ماشین مجازی Vagrant هنگام اتصال VPN ناپدید می‌شود: مسیر خراب مال کیست

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

مسیر را ببینید، نه ماشین را

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

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

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

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

جدول میزبان را پیش و پس از اتصال بخوانید

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

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

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

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

وقتی محدوده NAT مهمان همان تصادم است

VirtualBox NAT به‌طور پیش‌فرض از 10.0.2.0/24 استفاده می‌کند، و تونلی که همان محدوده را هل می‌دهد باعث می‌شود مهمان آن ترافیک را به دروازه NAT خودش بفرستد نه به مقصد واقعی. بسته هرگز از میزبان بیرون نمی‌رود، پس هیچ گزارش دیوار آتش آن سوی مسیر آن را نشان نخواهد داد. Docker Machine همین رده تعارض را در طرح فقط میزبان خود دارد، و تغییر آن طرح می‌تواند بازساختن ماشین همراه با گواهی‌هایش را لازم کند.

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

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

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

مسیر را بدون جنگیدن با کلاینت بازگردانید

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

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

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

اصلاح را در هر دو سو بررسی کنید

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

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

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

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