Vagrant VM zmizne pri pripojení VPN: čia trasa sa zlomila

Stroj pred minútou odpovedal, VPN sa pripojila a teraz rovnaká adresa končí časovým limitom. Tri poruchy dávajú tento príznak a sídlia na rôznych strojoch. Hostiteľ môže stratiť trasu do privátnej siete, rozsah NAT hosťa sa môže zraziť s rozsahom, ktorý tunel teraz inzeruje, alebo plný tunel môže prevziať vlastníctvo každej trasy na hostiteľovi. Zistite, ktorá nastala, skôr než zmeníte akúkoľvek konfiguráciu, pretože každá oprava sídli inde.

Sledujte trasu, nie stroj

Pozrite sa na rozhodnutie hostiteľa o smerovaní pre adresu hosťa, kým je tunel aktívny. Trasa, ktorá stále ukazuje na adaptér iba pre hostiteľa, nie je problém. Trasa, ktorá teraz ukazuje na adaptér VPN, problém je, a zmenil ju klient, nie vy. To, že si adaptér zachováva adresu, hovorí, že rozhranie prežilo, čo je iný fakt než prežitie cesty.

Relácia SSH, ktorá spadne presne v okamihu pripojenia, je očakávané správanie. Klient recykluje adaptéry a inštaluje trasy, takže spojenie na niekoľko sekúnd umiera. Poruchou je spojenie, ktoré sa nikdy nevráti, nie to, ktoré len bliklo.

Zachyťte tabuľku pred tunelom a znova po ňom, potom tieto dva výstupy porovnajte. Rozdiel je diagnóza a zároveň dôkaz, ktorý si vyžiada správca siete.

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

Prečítajte tabuľku hostiteľa pred a po

V Linuxe preferencia medzi prekrývajúcimi sa trasami vychádza z dĺžky prefixu a metriky, takže konkrétnejšia trasa VPN vyhrá, aj keď je nesprávna. Vo Windows rozhoduje remízu metrika rozhrania a adaptér tunela zvyčajne prichádza s nižšou metrikou ako virtuálny. V oboch prípadoch je viditeľný príznak rovnaký: pakety odchádzajú cez adaptér tunela a miznú.

Vypíšte adaptéry a ich metriky vedľa trasy pre prefix hosťa. Táto dvojica výstupov odpovie na otázku vlastníctva na jeden pohľad.

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

Ak sa trasa zmenila, ale metrika adaptéra nie, klient nainštaloval konkurenčnú trasu. Ak sa metrika zmenila, klient preusporiadal adaptéry. Obe sa dajú opraviť a opravujú sa na rôznych miestach.

Keď je zrážkou rozsah NAT hosťa

VirtualBox NAT používa predvolene 10.0.2.0/24 a tunel, ktorý tlačí rovnaký rozsah, núti hosťa posielať túto prevádzku na svoju bránu NAT namiesto skutočného cieľa. Paket nikdy neopustí hostiteľa, takže ho neukáže žiadny log firewallu na druhej strane. Docker Machine má rovnakú triedu konfliktu vo svojom pláne iba pre hostiteľa a zmena tohto plánu môže vyžadovať opätovné vytvorenie stroja spolu s jeho certifikátmi.

Vyberte náhradu tak, že vypíšete, čo tunel už inzeruje, potom čo používa kancelárska sieť a potom čo si nárokoval každý virtuálny adaptér na tomto hostiteľovi. Smerovanie láme prekrytie a podobnosť je nepodstatná. Jeden rozsah môže celý sedieť vnútri iného, pričom na prvý pohľad nevyzerajú vôbec podobne.

Nastavte nový rozsah pri vytváraní stroja, alebo ho zmeňte a znova načítajte, a potom z hosťa znova otestujte zlyhávajúce spojenie. Vlastná tabuľka hosťa je pohľad, na ktorom záleží.

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

Obnovte cestu bez boja s klientom

Každá platforma ponúka spôsob, ako vrátiť prefix iba pre hostiteľa dopredu. V macOS funguje statická trasa k rozhraniu iba pre hostiteľa do nasledujúceho pripojenia. Vo Windows udržiava nižšia metrika rozhrania na virtuálnom adaptéri jeho prednosť. V Linuxe operácia nahradenia pokrýva jediný prefix. Všetky tri sú obchádzky, pretože klient, ktorý znova presadzuje svoje trasy, ich zruší.

Skriptujte kontrolu namiesto slepého opätovného pripojenia pri štarte. Malý skript, ktorý po každom pripojení vypíše trasu pre prefix hosťa, mení záhadu na riadok v logu.

Ak je profil plný tunel, požiadajte správcu siete o rozdelený tunel alebo zdokumentovanú výnimku. Ticho pridávať trasy, ktoré obchádzajú bezpečnostnú politiku, nie je oprava, ale druhý problém, ktorý dorazí neskôr s audítorom.

Overte opravu na oboch stranách

Po zmene overte tri cesty: hostiteľ k hosťovi, hosť ku korporátnemu hostiteľovi a hosť k internetu. Oprava, ktorá jednu obnoví a inú pokazí, je zmena konfigurácie vydávajúca sa za opravu. Zachyťte rovnaké výstupy, ktoré ste nazbierali pred zmenou, aby porovnanie bolo ako s ako.

Zaznamenajte rozhranie, metriku a trasu, ktoré sa zmenili, spolu s časom, aby ďalší výskyt bol vyhľadaním, nie prestavbou. Tá poznámka má väčšiu cenu než dlhé vlákno v tikete.

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

Keď hostiteľ znova dosiahne hosťa a hosť dosiahne LAN, obnovili ste cestu, s ktorou ste začali. Keď funguje len jedno z toho, zostávajúca porucha je na území druhého vlastníka a rozdiel vám povie, ktoré územie to je.