📄 تانل GRE به سایت دیگر

اگر می‌خواهید ماشین‌های شما در ستون بتوانند با شبکه‌ی یک سایت دیگر — دفتر شما، یک مرکزداده‌ی دیگر یا یک ارائه‌دهنده‌ی دیگر — ارتباط مستقیم داشته باشند، می‌توانید بین ماشین خود و دستگاه سمت مقابل یک تانل برقرار کنید. در این راهنما از GRE استفاده می‌کنیم که ساده‌ترین و سریع‌ترین گزینه برای این کار است.

چه چیزی این راهنما را متفاوت می‌کند؟

در ستون، ماشین شما IP خارجی را مستقیماً روی اینترفیس خود ندارد؛ دسترسی آن به اینترنت از طریق یک One-to-One NAT برقرار می‌شود. بیشتر راهنماهای برپایی تانل این حالت را در نظر نمی‌گیرند و به همین دلیل بسیاری از کاربران تصور می‌کنند در چنین شرایطی نمی‌توان تانل برقرار کرد.

این راهنما دقیقاً همین سناریو را پیاده‌سازی می‌کند: برپایی تانل GRE از پشت یک One-to-One NAT. برای این کار به هیچ تنظیم اضافه‌ای نیاز ندارید؛ تنها چیزی که باید درست انتخاب شود، مقدار local و remote در هر سمت است.

به هر یک از دو ماشینی که سر تانل روی آن بالا می‌آید، Tunnel Endpoint گفته می‌شود؛ سمت ستون را Tunnel Endpoint A و سمت مقابل را Tunnel Endpoint B می‌نامیم.

پیش از خواندن این صفحه، بهتر است عبور دادن ترافیک از یک ماشین Gateway را خوانده باشید؛ مفاهیم Route، عبور بسته و آدرس‌های قابل فوروارد در آنجا توضیح داده شده‌اند. همان ماشینی که در آن راهنما به‌عنوان ماشین Gateway پیکربندی کردید، در این سناریو نقش Tunnel Endpoint A را بر عهده می‌گیرد؛ یک ماشین است با دو نام، و در این صفحه برای دقت بیشتر از عنوان Tunnel Endpoint استفاده می‌کنیم.

دستورهای این صفحه هم مانند بقیه‌ی این راهنما با ابزارهای استاندارد Linux Kernel نوشته شده‌اند. اگر می‌خواهید سر تانل را روی pfSense، MikroTik یا دستگاه دیگری بالا بیاورید، قاعده‌ی انتخاب local و remote و الزام «آدرس‌های قابل فوروارد» بدون تغییر برقرار است و فقط شکل پیکربندی فرق می‌کند.

توپولوژی نمونه

	سایت ستون	سایت مقابل
نام Tunnel Endpoint	‏Tunnel Endpoint A	‏Tunnel Endpoint B
‏IP داخلی Tunnel Endpoint	192.168.50.224	172.16.0.1
‏IP خارجی Tunnel Endpoint	185.248.32.39	203.0.113.10
سابنت داخلی	192.168.50.0/24	172.16.0.0/16
ماشین نمونه داخل سابنت	192.168.50.11	172.16.0.5

نکته‌ی کلیدی: بودن پشت NAT یک‌به‌یک مشکلی ایجاد نمی‌کند

بسیاری از کاربران تصور می‌کنند چون ماشین آن‌ها IP خارجی را مستقیماً روی اینترفیس ندارد، امکان برپایی تانل وجود ندارد. این تصور درست نیست.

در ستون، دسترسی ماشین به اینترنت از طریق یک نگاشت یک‌به‌یک (One-to-One NAT) بین IP داخلی و IP خارجی انجام می‌شود. این نگاشت کامل و دوطرفه است؛ یعنی هر بسته‌ای که به IP خارجی برسد بدون تغییر به IP داخلی تحویل داده می‌شود و برعکس. پورت‌ها دست‌کاری نمی‌شوند و پروتکل هم تغییر نمی‌کند. بنابراین تانل بدون هیچ تنظیم اضافه‌ای برقرار می‌شود.

تنها چیزی که باید به آن دقت کنید، انتخاب درست دو مقدار local و remote از دید هر سمت است.

قاعده‌ی انتخاب local و remote

قاعده در یک جمله: هر سمت، آدرس محلی خودش را همان‌طور که روی اینترفیس می‌بیند می‌نویسد، و آدرس سمت مقابل را با IP خارجی آن می‌نویسد.

مقدار	روی Tunnel Endpoint A	روی Tunnel Endpoint B
‏local	192.168.50.224 — IP داخلی خودِ A	172.16.0.1 — IP داخلی خودِ B
‏remote	203.0.113.10 — IP خارجی سایت مقابل	185.248.32.39 — IP خارجی سایت ستون

هیچ سمتی IP خارجی خودش را نمی‌نویسد

در پیکربندی هر دو سمت، مقدار local باید آدرسی باشد که واقعاً روی اینترفیس آن ماشین پیکربندی شده و در خروجی ip addr دیده می‌شود. ‏Tunnel Endpoint A هرگز 185.248.32.39 را روی اینترفیس خود نمی‌بیند، پس اگر آن را به‌عنوان local بنویسید، تانل هرگز بالا نمی‌آید. NAT بین آدرس داخلی و خارجی را خودِ شبکه انجام می‌دهد.

اگر سمت مقابل هم پشت NAT باشد، دقیقاً همین قاعده برای او هم صدق می‌کند و باز هم مشکلی پیش نمی‌آید.

۱. مجاز کردن سابنت سایت مقابل در پنل

این گام پیش‌نیاز همه‌چیز است و باید پیش از پیکربندی تانل انجام شود.

‏Tunnel Endpoint A قرار است ترافیکی را جابه‌جا کند که متعلق به سابنت سایت مقابل است — نه مبدأ آن خودش است و نه مقصدش. تا زمانی که این Range را به «آدرس‌های قابل فوروارد» اینترفیس آن اضافه نکرده باشید، این ترافیک اصلاً به آن تحویل داده نمی‌شود و در tcpdump هیچ نشانی از آن نخواهید دید.

در پنل به مسیر زیر بروید:

سرویس‌های ستون › ماشین مجازی نسخه ۲ › لیست ماشین‌های مجازی › ‹Tunnel Endpoint A› › تب «شبکه»

در کارت «اینترفیس‌ها» و روی اینترفیس eth0، ردیف «آدرس‌های قابل فوروارد» را پیدا کنید و با دکمه‌ی + مقدار 172.16.0.0/16 را اضافه کنید.

توضیح کامل این قابلیت در بخش افزودن آدرس‌های قابل فوروارد آمده است.

گروه دسترسی امن

در همان کارت، گروه‌های دسترسی امن اینترفیس Tunnel Endpoint A باید پروتکل GRE را هم مجاز کنند. ‏GRE نه TCP است و نه UDP؛ یک پروتکل مستقل با شماره‌ی ۴۷ است. اگر این پروتکل مجاز نشده باشد، تانل حتی بالا نمی‌آید.

۲. ساخت تانل روی هر دو سمت

روی Tunnel Endpoint A:

sysctl -w net.ipv4.ip_forward=1
ip tunnel add gre1 mode gre local 192.168.50.224 remote 203.0.113.10 ttl 255
ip addr add 10.10.10.1/30 dev gre1
ip link set gre1 up

و روی Tunnel Endpoint B، همان پیکربندی به‌صورت متقارن:

ip tunnel add gre1 mode gre local 172.16.0.1 remote 185.248.32.39 ttl 255
ip addr add 10.10.10.2/30 dev gre1
ip link set gre1 up

آدرس 10.10.10.0/30 صرفاً یک Point to Point Network کوچک برای دو سر تانل است. مقدار آن اهمیتی ندارد، فقط نباید با هیچ‌کدام از سابنت‌های دو سمت هم‌پوشانی داشته باشد.

بررسی کنید: از Tunnel Endpoint A سمت دیگر تانل را پینگ کنید.

ping 10.10.10.2

اگر پاسخ نیامد، روی Tunnel Endpoint A ببینید بسته‌های تانل اصلاً رد و بدل می‌شوند یا نه:

tcpdump -ni eth0 proto gre

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

• هیچ بسته‌ای دیده نمی‌شود: تانل حتی تلاش نمی‌کند بسته بفرستد. معمولاً یعنی مقدار local روی اینترفیس وجود ندارد — همان اشتباه نوشتن IP خارجی به‌جای IP داخلی.
• فقط بسته‌های خروجی دیده می‌شود: بسته‌های شما می‌روند ولی پاسخی برنمی‌گردد. گروه دسترسی امن سمت ستون یا پیکربندی و دیوار آتش سمت مقابل را بررسی کنید.
• بسته‌های رفت و برگشت دیده می‌شود ولی ping جواب نمی‌دهد: آدرس‌دهی دو سر تانل را بررسی کنید؛ باید در یک شبکه باشند.

۳. افزودن Route به سابنت سایت مقابل

تا اینجا فقط دو سر تانل به هم می‌رسند. حالا باید مشخص کنید که ترافیک سابنت سایت مقابل از داخل تانل عبور کند.

روی Tunnel Endpoint A:

ip route add 172.16.0.0/16 dev gre1

روی Tunnel Endpoint B، Route بازگشت:

ip route add 192.168.50.0/24 dev gre1

و روی ماشین‌های داخل سابنت ستون، فقط یک Route لازم است تا بدانند مسیر رسیدن به سایت مقابل از طریق Tunnel Endpoint A است:

ip route add 172.16.0.0/16 via 192.168.50.224

اینجا SNAT لازم نیست

برخلاف سناریوی خروج به اینترنت، ترافیک این تانل نباید SNAT شود؛ چون در آن صورت ماشین‌های سایت مقابل نمی‌فهمند درخواست از کدام ماشین آمده است. همین است که «آدرس‌های قابل فوروارد» را در این سناریو ضروری می‌کند: ترافیک باید با Source IP اصلی خودش عبور کند و شبکه باید از پیش بداند که این کار مجاز است.

بررسی کنید: از یک ماشین داخل سابنت ستون (192.168.50.11) یک ماشین در سایت مقابل (172.16.0.5) را پینگ کنید و همزمان روی Tunnel Endpoint A دو دستور زیر را در دو ترمینال جداگانه اجرا کنید:

tcpdump -ni gre1

tcpdump -ni eth0 proto gre

مقایسه‌ی این دو، مشکل را دقیقاً مشخص می‌کند:

• در gre1 چیزی دیده نمی‌شود: بسته اصلاً وارد تانل نشده. Route روی Tunnel Endpoint A و روی ماشین فرستنده را بررسی کنید و مطمئن شوید Range 172.16.0.0/16 در «آدرس‌های قابل فوروارد» اضافه شده است.
• در gre1 دیده می‌شود ولی در eth0 بسته‌ی GRE خارج نمی‌شود: مشکل از خود تانل است، به گام قبل برگردید.
• بسته‌ی پاسخ در gre1 دیده می‌شود ولی به ماشین فرستنده نمی‌رسد: Range سابنت سایت مقابل در «آدرس‌های قابل فوروارد» ثبت نشده است. به گام ۱ برگردید.

۴. تنظیم MTU

هر بسته‌ای که وارد تانل GRE می‌شود ۲۴ بایت سربار اضافه می‌گیرد. اگر MTU را تنظیم نکنید، بسته‌های بزرگ در مسیر گم می‌شوند.

نشانه‌ی این مشکل بسیار مشخص است: ping به‌درستی کار می‌کند و اتصال اولیه‌ی SSH هم برقرار می‌شود، اما انتقال فایل، صفحات وب سنگین یا خروجی‌های طولانی در میانه‌ی کار قفل می‌شوند.

روی هر دو سمت تانل:

ip link set gre1 mtu 1476

و برای اینکه ارتباط‌های TCP خودشان اندازه‌ی مناسب را انتخاب کنند:

iptables -t mangle -A FORWARD -o gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

بررسی کنید: با یک بسته‌ی بزرگ و بدون اجازه‌ی تکه‌تکه شدن تست کنید.

ping -M do -s 1448 172.16.0.5

اگر این دستور پاسخ گرفت، MTU درست تنظیم شده است.

نکات مهم

‏GRE ترافیک را رمزنگاری نمی‌کند

بسته‌های عبوری از تانل GRE به‌صورت متن ساده از اینترنت عبور می‌کنند. اگر داده‌های شما محرمانه هستند، باید روی این تانل از IPsec استفاده کنید یا به‌جای GRE سراغ یک راهکار رمزنگاری‌شده بروید.

ماندگاری تنظیمات

دستورهای ip tunnel، ip route، ip link، sysctl -w و iptables در این راهنما موقتی هستند و پس از راه‌اندازی مجدد ماشین از بین می‌روند. پس از اطمینان از درستی پیکربندی، آن‌ها را به‌شکل ماندگار در سیستم‌عامل خود ثبت کنید. در مقابل، «آدرس‌های قابل فوروارد» و «گروه دسترسی امن» تنظیمات سمت پنل هستند و باقی می‌مانند.

اگر سابنت دو سمت هم‌پوشانی داشته باشند (مثلاً هر دو 192.168.50.0/24 باشند) Routeها دچار تداخل می‌شوند و ارتباط برقرار نخواهد شد. پیش از راه‌اندازی تانل از متفاوت بودن Range آدرس دو سمت مطمئن شوید.