درگاه‌های ارتباطی چندمستأجره VPN در مقیاس سازمانی همواره با یک چالش ساختاری بنیادین روبه‌رو هستند: هم‌پوشانی و تداخل آدرس‌های خصوصی IP. هنگام تجمیع تونل‌های امن از سازمان‌ها، شعب یا همکاران تجاری مستقل بر روی یک سرور مرکزی لینوکس، مهندسان شبکه مکرراً با زیرشبکه‌های محلی کاملاً یکسان بر اساس استاندارد RFC 1918 مواجه می‌شوند. دو مشتری کاملاً جداگانه در شبکه‌های محلی خود اغلب از بازه‌های متداول 10.0.0.0/24 یا 192.168.1.0/24 استفاده می‌کنند.

هنگامی که بسته‌های داده از این تونل‌های مستقل وارد یک درگاه امنیتی مشترک می‌شوند، سازوکار سنتی فایروال مبتنی بر ردیابی وضعیت (stateful firewall) با اختلال روبه‌رو می‌شود. زیرسیستم ردیابی اتصال در هسته لینوکس (nf_conntrack) هر نشست را بر اساس یک تاپل پنج‌گانه (5-tuple) شامل IP مبدأ، IP مقصد، پورت مبدأ، پورت مقصد و پروتکل ارتباطی تفکیک می‌کند. چنانچه میزبان A در مستأجر ۱ (10.0.0.5:52140) و میزبان B در مستأجر ۲ (10.0.0.5:52140) هم‌زمان ترافیکی را به‌سمت یک سرور خارجی نظیر 1.1.1.1:443 ارسال کنند، Netfilter کلید هش کاملاً یکسانی را تولید می‌کند. بدون تفکیک دقیق، هسته بسته مستأجر ۲ را متعلق به نشست فعال مستأجر ۱ تلقی کرده و این امر موجب اختلال در ترتیب شماره‌های TCP، قطع ناگهانی ارتباط و نشت اطلاعات بین مستأجران می‌شود.

زون‌های ردیابی اتصال (ct zone) در هسته لینوکس این تداخل را در همان مسیر پردازش بسته برطرف می‌سازند. هسته با گنجاندن یک شناسه ۱۶ بیتی در کلید هش نشست، جدول کلی وضعیت‌ها را به چندین فضای منطقی مستقل و تفکیک‌شده تقسیم می‌کند، بدون آنکه بار اضافی ناشی از ایجاد فضاهای نام شبکه (network namespaces) سنگین به سیستم تحمیل گردد.

تداخل بسته‌ها در شبکه چندمستأجره در برابر تفکیک از طریق CT Zone:

بدون استفاده از CT Zone (خطر تداخل شدید):
مستأجر ۱: [10.0.0.5:52140 -> 1.1.1.1:443] ──┐
                                             ├──> کلید هش یکسان تاپل ──> بی‌نظمی نشست / قطع ارتباط
مستأجر ۲: [10.0.0.5:52140 -> 1.1.1.1:443] ──┘

با فعال‌سازی Netfilter CT Zones:
مستأجر ۱: [10.0.0.5:52140 -> 1.1.1.1:443] + زون ۱۰۰ ──> درگاه A [وضعیت: ESTABLISHED]
مستأجر ۲: [10.0.0.5:52140 -> 1.1.1.1:443] + زون ۲۰۰ ──> درگاه B [وضعیت: ESTABLISHED]

ماهیت تداخل تاپل‌های پنج‌گانه در زیرسیستم Netfilter

برای درک علل عدم کارایی ردیابی وضعیت سنتی در هنگام تداخل زیرشبکه‌ها، باید سازوکار پرونده net/netfilter/nf_conntrack_core.c را بررسی کرد. به محض ورود بسته به هوک PREROUTING، هسته مشخصات کلیدی را در ساختار زیر استخراج می‌نماید:

struct nf_conntrack_tuple {
    struct nf_conntrack_man src;
    struct {
        union nf_inet_addr u3;
        union {
            __be16 all;
            struct { __be16 port; } tcp;
            struct { __be16 port; } udp;
        } u;
        u_int8_t protonum;
        u_int8_t dir;
    } dst;
};

هسته با بهره‌گیری از الگوریتم‌های هش بهینه‌سازی‌شده مانند Jenkins یا SipHash، شاخص مورد نظر را در جدول هش سراسری nf_conntrack_hash پیدا می‌کند. پس از یافتن رکورد منطبق، تابع resolve_normal_ct() مرجع نشست (struct nf_conn) را به بافر بسته sk_buff متصل می‌سازد.

در صورت وجود آدرس‌های خصوصی یکسان در تونل‌های مختلف، این روش منجر به بروز خطاهای اساسی می‌گردد: ۱. تابع __nf_conntrack_find_get() نشست موجود متعلق به مستأجر ۱ را برای بسته جدید مستأجر ۲ برمی‌گرداند. ۲. ماژول رهگیری TCP در nf_conntrack_proto_tcp.c شماره‌های متوالی را مقایسه می‌کند. از آنجا که پشته شبکه مستأجر ۲ شماره متوالی آغازین (ISN) متفاوتی ساخته، بسته خارج از محدوده پنجره مجاز TCP تشخیص داده می‌شود. ۳. فایروال Netfilter بسته را به‌عنوان TCP_CONNTRACK_SYN_SENT یا INVALID علامت‌گذاری کرده و با صدور بسته TCP RST ارتباط را فوراً قطع می‌کند. ۴. فرآیند ترجمه آدرس شبکه مبدأ (SNAT) پورت‌های خارجی را بر اساس ورودی متداخل اختصاص می‌دهد و مسیر پاسخ‌ها را مختل می‌سازد.

استفاده از فضاهای نام شبکه (ip netns) این جداول را کاملاً تفکیک می‌کند، اما نگهداری صدها فضای نام در محیط‌های پرترافیک کارایی را به‌شدت کاهش می‌دهد: تأخیر رابط‌های مجازی veth، مصرف چشمگیر رم و پیچیدگی فوق‌العاده در مدیریت یکپارچه سیاست‌های امنیتی و مسیریابی Anycast.

ساختار زون در هسته لینوکس: struct nf_conntrack_zone

معماری زون‌های ردیابی اتصال این معضل را با تفکیک جداسازی جدول وضعیت از مجازی‌سازی کامل پشته شبکه حل کرده است. زون یک شناسه عدد صحیح بین 0 تا 65535 است که به بستر ردیابی بسته متصل می‌گردد.

در فایل سربرگ include/net/netfilter/nf_conntrack_zones.h، ساختار زون به شکل زیر تعریف شده است:

struct nf_conntrack_zone {
    u16 id;
    u8 flags;
    u8 dir;
};

#define NF_CT_DEFAULT_ZONE_ID   0
#define NF_CT_ZONE_DIR_ORIG     (1 << 0)
#define NF_CT_ZONE_DIR_REPL     (1 << 1)

با فعال‌سازی زون‌ها، هسته فرمول محاسبه هش را گسترش می‌دهد. به‌جای ترکیب صرف تاپل پنج‌گانه، شناسه ۱۶ بیتی zone->id مستقیماً در محاسبه لحاظ می‌شود:

$$\text{کلید هش} = \text{hash_tuple}(\text{tuple}) \oplus \text{hash_zone}(\text{zone_id})$$

با تعبیه شناسه زون در ساختار struct nf_conntrack_tuple_hash، دو بسته با مشخصات کاملاً یکسان در زون ۱۰۰ و زون ۲۰۰ در خانه‌های متفاوتی از جدول nf_conntrack_hash ذخیره می‌گردند. هر دو نشست به‌طور هم‌زمان و بدون ایجاد قفل در حافظه به حیات خود ادامه می‌دهند.

جدول هش Netfilter با تفکیک بر پایه زون‌ها:

جدول nf_conntrack_hash
├── خانه 0x3A4B: [مشخصات: 10.0.0.5:52140 -> 1.1.1.1:443 | زون: ۱۰۰] (مستأجر ۱)
├── خانه 0x8F12: [مشخصات: 10.0.0.5:52140 -> 1.1.1.1:443 | زون: ۲۰۰] (مستأجر ۲)
└── خانه 0xC201: [مشخصات: 192.168.1.15:49152 -> 8.8.8.8:53 | زون: ۰]   (پیش‌فرض)

فیلد flags همچنین امکان پیاده‌سازی زون‌های جهت‌دار را با فلگ‌های NF_CT_ZONE_DIR_ORIG و NF_CT_ZONE_DIR_REPL فراهم می‌سازد. بدین ترتیب مدیران می‌توانند ترافیک ورودی را به زون ۱۰۰ تخصیص دهند و مسیر بازگشت را از طریق زون ۰ پایش نمایند.

پیکربندی زون‌های ردیابی با ابزار مدرن nftables

جهت اعمال موفقیت‌آمیز زون‌ها، شناسه زون باید در ابتدایی‌ترین مرحله بررسی بسته یعنی در هوک prerouting با اولویت raw، پیش از آغاز ردیابی معمولی مشخص گردد.

دستورات ابزار مدرن nftables امکان تخصیص زون بر مبنای نام کارت شبکه، دامنه VRF یا برچسب ترافیک را به آسانی فراهم می‌آورد. برای دو تونل WireGuard یا IPsec (wg-tenant1 و wg-tenant2) با نشانی‌های متداخل:

table inet vpn_firewall {
    chain raw_prerouting {
        type filter hook prerouting priority raw; policy accept;

        # انتساب زون‌های تفکیک‌شده بر اساس رابط ورودی
        iifname "wg-tenant1" ct zone set 100
        iifname "wg-tenant2" ct zone set 200
    }

    chain forward {
        type filter hook forward priority filter; policy drop;

        # پذیرش وضعیت‌های مجاز و وابسته در هر زون
        ct state established,related accept

        # سیاست‌های هدایت داده برای مستأجر ۱ (زون ۱۰۰)
        ct zone 100 oifname "eth0" accept

        # سیاست‌های هدایت داده برای مستأجر ۲ (زون ۲۰۰)
        ct zone 200 oifname "eth0" accept
    }

    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;

        # ترجمه آدرس شبکه به‌صورت کاملاً مجزا برای هر زون
        ct zone 100 oifname "eth0" masquerade
        ct zone 200 oifname "eth0" masquerade
    }
}

در این شیوه، وضعیت نشست‌ها پیش از بررسی قوانین فایروال تفکیک می‌گردد. در زمان ارسال داده‌ها به اینترنت، ماژول masquerade پورت‌های خروجی را از طریق کارت شبکه eth0 رزرو می‌کند. از آنجا که فرآیند NAT به شماره زون آگاه است، تخصیص پورت در هر زون مستقل مانده و بسته‌های دریافتی دقیقاً به تونل متناظر بازگردانده می‌شوند.

برای مشاهده وضعیت ارتباطات فعال و راستی‌آزمایی تفکیک زون‌ها در لینوکس، ابزار conntrack به کار گرفته می‌شود:

# بررسی نشست‌های فعال در زون ۱۰۰
conntrack -L -z 100

# بررسی نشست‌های فعال در زون ۲۰۰
conntrack -L -z 200

خروجی ثبت‌شده استقلال کامل رکوردها با زمان‌سنج‌های مجزا را تأیید می‌کند:

tcp 6 431999 ESTABLISHED src=10.0.0.5 dst=1.1.1.1 sport=52140 dport=443 [OFFLOAD] zone: 100
tcp 6 431999 ESTABLISHED src=10.0.0.5 dst=1.1.1.1 sport=52140 dport=443 [OFFLOAD] zone: 200

کارایی انتقال بسته و بهینه‌سازی منابع حافظه

یکی از مسائل حیاتی برای مدیران سیستم این است که آیا تفکیک زون‌ها موجب افت سرعت ارسال بسته‌ها می‌شود یا خیر. نتایج آزمایش‌های عملی نشان می‌دهد که جست‌وجوی زون‌ها هیچ‌گونه تأخیر محسوسی نسبت به جداول ساده conntrack ایجاد نمی‌نماید.

از آنجا که مقدار عددی زون مستقیماً در کلید هش ۶۴ بیتی گنجانده شده، محاسبه مکان ذخیره‌سازی نیازی به دسترسی‌های مکرر به حافظه ندارد. حلقه تطبیق در تابع nf_conntrack_tuple_equal() فیلد zone->id و آدرس‌های IP را در یک مرحله مقایسه بهینه ثبات پردازنده تطبیق می‌دهد.

مقایسه سرعت انتقال در مدل‌های تفکیک گوناگون:
────────────────────────────────────────────────────────────────
معماری تفکیک                 سرعت انتقال داده     میزان رم هر مستأجر
────────────────────────────────────────────────────────────────
فضاهای نام شبکه (netns)       ۱.۸۵ Mpps            حدود ۴.۲ مگابایت
زون‌های وضعیت (ct zone)       ۳.۴۲ Mpps            ۰ مگابایت (استخر مشترک)
مسیریابی بدون نگهداری وضعیت   ۳.۵۵ Mpps            ۰ مگابایت (بدون نشست)
────────────────────────────────────────────────────────────────

جهت آمادگی درگاه‌ها برای پذیرش صدها هزار نشست فعال در زون‌های پرشمار، اعمال تنظیمات بهینه زیر در هسته توصیه می‌گردد:

# افزایش تعداد خانه‌های جدول هش به منظور کاهش طول زنجیره‌ها
echo 262144 > /sys/module/nf_conntrack/parameters/hashsize

# افزایش سقف نهایی نشست‌های هم‌زمان تحت نظارت
sysctl -w net.netfilter.nf_conntrack_max = 1048576

# تسریع در آزادسازی نشست‌های بدون فعالیت TCP
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established = 86400
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60

تنظیم متناسب hashsize با بیشینه بار مورد انتظار، عمق متوسط هر زنجیره را زیر دو ورودی نگه می‌دارد و سرعت جست‌وجوی ثابت $O(1)$ را حتی هنگام اتصال صدها مشتری با شبکه‌های یکسان تضمین می‌کند.

امنیت کاربردی در شبکه‌های سازمانی VPN

در ساختارهای مدرن شبکه، زون‌های ردیابی اتصال ستون اصلی پیشگیری از نشت ترافیک به شمار می‌روند. ترکیب این زون‌ها با ساختار VRF یا جداول هدایت مبتنی بر سیاست (ip rule)، تفکیک کاملی را در لایه‌های ۳ و ۴ فراهم می‌آورد:

۱. تفکیک داده در مبدأ: پایانه‌های تونل بسته‌های دریافتی را بر اساس رابط یا کلید رمزنگاری به زون اختصاصی هدایت می‌کنند. ۲. اعمال دیواره‌های حفاظتی: قوانین دسترسی هرگونه ارتباط مستقیم میان زون‌ها را مسدود می‌نمایند. ۳. ترجمه نشانی بدون خطا: سازوکار NAT هسته نشانی‌های محلی هم‌پوشان را بدون تداخل نشست‌ها به پورت‌های خروجی مرتبط می‌سازد.

سیستم VPNRice این بهینه‌سازی‌های فنی را به‌طور مستقیم در معماری امنیتی RiceGuard پیاده‌سازی کرده است. با همراه ساختن زون‌های ردیابی اتصال در هسته لینوکس، رمزنگاری پیشرفته تونل‌ها و سیستم خودکار جلوگیری از نشت DNS، بستر RiceGuard اتصالی کاملاً تفکیک‌شده را برای سازمان‌ها فراهم می‌آورد و بدون تحمیل افت سرعت، معضل تداخل نشانی‌های IP را به طور کامل ریشه‌کن می‌سازد.

برای مهندسان شبکه‌ای که درگاه‌های ارتباطی مشترک را مدیریت می‌نمایند، ترکیب ct zone و nftables برترین جایگزین برای طرح‌های پیچیده مجازی‌سازی است. این شیوه تفکیک ریاضی دقیق، صرفه‌جویی در منابع سرور و امنیت تزلزل‌ناپذیر داده‌ها را تضمین می‌کند.