آموزش تانل IPsec بین دو سرور لینوکس با strongSwan (Site-to-Site)

وقتی یک سرور لینوکس باید به فایروال سخت‌افزاری دفتر، روتر یک شعبه یا درگاه VPN یک سرویس ابری وصل شود، تقریباً همیشه یک پروتکل مشترک وجود دارد: IPsec. این استاندارد دهه‌هاست در تجهیزات شبکه پیاده‌سازی شده و هنوز زبان مشترک دنیای سازمانی برای اتصال Site-to-Site است. در این آموزش توضیح می‌دهیم IPsec چیست، IKEv2 و ESP چه نقشی دارند، و سپس قدم‌به‌قدم یک تانل IPsec بین دو سرور لینوکس با strongSwan راه می‌اندازیم.

مثال‌ها روی اوبونتو و دبیان نوشته شده‌اند و از آی‌پی‌های مستندسازی استفاده می‌کنند: سرور A با آی‌پی عمومی 203.0.113.10 و شبکهٔ داخلی 10.10.1.0/24، و سرور B با آی‌پی عمومی 198.51.100.20 و شبکهٔ داخلی 10.10.2.0/24. این همان طرحی است که در آموزش WireGuard Site-to-Site استفاده کردیم تا مقایسهٔ دو روش ساده‌تر باشد.

IPsec چیست؟

IPsec مجموعه‌ای از استانداردهای IETF برای امن کردن ترافیک در لایهٔ IP است. برخلاف TLS که فقط اتصال یک برنامه را رمزنگاری می‌کند، IPsec روی خود بسته‌های IP کار می‌کند؛ پس هر نوع ترافیکی، از TCP و UDP تا ICMP، بدون تغییر در برنامه‌ها از آن عبور می‌کند. IPsec سه بخش اصلی دارد:

• IKE (امروزه IKEv2): پروتکل تبادل کلید. دو طرف با آن یکدیگر را احراز هویت می‌کنند، روی الگوریتم‌ها توافق می‌کنند و کلیدهای رمزنگاری را می‌سازند. IKE روی UDP 500 کار می‌کند و اگر NAT در مسیر باشد، به UDP 4500 منتقل می‌شود.
• ESP: پروتکلی که داده‌ها را رمزنگاری و صحت آن‌ها را تضمین می‌کند. ESP یک پروتکل IP مستقل با شمارهٔ ۵۰ است، نه یک پورت TCP یا UDP؛ همین نکته در فایروال‌ها مهم است.
• AH: پروتکل قدیمی‌تری که فقط صحت بسته را تضمین می‌کند و رمزنگاری ندارد. امروزه تقریباً همیشه ESP به‌تنهایی استفاده می‌شود.

IPsec دو حالت کار دارد. در حالت Tunnel کل بستهٔ اصلی رمزنگاری می‌شود و داخل یک بستهٔ جدید با آی‌پی‌های عمومی دو سرور قرار می‌گیرد؛ این حالت برای اتصال دو شبکه استفاده می‌شود. در حالت Transport فقط محتوای بسته رمزنگاری می‌شود و سرآیند اصلی باقی می‌ماند؛ این حالت برای ارتباط مستقیم دو میزبان یا رمزنگاری یک تانل دیگر، مثل طرح «GRE روی IPsec» که در آموزش تانل GRE در لینوکس به آن اشاره کردیم، کاربرد دارد.

IKEv2 چطور اتصال را می‌سازد؟

IKEv2 در حالت عادی فقط با چهار پیام اتصال را برقرار می‌کند. در دو پیام اول (IKE_SA_INIT) دو طرف الگوریتم‌ها را انتخاب می‌کنند، با تبادل Diffie-Hellman یک کلید مشترک می‌سازند و بررسی می‌کنند که NAT در مسیر هست یا نه. در دو پیام بعدی (IKE_AUTH) که رمزنگاری‌شده‌اند، هر طرف هویت خود را با کلید مشترک یا گواهی ثابت می‌کند و همزمان اولین «CHILD_SA»، یعنی کانال ESP برای داده‌ها، ساخته می‌شود.

دو مفهوم را در ادامه زیاد می‌بینید. IKE_SA کانال کنترلی بین دو سرور است و CHILD_SA کانالی است که ترافیک واقعی از آن عبور می‌کند. هر CHILD_SA با دو «Traffic Selector» تعریف می‌شود: رنج آدرس‌های این طرف و رنج آدرس‌های طرف مقابل. فقط بسته‌هایی که بین این دو رنج جابه‌جا می‌شوند وارد تانل می‌شوند؛ بقیه مثل قبل مستقیم به اینترنت می‌روند. این روش «مبتنی بر سیاست» (Policy-based) نام دارد و رایج‌ترین مدل IPsec روی لینوکس است.

چرا هنوز IPsec؟ وقتی سازمان‌ها IPsec را انتخاب می‌کنند

اگر هر دو سر اتصال سرور لینوکس هستند، مقایسهٔ پروتکل‌های VPN نشان می‌دهد WireGuard معمولاً ساده‌تر و سریع‌تر است. با این حال IPsec در چند موقعیت هنوز انتخاب اول است:

• فایروال‌ها و روترهای سازمانی: تجهیزات رایج سازمانی، از فایروال‌های سخت‌افزاری تا روترهای شعبه‌ها، IPsec را به‌صورت استاندارد پشتیبانی می‌کنند، در حالی که پشتیبانی آن‌ها از WireGuard محدود یا وابسته به نسخه است.
• درگاه‌های VPN ابری: سرویس‌های Site-to-Site VPN در ارائه‌دهندگان بزرگ ابری، مثل AWS و Azure و Google Cloud، بر پایهٔ IPsec و IKEv2 کار می‌کنند. اگر می‌خواهید سرور مجازی خود را به شبکهٔ خصوصی یکی از این سرویس‌ها وصل کنید، IPsec زبان مشترک است.
• الزامات امنیتی و انطباق: بسیاری از سیاست‌های امنیتی سازمانی الگوریتم‌های مشخص، احراز هویت با گواهی و زیرساخت کلید عمومی (PKI) را الزام می‌کنند. IPsec همهٔ این‌ها را پشتیبانی می‌کند.
• مدیریت متمرکز تعداد زیاد اتصال: با گواهی‌های صادرشده از یک مرجع داخلی، اضافه کردن یا لغو دسترسی یک شعبه بدون تغییر در بقیهٔ سرورها ممکن است.

در مقابل، پیچیدگی IPsec بیشتر است: الگوریتم‌ها، شناسه‌ها و Traffic Selectorها باید در دو طرف دقیقاً هماهنگ باشند و بیشتر خطاها از همین ناهماهنگی‌ها می‌آیند.

مقایسهٔ IPsec با WireGuard و GRE

خلاصه: اگر هر دو سر لینوکس هستند، WireGuard را انتخاب کنید. اگر فقط یک اتصال ساده لایهٔ شبکه روی مسیری مطمئن لازم دارید یا پروتکل‌های مسیریابی و Multicast باید از تانل عبور کنند، GRE کافی است و می‌توان آن را داخل IPsec قرار داد. اگر یک سر تجهیزات سازمانی یا درگاه ابری است، IPsec راه استاندارد است.

پیش‌نیازها

• دو سرور لینوکس با آی‌پی عمومی ثابت؛ در این آموزش اوبونتو ۲۲.۰۴ یا جدیدتر یا دبیان ۱۲ یا جدیدتر.
• مجازی‌سازی کامل مثل KVM. IPsec در هستهٔ لینوکس اجرا می‌شود و روی کانتینرهای اشتراکی مثل OpenVZ یا LXC معمولاً کار نمی‌کند؛ این موضوع را در خرید سرور ایران برای تانل توضیح داده‌ایم.
• دسترسی root یا sudo و دسترسی کنسول از پنل، تا اگر قانون فایروال اشتباهی اتصال SSH را قطع کرد، راه بازگشت داشته باشید.
• رنج‌های داخلی که با هم و با شبکهٔ خصوصی دیتاسنتر تداخل نداشته باشند.

نصب strongSwan روی لینوکس

strongSwan رایج‌ترین پیاده‌سازی IPsec روی لینوکس است. ابزار پیکربندی مدرن آن swanctl است و پیکربندی قدیمی ipsec.conf منسوخ شده؛ در نسخهٔ ۶ strongSwan، افزونهٔ مربوط به آن به‌طور پیش‌فرض غیرفعال است. طبق مستندات strongSwan، در دبیان و اوبونتو بستهٔ کلی strongswan همان سرویس قدیمی را نصب می‌کند؛ برای روش مدرن، این دو بسته را نصب کنید:

sudo apt update
sudo apt install charon-systemd strongswan-swanctl
sudo systemctl enable --now strongswan
systemctl status strongswan

سرویس strongswan در هر بار شروع، پیکربندی‌های پوشهٔ /etc/swanctl را بارگذاری می‌کند. اگر پیش‌تر بستهٔ strongswan-starter را نصب کرده‌اید، طبق همان مستندات فقط یکی از دو سرویس را فعال نگه دارید تا تداخل پیش نیاید. همین مراحل را روی هر دو سرور اجرا کنید.

اگر سرورها باید ترافیک شبکه‌های داخلی را به هم برسانند، فوروارد بسته را فعال کنید:

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-ipsec.conf
sudo sysctl --system

ساخت کلید مشترک (PSK) امن

ساده‌ترین روش احراز هویت در IPsec، کلید مشترک یا PSK است: یک رشتهٔ مخفی که هر دو سرور آن را دارند. PSK فقط وقتی امن است که طولانی و کاملاً تصادفی باشد. هرگز از رمزهای قابل حدس یا کلیدی که در جای دیگری استفاده کرده‌اید بهره نبرید. یک کلید تصادفی ۳۲ بایتی بسازید:

openssl rand -base64 32

خروجی را فقط از راه امن، مثلاً داخل همان نشست SSH، به سرور دوم منتقل کنید و آن را در پیام‌رسان، ایمیل یا مخزن کد قرار ندهید. دلیل این سخت‌گیری روشن است: کسی که PSK را داشته باشد می‌تواند خود را جای یکی از دو سرور جا بزند. در IKEv1 و به‌خصوص حالت Aggressive Mode، مهاجم می‌توانست از ترافیک ضبط‌شده، PSK ضعیف را به‌صورت آفلاین حدس بزند؛ IKEv2 این ضعف را ندارد، ولی کلید کوتاه در هر حال خطرناک است. در این آموزش فقط از IKEv2 استفاده می‌کنیم.

PSK یا گواهی؟

برای یک اتصال بین دو سرور که خودتان مدیریت می‌کنید، PSK تصادفی و طولانی کاملاً قابل قبول است. برای محیط‌های تولیدی با چند شعبه یا چند مدیر، احراز هویت با گواهی را ترجیح دهید: هر سرور کلید خصوصی خودش را دارد که هرگز جابه‌جا نمی‌شود، با لو رفتن یک سرور فقط گواهی همان سرور لغو می‌شود و اضافه کردن سرور جدید نیازی به تغییر بقیه ندارد. strongSwan با ابزار pki می‌تواند یک مرجع گواهی داخلی و گواهی سرورها را بسازد. پیکربندی تقریباً همان است؛ فقط در بخش‌های local و remote به جای auth = psk از auth = pubkey استفاده می‌شود و فایل‌های گواهی در پوشه‌های x509ca و x509 و private زیر /etc/swanctl قرار می‌گیرند.

فایل swanctl.conf در دو سرور

پیکربندی هر اتصال را در یک فایل جداگانه در پوشهٔ conf.d بنویسید؛ فایل اصلی swanctl.conf در بسته‌های دبیان و اوبونتو این پوشه را بارگذاری می‌کند. روی سرور A، فایل /etc/swanctl/conf.d/site-b.conf را بسازید:

connections {
  site-b {
    version = 2
    local_addrs = 203.0.113.10
    remote_addrs = 198.51.100.20
    proposals = aes256gcm16-prfsha384-ecp384
    dpd_delay = 30s
    local {
      auth = psk
      id = site-a.example
    }
    remote {
      auth = psk
      id = site-b.example
    }
    children {
      net {
        local_ts = 10.10.1.0/24
        remote_ts = 10.10.2.0/24
        esp_proposals = aes256gcm16-ecp384
        start_action = trap
        dpd_action = trap
      }
    }
  }
}

secrets {
  ike-site-b {
    id-a = site-a.example
    id-b = site-b.example
    secret = "REPLACE_WITH_RANDOM_PSK"
  }
}

روی سرور B همین فایل را با نام site-a.conf بسازید و جای مقادیر را عوض کنید: local_addrs برابر 198.51.100.20، remote_addrs برابر 203.0.113.10، شناسهٔ local برابر site-b.example و شناسهٔ remote برابر site-a.example، و Traffic Selectorها برعکس: local_ts = 10.10.2.0/24 و remote_ts = 10.10.1.0/24. بخش secrets در هر دو سرور یکسان است. سپس دسترسی فایل را محدود کنید، چون کلید مشترک در آن قرار دارد:

sudo chmod 600 /etc/swanctl/conf.d/site-b.conf
sudo swanctl --load-all

چند نکته دربارهٔ این تنظیمات:

• proposals و esp_proposals: الگوریتم‌ها را صریحاً تعیین کرده‌ایم تا دو طرف دقیقاً بدانند روی چه چیزی توافق می‌کنند. AES-GCM روی پردازنده‌های دارای AES-NI بسیار سریع است. اضافه کردن گروه Diffie-Hellman به esp_proposals یعنی هنگام تجدید کلید، کلید تازه و مستقل ساخته می‌شود (Perfect Forward Secrecy). اگر طرف مقابل تجهیزات دیگری است، همین الگوریتم‌ها را در آن هم تنظیم کنید.
• شناسه‌ها: شناسه‌ها را صریح نوشته‌ایم تا اگر یکی از سرورها پشت NAT قرار گرفت، آدرس داخلی جای شناسه را نگیرد و احراز هویت شکست نخورد.
• start_action = trap: تانل با اولین بسته‌ای که باید وارد آن شود، خودکار برقرار می‌شود. اگر می‌خواهید تانل بلافاصله پس از بارگذاری بالا بیاید، در یکی از دو طرف start بنویسید.
• dpd_delay و dpd_action: اگر طرف مقابل ۳۰ ثانیه پاسخ ندهد، اتصال پاک می‌شود و با اولین بستهٔ بعدی دوباره ساخته می‌شود.

فایروال: UDP 500 و 4500 و پروتکل ESP

IPsec سه نوع ترافیک لازم دارد: UDP 500 برای IKE، UDP 4500 برای IKE و ESP وقتی NAT در مسیر است، و پروتکل ESP (شمارهٔ ۵۰) برای داده‌ها وقتی NAT در مسیر نیست. با فایروال UFW، روی سرور A فقط برای آی‌پی سرور B باز کنید:

sudo ufw allow from 198.51.100.20 to any port 500,4500 proto udp
sudo ufw allow from 198.51.100.20 to any proto esp
sudo ufw status numbered

روی سرور B همین قانون‌ها را با آی‌پی سرور A اجرا کنید. طبق راهنمای UFW، پروتکل ESP فقط در قالب کامل قانون پذیرفته می‌شود و پورت ندارد. اگر دیتاسنتر شما فایروال شبکه‌ای جداگانه در پنل دارد، همین موارد را آنجا هم باز کنید.

اگر بسته‌ها بین دو شبکهٔ داخلی فوروارد می‌شوند، UFW ترافیک عبوری را به‌طور پیش‌فرض مسدود می‌کند. با قانون‌هایی مثل ufw route allow from 10.10.2.0/24 to 10.10.1.0/24 و برعکس، فقط مسیرهای لازم را باز کنید. نکتهٔ مهم دیگر NAT است: اگر سرور برای دسترسی شبکهٔ داخلی به اینترنت قانون MASQUERADE دارد، باید ترافیک IPsec را از آن مستثنا کنید؛ در غیر این صورت آدرس مبدأ پیش از رمزنگاری عوض می‌شود، دیگر با Traffic Selector جور درنمی‌آید و بسته بدون رمزنگاری به اینترنت می‌رود:

sudo iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT

عبور از NAT (NAT-T)

ESP پورت ندارد و دستگاه‌های NAT نمی‌دانند آن را به کدام دستگاه داخلی برسانند. راه‌حل استاندارد، NAT Traversal است: در پیام‌های اول IKEv2، هر دو طرف آدرس و پورت خود را به‌صورت هش می‌فرستند و اگر مقدار دریافتی با آدرس واقعی جور نباشد، می‌فهمند NAT در مسیر است. در این حالت ارتباط به UDP 4500 منتقل می‌شود و ESP داخل UDP قرار می‌گیرد، تا NAT بتواند مثل هر ترافیک UDP دیگری با آن رفتار کند. strongSwan این کار را خودکار انجام می‌دهد و برای باز نگه داشتن نگاشت NAT، به‌طور پیش‌فرض هر ۲۰ ثانیه یک بستهٔ کوچک Keepalive می‌فرستد.

اگر سرور شما پشت NAT است، چند نکته را رعایت کنید: آن سرور باید آغازکنندهٔ اتصال باشد، چون طرف مقابل آدرس واقعی آن را نمی‌داند؛ پس در آن سمت start_action = start بنویسید. شناسه‌ها را صریح تعیین کنید، همان‌طور که در فایل بالا انجام دادیم. و UDP 4500 را در فایروال هر دو طرف باز نگه دارید.

راه‌اندازی و بررسی تانل

پس از بارگذاری پیکربندی در هر دو سرور، اتصال را دستی آغاز کنید و وضعیت را ببینید:

sudo swanctl --list-conns
sudo swanctl --initiate --child net
sudo swanctl --list-sas

اگر همه‌چیز درست باشد، خروجی --list-sas وضعیت ESTABLISHED را برای IKE_SA و INSTALLED را برای CHILD_SA نشان می‌دهد، همراه با الگوریتم‌های توافق‌شده و شمارندهٔ بسته‌ها:

$ sudo swanctl --list-sassite-b: #1, ESTABLISHED, IKEv2, 4f1c2a9e7b3d5c60_i* 9a8b7c6d5e4f3a21_r  local  'site-a.example' @ 203.0.113.10[500]  remote 'site-b.example' @ 198.51.100.20[500]  AES_GCM_16-256/PRF_HMAC_SHA2_384/ECP_384  net: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-256    local  10.10.1.0/24    remote 10.10.2.0/24$ 

برای آزمایش واقعی، از آدرسی داخل شبکهٔ A به آدرسی داخل شبکهٔ B پینگ بگیرید. اگر روی خود سرور آزمایش می‌کنید، آدرس مبدأ باید داخل local_ts باشد؛ مثلاً اگر سرور A روی رابط داخلی آدرس 10.10.1.1 دارد:

ping -I 10.10.1.1 -c 3 10.10.2.1
sudo ip xfrm state
sudo ip xfrm policy

دستورهای ip xfrm نشان می‌دهند هستهٔ لینوکس چه کلیدها و سیاست‌هایی را نصب کرده است. برای دیدن لاگ‌ها از journalctl -u strongswan -f استفاده کنید؛ پیام‌های IKE در آنجا با جزئیات ثبت می‌شوند. برای جزئیات بیشتر دربارهٔ مدیریت سرویس‌ها و خواندن لاگ، راهنمای ساخت سرویس systemd را ببینید.

MTU و MSS در تانل IPsec

ESP به هر بسته چند ده بایت سربار اضافه می‌کند: سرآیند IP بیرونی، سرآیند ESP، بردار اولیه، پدینگ و کد احراز صحت؛ با NAT-T، سرآیند UDP هم اضافه می‌شود. نتیجه این است که بستهٔ ۱۵۰۰ بایتی پس از رمزنگاری از MTU مسیر بزرگ‌تر می‌شود و یا تکه‌تکه می‌شود یا گم می‌شود. علامت مشکل همان علامت آشنای همهٔ تانل‌هاست: پینگ و SSH کار می‌کنند، ولی انتقال فایل یا صفحه‌های بزرگ گیر می‌کند.

چون در روش مبتنی بر سیاست رابط شبکهٔ جداگانه‌ای وجود ندارد، ساده‌ترین راه‌حل کوچک کردن MSS اتصال‌های TCP است. مستندات strongSwan برای این کار قانونی مشابه زیر پیشنهاد می‌کند که MSS بسته‌های SYN عبوری از تانل را روی ۱۳۶۰ تنظیم می‌کند:

sudo iptables -t mangle -A FORWARD -m policy --pol ipsec --dir in -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360
sudo iptables -t mangle -A FORWARD -m policy --pol ipsec --dir out -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360

برای پیدا کردن MTU واقعی مسیر، از ping -M do با اندازه‌های مختلف استفاده کنید و کیفیت مسیر را با ابزارهای ping، traceroute و mtr بسنجید. اگر گم‌شدن بسته یا نوسان دارید، راهنمای پینگ بالا و Packet Loss را ببینید.

IPsec مبتنی بر مسیر (XFRM و VTI)

در روش مبتنی بر سیاست، هر ترکیب جدید از شبکه‌ها یعنی Traffic Selector جدید. اگر چند شبکه دارید یا می‌خواهید از پروتکل‌های مسیریابی پویا استفاده کنید، IPsec مبتنی بر مسیر راحت‌تر است: در این روش یک رابط شبکهٔ مجازی، مثل رابط XFRM در هسته‌های جدید لینوکس یا VTI در هسته‌های قدیمی‌تر، ساخته می‌شود، Traffic Selectorها روی همه‌چیز تنظیم می‌شوند و تصمیم اینکه چه ترافیکی وارد تانل شود، با جدول مسیریابی گرفته می‌شود. strongSwan برای این کار گزینه‌های if_id_in و if_id_out را دارد. برای یک اتصال ساده بین دو شبکه، همان روش مبتنی بر سیاست کافی است.

L2TP/IPsec چیست و چرا برای راه‌اندازی جدید مناسب نیست؟

L2TP/IPsec ترکیبی قدیمی است که هنوز در جست‌وجوها زیاد دیده می‌شود. L2TP یک پروتکل تونل‌زنی لایهٔ ۲ است که خودش هیچ رمزنگاری‌ای ندارد؛ به همین دلیل داخل IPsec اجرا می‌شود. در عمل این ترکیب معمولاً با IKEv1 و یک کلید مشترک واحد برای همهٔ کاربران راه‌اندازی می‌شد، دو لایه بسته‌بندی دارد که سربار و عیب‌یابی را سخت‌تر می‌کند و برخی سازندگان سیستم‌عامل امکان ساخت اتصال جدید با آن را حذف کرده‌اند. برای اتصال سرور به سرور هیچ دلیلی برای استفاده از آن وجود ندارد: IKEv2 خالص، همان‌طور که در این آموزش راه‌اندازی کردیم، امن‌تر و ساده‌تر است. جزئیات بیشتر را در مقایسهٔ پروتکل‌های VPN آورده‌ایم.

اشتباهات رایج در راه‌اندازی تانل IPsec

• ناهماهنگی الگوریتم‌ها: اگر proposals در دو طرف مشترک نداشته باشند، لاگ خطای NO_PROPOSAL_CHOSEN نشان می‌دهد. الگوریتم‌ها را در هر دو طرف یکسان بنویسید.
• Traffic Selector برعکس یا ناهماهنگ: local_ts یک طرف باید دقیقاً remote_ts طرف دیگر باشد؛ در غیر این صورت IKE_SA برقرار می‌شود ولی CHILD_SA با خطای TS_UNACCEPTABLE رد می‌شود.
• شناسهٔ اشتباه: شناسه‌های local و remote و بخش secrets باید با هم جور باشند؛ خطای AUTHENTICATION_FAILED معمولاً از همین جاست.
• باز نکردن ESP یا UDP 4500: IKE برقرار می‌شود ولی داده‌ای عبور نمی‌کند، چون فقط UDP 500 باز است.
• قانون MASQUERADE بدون استثنا: آدرس مبدأ پیش از رمزنگاری عوض می‌شود و ترافیک وارد تانل نمی‌شود.
• PSK کوتاه یا تکراری: کلید مشترک باید تصادفی و طولانی باشد و برای هر اتصال جدا ساخته شود.
• استفاده از IKEv1 یا L2TP بدون دلیل: برای راه‌اندازی جدید همیشه IKEv2.
• نادیده گرفتن MTU: پینگ سالم است ولی انتقال‌های بزرگ گیر می‌کنند.
• اشتباه گرفتن تانل با تغییر DNS: تغییر DNS مسیر ترافیک را عوض نمی‌کند؛ تفاوت را در DNS شکن چیست؟ توضیح داده‌ایم.

عیب‌یابی سریع

برای دیدن بسته‌ها در شبکه، sudo tcpdump -ni eth0 udp port 500 or udp port 4500 or esp نشان می‌دهد کدام نوع ترافیک واقعاً رد و بدل می‌شود. وضعیت شبکهٔ دیتاسنترهای کلودیفای را هم در صفحهٔ وضعیت ببینید.

کدام سرور برای تانل IPsec؟

IPsec در هستهٔ لینوکس اجرا می‌شود و با شتاب‌دهندهٔ AES-NI، رمزنگاری AES-GCM بار کمی روی پردازنده دارد؛ برای چند تانل Site-to-Site، یک سرور مجازی ۱ هسته و ۱ گیگابایت رم معمولاً کافی است. مهم‌تر از سخت‌افزار، مجازی‌سازی KVM، آی‌پی عمومی ثابت، پورت شبکهٔ سریع و مسیر پایدار بین دو لوکیشن است. اگر یک سر اتصال در ایران است، سرور مجازی ایران با پورت ۲۵ گیگ مناسب است و فقط ترافیک خروجی آن محاسبه می‌شود (هر گیگابایت ۱٬۲۵۰ تومان)؛ برای سر دیگر، سرور مجازی خارج را در لوکیشنی نزدیک به سرویس‌ها یا کاربرانتان انتخاب کنید و پیش از تصمیم، راهنمای انتخاب لوکیشن با کمترین پینگ را ببینید. برای آزمایش پیکربندی، الگوریتم‌ها و MTU پیش از اتصال به تجهیزات اصلی، سرور ساعتی گزینهٔ اقتصادی است: چند ساعت تست می‌کنید و فقط همان ساعت‌ها را می‌پردازید.

نکتهٔ حقوقی و شرایط استفاده

IPsec و strongSwan ابزارهای استاندارد و متن‌باز برای ساخت شبکهٔ خصوصی امن بین سرورها و شبکه‌های سازمانی هستند و این آموزش فقط اتصال Site-to-Site بین سرورهای خودتان را پوشش می‌دهد. مسئولیت نحوهٔ استفاده با شماست: فقط سرورها و شبکه‌هایی را به هم وصل کنید که مالکشان هستید یا اجازهٔ کتبی مدیر آن‌ها را دارید، سیاست‌های امنیتی سازمان خود را رعایت کنید و قوانین کشور محل هر سرور و شرایط ارائه‌دهنده را در نظر بگیرید. بند «استفادهٔ مجاز» در شرایط استفادهٔ کلودیفای کاربردهای ممنوع را مشخص کرده است.

ادامهٔ این مجموعه

این مقاله نهمین قسمت از مجموعهٔ آموزش‌های تانل و شبکهٔ سرور در مجلهٔ کلودیفای است. قسمت‌های قبلی: تانل معکوس چیست؟، خرید سرور ایران برای تانل، تانل GRE در لینوکس، مقایسهٔ Backhaul و Rathole با GOST و FRP، تانل SSH، WireGuard Site-to-Site، مقایسهٔ پروتکل‌های VPN و انتخاب لوکیشن با کمترین پینگ. قسمت بعدی، تانل 6to4 و IPv6، هم منتشر شده است.

سؤالات متداول