تونل برپاست، اینترنت نیست: بازفرست در کجا می‌ایستد

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

تأیید کنید که خروج به اینترنت از آغاز طرح بوده است

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

آنچه کارخواه نصب می‌کند همیشه همان نیست که نمایه در نظر دارد. یک مسیر محلی با متریک کمتر می‌تواند بر مسیر هل‌داده‌شده چیره شود، و کارخواهی که مسیر LAN خود را نگه می‌دارد و هم‌زمان مسیر پیش‌فرض می‌افزاید، برای آن زیرشبکه مانند تونل تقسیم‌شده رفتار می‌کند.

یک درخواست عمومی را دنبال کنید

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

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

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

بازفرست، مسیر و ترجمه را بررسی کنید

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

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

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

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

مسیر پاسخ و حل‌کننده دو پاسخ متفاوت‌اند

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

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

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