VPN ulanganda Vagrant VM yo'qoladi: buzilgan yo'l kimniki

Mashina bir daqiqa oldin javob berardi, VPN ulandi va endi o'sha manzil vaqt tugashi bilan yakunlanadi. Uch nosozlik bu alomatni keltiradi va ular turli mashinalarda yashaydi. Xost xususiy tarmoqqa boradigan yo'lni yo'qotishi mumkin, mehmonning NAT diapazoni tunnel endi e'lon qilayotgan diapazon bilan to'qnashishi mumkin, yoki to'liq tunnel xostdagi har bir yo'lning egaligini olishi mumkin. Har qanday konfiguratsiyani o'zgartirishdan oldin qaysi biri sodir bo'lganini aniqlang, chunki har bir tuzatish boshqa joyda yashaydi.

Yo'lni kuzating, mashinani emas

Tunnel ishlab turganda mehmon manzili uchun xostning marshrutlash qaroriga qarang. Hali ham faqat-xost adapteriga ishora qiladigan yo'l muammo emas. Endi VPN adapteriga ishora qiladigan yo'l muammo, va uni siz emas, mijoz o'zgartirgan. Adapter o'z manzilini saqlab qolishi interfeys tirik qolganini bildiradi, bu yo'lning tirik qolishidan boshqa fakt.

Aynan ulanish paytida uziladigan SSH sessiyasi kutilgan xatti-harakat. Mijoz adapterlarni qayta ishlatadi va yo'llarni o'rnatadi, shuning uchun aloqa bir necha soniya o'ladi. Nosozlik hech qachon qaytmaydigan aloqa, bir lahza miltillagan aloqa emas.

Tunneldan oldin jadvalni oling va keyin yana bir marta, so'ng bu ikki chiqishni solishtiring. Farqning o'zi tashxis, va u tarmoq egasi so'raydigan dalil ham.

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

Ulanishdan oldin va keyin xost jadvalini o'qing

Linuxda bir-birining ustiga tushadigan yo'llar orasidagi ustunlik prefiks uzunligi va metrikadan keladi, shuning uchun aniqroq VPN yo'li noto'g'ri bo'lsa ham yutadi. Windowsda interfeys metrikasi tenglikni hal qiladi va tunnel adapteri odatda virtualdan past metrika bilan keladi. Ikkala holatda ham ko'rinadigan alomat bir xil: paketlar tunnel adapteridan chiqib yo'qoladi.

Mehmon prefiksi yo'lining yonida adapterlar va ularning metrikalarini chop eting. O'sha chiqish juftligi egalik savoliga bir qarashda javob beradi.

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

Yo'l o'zgargan bo'lsa-da adapter metrikasi o'zgarmasa, mijoz raqobatchi yo'l o'rnatgan. Metrika o'zgargan bo'lsa, mijoz adapterlarni qayta tartiblagan. Ikkalasini ham tuzatish mumkin va ular turli joylarda tuzatiladi.

Mehmonning NAT diapazoni to'qnashuv bo'lganda

VirtualBox NAT standart bo'yicha 10.0.2.0/24 dan foydalanadi, va xuddi shu diapazonni itarib yuboradigan tunnel mehmonni o'sha trafikni haqiqiy manzilga emas, o'zining NAT darvozasiga yuborishga majbur qiladi. Paket hech qachon xostdan chiqmaydi, shuning uchun narigi tomondagi hech qanday firewall jurnali uni ko'rsatmaydi. Docker Machine ham o'zining faqat-xost rejasida shu turdagi ziddiyatga ega va bu rejani o'zgartirish mashinani sertifikatlari bilan birga qayta yaratishni talab qilishi mumkin.

O'rinbosarni tanlash uchun tunnel allaqachon nima e'lon qilayotganini, keyin ofis tarmog'i nimadan foydalanishini, keyin bu xostdagi har bir virtual adapter nimani talab qilganini sanab chiqing. Marshrutlashni buzadigan narsa qoplanish, o'xshashlikning ahamiyati yo'q. Bir diapazon ikkinchisining ichida to'liq joylashishi mumkin, lekin birinchi qarashda umuman o'xshamaydi.

Yangi diapazonni mashina yaratilayotganda belgilang yoki uni o'zgartirib qayta yuklang, so'ng mehmondan muvaffaqiyatsiz ulanishni qayta sinab ko'ring. Mehmonning o'z jadvali muhim ko'rinishdir.

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

Mijoz bilan urishmasdan yo'lni tiklang

Har bir platforma faqat-xost prefiksini yana oldinga chiqarish usulini taklif qiladi. macOSda faqat-xost interfeysiga statik yo'l keyingi ulanishgacha ishlaydi. Windowsda virtual adapterdagi pastroq interfeys metrikasi uni afzal holatda ushlab turadi. Linuxda almashtirish amali bitta prefiksni qamrab oladi. Uchtasi ham vaqtinchalik chora, chunki o'z yo'llarini qayta talab qiladigan mijoz ularni bekor qiladi.

Yuklanishda ko'r-ko'rona qayta ulanish o'rniga tekshiruvni skript qiling. Har bir ulanishdan keyin mehmon prefiksi yo'lini chop etadigan kichik skript jumboqni jurnaldagi satrga aylantiradi.

Agar profil to'liq tunnel bo'lsa, tarmoq egasidan bo'lingan tunnel yoki hujjatlashtirilgan istisno so'rang. Xavfsizlik siyosatini chetlab o'tadigan yo'llarni jimgina qo'shish tuzatish emas, keyinchalik auditor bilan keladigan ikkinchi muammo.

Tuzatishni ikki tomondan tekshiring

O'zgarishdan keyin uch yo'lni tekshiring: xostdan mehmonga, mehmondan korporativ xostga va mehmondan internetga. Birini tiklab boshqasini buzadigan tuzatish ta'mir niqobidagi konfiguratsiya o'zgarishidir. Taqqoslash teng-teng bo'lishi uchun o'zgarishdan oldin to'plangan o'sha chiqishlarni oling.

O'zgargan interfeys, metrika va yo'lni vaqt bilan birga yozib qo'ying, keyingi hodisa qayta qurish emas, qidiruv bo'lsin. Bu yozuv uzoq chiptalar zanjiridan qimmatroq.

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

Xost yana mehmonga yetib borsa va mehmon LANga yetib borsa, siz boshlagan yo'lni tikladingiz. Faqat bittasi ishlasa, qolgan nosozlik boshqa egasining hududida, va farq qaysi hudud ekanini aytadi.