کارخواه VPN مسیریابیشده به کارساز میرسد اما به میزبانهای LAN نمیرسد

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

پاسخ را دنبال کنید، نه درخواست را

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

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

مسیر بازگشت را جایی بگذارید که میزبانها نگاه میکنند

هر میزبان LAN از دروازه پیشفرض خود میپرسد، پس دروازه تنها دستگاهی است که باید بداند استخر تونل کجاست. یک مسیر ایستا آنجا اضافه کنید و هر میزبان مسیر درست را بدون دستکاری به ارث میبرد.

اگر دروازه نشانی خودش را به عنوان گزینه DHCP پخش میکند، مسیر را همانطور توزیع کنید تا ماشینهای تازه آن را خودکار بردارند. در غیر این صورت مسیر در یک پرونده پیکربندی زندگی میکند و در بازسازی بعدی ناپدید میشود.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

چرا NAT مبدأ به نظر میرسد آن را درست میکند

پوشاندن استخر کارخواهان پشت نشانی کارساز VPN مشکل را با حذف نشانی کارخواه از بسته برمیدارد. سپس پاسخها به کارساز برمیگردند که از پیش میداند چگونه به تونل برسد و همه چیز کار میکند. هزینه آن این است که میزبانهای داخلی دیگر نمیتوانند ببینند کارخواه کیست و هر اتصال به نظر میرسد از یک ماشین میآید.

این معاوضه گاهی درست است، مثلاً وقتی به دستگاه یک فروشنده نمیتوان مسیر ایستا داد. قاعده را از استخر کنونی گستردهتر نکنید، چون قاعدهای که برای /24 نوشته شده روزی که استخر به /16 بازشمارهگذاری شود دیگر منطبق نمیشود و نخستین نشانه دستهای از کارخواهان تازه است که وصل میشوند و به هیچ جا نمیرسند.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

مسیر ابری سه تنظیم لازم دارد

در یک VPC همان شکاف به شکلی دیگر برمیگردد، چون زیرشبکه هیچ مسیری برای محدوده کارخواهان ندارد. جدول مسیریابی به یک ورودی برای استخر تونل نیاز دارد که به واسط شبکه نمونه اشاره کند و واسط باید بررسی مبدأ و مقصد را خاموش داشته باشد تا سکو بستههایی را بپذیرد که مبدأشان نشانی خودش نیست. گروههای امنیتی و ACLهای شبکه هم باید استخر را در هر دو جهت بپذیرند.

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

بررسیها را به این ترتیب اجرا کنید

پیش از سرزنش مسیریابی، ارسال به جلو و سیاست پالایش را تأیید کنید، چون میزبانی که ارسال به جلو نکند به همان شکل خاموش شکست میخورد. سپس تنظیم مؤثر مسیر معکوس را روی واسطی که تونل را حمل میکند بخوانید، چون پالایهای سختگیر میتواند پاسخهایی را که از جهت غیرمنتظره میرسند دور بیندازد.

با یک ثبت روی میزبان LAN در حالی که کارخواه آن را پینگ میکند تمام کنید. درخواستی که بدون پاسخ متناظر میرسد مسیر بازگشت را اثبات میکند و درخواستی که هرگز نمیرسد خطا را به کارساز یا تونل برمیگرداند.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

بررسی مبدأ و مقصد در راهنمای واسط شبکه کشسان مستند شده است. آن را روی واسطی تنظیم کنید که واقعاً ترافیک تونل را حمل میکند، نه روی یک مبدل بیربط متصل به همان نمونه.