Vagrant VM mizí při připojení VPN: čí trasa se rozbila

Stroj před minutou odpovídal, VPN se připojila a nyní stejná adresa končí časovým limitem. Tři závady dávají tento příznak a sídlí na různých strojích. Hostitel může ztratit trasu do privátní sítě, rozsah NAT hosta se může srazit s rozsahem, který tunel nyní inzeruje, nebo plný tunel může převzít vlastnictví všech tras na hostiteli. Zjistěte, která z nich nastala, než změníte jakoukoli konfiguraci, protože každá oprava sídlí jinde.

Sledujte trasu, ne stroj

Podívejte se na rozhodnutí hostitele o směrování pro adresu hosta, dokud je tunel aktivní. Trasa, která stále ukazuje na adaptér pouze pro hostitele, není problém. Trasa, která nyní ukazuje na adaptér VPN, problém je, a změnil ji klient, ne vy. To, že si adaptér ponechává adresu, říká, že rozhraní přežilo, což je jiný fakt než přežití cesty.

Relace SSH, která spadne přesně v okamžiku připojení, je očekávané chování. Klient recykluje adaptéry a instaluje trasy, takže spojení na několik sekund umírá. Závadou je spojení, které se nikdy nevrátí, ne to, které bliklo.

Zachyťte tabulku před tunelem a znovu po něm, pak tyto dva výstupy porovnejte. Rozdíl je diagnóza a zároveň důkaz, který si správce sítě vyžádá.

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

Přečtěte tabulku hostitele před a po

V Linuxu preference mezi překrývajícími se trasami vychází z délky prefixu a metriky, takže konkrétnější trasa VPN vyhraje, i když je špatná. Ve Windows rozhoduje remízu metrika rozhraní a adaptér tunelu obvykle přichází s nižší metrikou než virtuální. V obou případech je viditelný příznak stejný: pakety odcházejí přes adaptér tunelu a mizí.

Vypište adaptéry a jejich metriky vedle trasy pro prefix hosta. Tahle dvojice výstupů odpoví na otázku vlastnictví na jeden pohled.

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

Pokud se trasa změnila, ale metrika adaptéru ne, klient nainstaloval konkurenční trasu. Pokud se metrika změnila, klient přeuspořádal adaptéry. Obě jsou opravitelné a opravují se na různých místech.

Když je srážkou rozsah NAT hosta

VirtualBox NAT používá ve výchozím nastavení 10.0.2.0/24 a tunel, který tlačí stejný rozsah, nutí hosta posílat tento provoz na svou bránu NAT místo na skutečné cílové místo. Paket nikdy neopustí hostitele, takže ho žádný log firewallu na druhé straně neukáže. Docker Machine má stejnou třídu konfliktu ve svém plánu pouze pro hostitele a změna tohoto plánu může vyžadovat znovuvytvoření stroje spolu s jeho certifikáty.

Vyberte náhradu tak, že vypíšete, co tunel už inzeruje, potom co používá kancelářská síť a potom co si nárokoval každý virtuální adaptér na tomto hostiteli. Směrování láme překryv a podoba je nepodstatná. Jeden rozsah může celý sedět uvnitř jiného, přičemž na první pohled vypadají úplně jinak.

Nastavte nový rozsah při vytváření stroje, nebo ho změňte a znovu načtěte, a pak z hosta znovu otestujte selhávající spojení. Vlastní tabulka hosta je pohled, na kterém 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, aniž byste bojovali s klientem

Každá platforma nabízí způsob, jak vrátit prefix pouze pro hostitele dopředu. V macOS funguje statická trasa k rozhraní pouze pro hostitele do příštího připojení. Ve Windows udržuje nižší metrika rozhraní na virtuálním adaptéru jeho přednost. V Linuxu operace nahrazení pokrývá jediný prefix. Všechny tři jsou náhradní řešení, protože klient, který znovu prosazuje své trasy, je zruší.

Skriptujte kontrolu místo slepého opětovného připojení při startu. Malý skript, který po každém připojení vypíše trasu pro prefix hosta, mění záhadu na řádek v logu.

Pokud je profil plný tunel, požádejte správce sítě o rozdělený tunel nebo zdokumentovanou výjimku. Tiše přidávat trasy, které obcházejí bezpečnostní politiku, není oprava, ale druhý problém, který dorazí později s auditorem.

Ověřte opravu na obou stranách

Po změně ověřte tři cesty: hostitel k hostovi, host ke korporátnímu hostiteli a host k internetu. Oprava, která jednu obnoví a jinou rozbije, je změna konfigurace vydávající se za opravu. Zachyťte stejné výstupy, které jste nasbírali před změnou, aby srovnání bylo jako s jako.

Zaznamenejte rozhraní, metriku a trasu, které se změnily, spolu s časem, aby příští výskyt byl vyhledáním, ne přestavbou. Tahle poznámka má větší cenu než dlouhé vlákno v tiketu.

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

Když hostitel znovu dosáhne hosta a host dosáhne LAN, obnovili jste cestu, se kterou jste začali. Když funguje jen jedno z toho, zbývající závada je na území druhého vlastníka a rozdíl vám řekne, které území to je.