کلاینت‌های VPN وصل می‌شوند اما اینترنت ندارند: سه قطعه گم‌شده

کلاینت نشانی می‌گیرد، سرور به ping پاسخ می‌دهد و با این حال هر صفحه از مهلت زمانی می‌گذرد. بیشتر مردم در این مرحله شروع به ویرایش پروفایل کلاینت می‌کنند که معمولاً تلاشی هدررفته است: وقتی تونل بالا آمد، سرور باید مانند یک روتر رفتار کند. سه شرط باید هم‌زمان برقرار باشند تا بسته‌ای خارج شود و پاسخی برگردد، و علامت بیماری یکسان است، هر کدام که گم باشد.

چرا یک تونل سالم هنوز راه خروج ندارد

کرنل باید بسته‌ها را میان رابط‌ها ارسال کند، که در بیشتر توزیع‌های Linux به‌طور پیش‌فرض خاموش است. ترافیک باید به نشانی‌ای ترجمه شود که دنیای بیرون بتواند پاسخ دهد، مگر اینکه هر روتر بالادستی از قبل مسیر بازگشت به زیرشبکه تونل را بداند. مسیر ارسال دیوار آتش باید ترافیک را در هر دو جهت، از جمله پاسخ‌ها، مجاز کند.

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

پس سه لایه را بیازمایید نه کلاینت را، و هر بار یکی را تغییر دهید تا نتیجه معنا داشته باشد.

ارسال کلیدی در کرنل است که باید پایدارش کنید

پیش از تغییر، مقدار کنونی را بررسی کنید، سپس آن را تنظیم کنید و تأیید کنید که تغییر اثر کرده است.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

فرمان نخست مقدار کنونی را گزارش می‌دهد، دومی آن را در زمان اجرا تنظیم می‌کند و سومی ثابت می‌کند که نوشتن کار کرده است. مقدار زمان اجرا در راه‌اندازی بعدی از میان می‌رود، و به همین دلیل نشستی که کار می‌کرد می‌تواند پس از تعمیرات، بدون هیچ تغییری در تنظیمات، بشکند.

آن را در فایلی زیر /etc/sysctl.d/ پایدار کنید، سپس همان فایل را به کار ببرید نه اینکه برای فهمیدن، راه‌اندازی دوباره کنید. در FreeBSD معادل آن net.inet.ip.forwarding است، با gateway_enable=YES در rc.conf برای پایداری. دستگاهی که ارسال را غیرفعال گزارش می‌کند، یک طبقه کامل از گزارش‌های «بسته‌ها می‌رسند و چیزی برنمی‌گردد» را توضیح می‌دهد. تنظیم را پس از هر ارتقا هم بررسی کنید، چون کرنل بازسازی‌شده یا تصویر دستگاهی که جایگزین شده می‌تواند بی‌آنکه به کسی بگوید آن را صفر کند.

masquerade یا یک نشانی ترجمه ثابت را برگزینید

با نشانی بیرونی پویا، masquerading ساده‌ترین شکل درست است. زیرشبکه تونل را به‌عنوان منبع و رابط بیرونی را به‌عنوان خروج نام ببرید.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

با نشانی عمومی ایستا، ترجمه منبع به همان نشانی دقیق پیش‌بینی‌پذیرتر و آسان‌تر برای حسابرسی است.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

شکل دوم دام نگهداری دارد: نشانی‌ای که سخت‌کد شده و بعداً تغییر می‌کند تونل را سرپا نگه می‌دارد در حالی که دسترسی به اینترنت بی‌صدا قطع می‌شود. یا از masquerade استفاده کنید یا هر بار که ارائه‌دهنده شما را جابه‌جا کرد قاعده را به‌روز کنید. رابط هم مهم است، چون روتری که تونل بالادستی خودش را شریک می‌شود باید از همان تونل ترجمه کند نه از WAN فیزیکی.

جدول فیلتر دروازه سوم است

ارسال و ترجمه می‌توانند هر دو درست باشند و بسته باز هم در جدول فیلتر بمیرد. ufw خطاکار مکرر است: سیاست ارسالش به‌صورت DROP عرضه می‌شود و بقیه پیکربندی می‌تواند کاملاً درست به نظر برسد در حالی که همان یک تنظیم ترافیک را می‌کشد. بالا بردن آن تصمیمی امنیتی و آگاهانه است نه یک جعبه انتخاب.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

تونل پل‌شده پاسخ دیگری می‌خواهد. نشانی به پل تعلق دارد نه به درگاه فیزیکی، پس به بردگی گرفتن رابط، نشانی‌ای را که پیش‌تر داشت برمی‌دارد و میزبان تا زمانی که خود پل نشانی نگیرد، که dhclient br0 می‌تواند فراهم کند، دسترس‌ناپذیر به نظر می‌رسد. آن خرابی شبیه مشکل VPN است و مشکلی در لایه دوم است. پیش از دست زدن به دیوار آتش، نشانی خود پل را بررسی کنید، چون تغییر فیلتر نمی‌تواند میزبانی را درست کند که دیگر نشانی‌ای برای فرستادن ندارد.

وقتی صفحه‌ای هرگز بار نمی‌شود کجا را ببینید

به نشانی تونل سرور ping بزنید تا ثابت کنید تونل وجود دارد. سپس traceroute را از کلاینت به نشانی عمومی اجرا کنید و بخوانید کجا می‌ایستد: در سرور بسته می‌رسد اما ارسال یا ترجمه نمی‌شود؛ آن‌سوی سرور مشکل بالادستی است و از دست شما خارج.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

فرمان نخست ثابت می‌کند تونل ترافیک را به خود سرور می‌برد و دومی نشان می‌دهد بسته تا کجا به بیرون می‌رسد. مسیری که در نشانی تونل پایان می‌یابد به ارسال یا ترجمه روی سرور اشاره دارد، در حالی که مسیری که یک گام بعدتر می‌ایستد به ارائه‌دهنده یا مسیر بازگشت روتر بالادستی اشاره دارد.

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

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