Vagrant VM nestaje kada se VPN poveže: čija se ruta pokvarila

Mašina je prije minute odgovarala, VPN se povezao, a sada ista adresa ne odgovara. Tri kvara daju taj simptom i oni žive na različitim mašinama. Host može izgubiti rutu do privatne mreže, NAT raspon gosta može se sudariti s rasponom koji tunel sada oglašava, ili puni tunel može preuzeti vlasništvo nad svakom rutom na hostu. Utvrdite koji se dogodio prije nego promijenite bilo koju konfiguraciju, jer svaki popravak živi na drugom mjestu.

Gledajte rutu, ne mašinu

Pogledajte odluku hosta o rutiranju za adresu gosta dok je tunel aktivan. Ruta koja još pokazuje na adapter samo za host nije problem. Ruta koja sada pokazuje na VPN adapter jest problem, a promijenio ju je klijent, ne vi. To što adapter zadržava svoju adresu govori da je interfejs preživio, što je drugačija činjenica od preživljavanja puta.

SSH sesija koja padne tačno u trenutku povezivanja je očekivano ponašanje. Klijent reciklira adaptere i instalira rute, pa veza umre na nekoliko sekundi. Kvar je veza koja se nikad ne vrati, a ne ona koja je samo trepnula.

Snimite tabelu prije tunela i ponovo poslije njega, a zatim uporedite ta dva izlaza. Razlika je dijagnoza, a ujedno je i dokaz koji će vlasnik mreže tražiti.

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

Pročitajte tabelu hosta prije i poslije

Na Linuxu prednost između ruta koje se preklapaju dolazi od dužine prefiksa i metrike, pa konkretnija VPN ruta pobjeđuje čak i kada je pogrešna. Na Windowsu metriku interfejsa odlučuje izjednačenje, a tunelski adapter obično dolazi s nižom metrikom od virtualnog. U oba slučaja vidljivi simptom je identičan: paketi izlaze kroz tunelski adapter i nestaju.

Ispišite adaptere i njihove metrike pored rute za prefiks gosta. Taj par izlaza odgovara na pitanje vlasništva jednim pogledom.

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

Ako se ruta promijenila a metrika adaptera nije, klijent je instalirao konkurentsku rutu. Ako se metrika promijenila, klijent je preuredio adaptere. Oboje je popravljivo i popravlja se na različitim mjestima.

Kada je NAT raspon gosta sudar

VirtualBox NAT prema zadanim postavkama koristi 10.0.2.0/24, a tunel koji gura isti raspon tjera gosta da taj promet šalje svom NAT gejtveju umjesto pravom odredištu. Paket nikad ne napušta host, pa ga nijedan zapis firewall-a s druge strane neće pokazati. Docker Machine ima istu klasu sukoba u svom planu samo za host, a promjena tog plana može zahtijevati ponovno kreiranje mašine zajedno s njezinim certifikatima.

Odaberite zamjenu tako što ćete popisati šta tunel već oglašava, zatim šta koristi kancelarijska mreža, a zatim šta je tvrdio svaki virtualni adapter na ovom hostu. Preklapanje je ono što kvari rutiranje, a sličnost je nevažna. Jedan raspon može u potpunosti sjediti unutar drugog dok na prvi pogled ne liči nimalo.

Postavite novi raspon kada se mašina kreira, ili ga promijenite i ponovo učitajte, pa zatim ponovo testirajte neuspjelu vezu s gosta. Gostova vlastita tabela je pogled koji je važan.

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

Vratite put bez svađe s klijentom

Svaka platforma nudi način da se prefiks samo za host vrati naprijed. Na macOS-u statična ruta do interfejsa samo za host radi do sljedećeg povezivanja. Na Windowsu niža metrika interfejsa na virtualnom adapteru održava ga preferiranim. Na Linuxu operacija zamjene pokriva jedan prefiks. Sve tri su privremena rješenja, jer klijent koji ponovo nameće svoje rute će ih poništiti.

Skriptujte provjeru umjesto slijepog ponovnog povezivanja pri pokretanju. Mala skripta koja ispiše rutu za prefiks gosta nakon svakog povezivanja pretvara misteriju u red u zapisu.

Ako je profil puni tunel, zatražite od vlasnika mreže podijeljeni tunel ili dokumentovanu iznimku. Tiho dodavanje ruta koje zaobilaze sigurnosnu politiku nije popravak, to je drugi problem koji kasnije dolazi s auditorom.

Provjerite popravak s obje strane

Provjerite tri puta nakon promjene: host do gosta, gost do korporativnog hosta i gost do interneta. Popravak koji vraća jedan od njih i kvari drugi je promjena konfiguracije prerušena u popravak. Snimite iste izlaze koje ste prikupili prije promjene da poređenje bude jednako s jednakim.

Zabilježite interfejs, metriku i rutu koja se promijenila, zajedno s vremenom, da sljedeći slučaj bude pretraga, a ne ponovna izgradnja. Ta bilješka vrijedi više od dugog niza tiketa.

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

Kada host ponovo dosegne gosta i gost dosegne LAN, vratili ste put s kojim ste počeli. Kada radi samo jedno od toga, preostali kvar je na teritoriji drugog vlasnika, a razlika vam kaže koja je to teritorija.