VM Vagrant izgine ob povezavi VPN: čigava pot se je zlomila

Stroj je odgovoril pred minuto, VPN se je povezal in zdaj isti naslov konča s časovno omejitvijo. Tri okvare dajejo ta simptom in živijo na različnih strojih. Gostitelj lahko izgubi pot v zasebno omrežje, obseg NAT gosta lahko trči ob obseg, ki ga tunel zdaj oglašuje, ali pa lahko celoten tunel prevzame lastništvo vsake poti na gostitelju. Ugotovite, katera se je zgodila, preden spremenite katero koli konfiguracijo, ker vsako popravilo živi drugje.

Glejte pot, ne stroja

Poglejte odločitev gostitelja o usmerjanju za naslov gosta, medtem ko je tunel aktiven. Pot, ki še vedno kaže na vmesnik samo za gostitelja, ni težava. Pot, ki zdaj kaže na vmesnik VPN, je težava, in spremenil jo je odjemalec, ne vi. To, da vmesnik obdrži naslov, pove, da je vmesnik preživel, kar je drugo dejstvo kot preživetje poti.

Seja SSH, ki pade točno v trenutku povezave, je pričakovano vedenje. Odjemalec reciklira vmesnike in namešča poti, zato povezava za nekaj sekund umre. Okvara je povezava, ki se nikoli ne vrne, ne tista, ki je le utripnila.

Zajemite tabelo pred tunelom in še enkrat po njem, nato primerjajte ta dva izhoda. Razlika je diagnoza in hkrati dokaz, ki ga bo zahteval lastnik omrežja.

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

Preberite tabelo gostitelja pred in po

V Linuxu prednost med prekrivajočimi se potmi izhaja iz dolžine predpone in metrike, zato bolj specifična pot VPN zmaga tudi, ko je napačna. V Windowsu neodločeno odloči metrika vmesnika, vmesnik tunela pa običajno pride z nižjo metriko kot virtualni. V obeh primerih je vidni simptom enak: paketi odidejo skozi vmesnik tunela in izginejo.

Izpišite vmesnike in njihove metrike poleg poti za predpono gosta. Ta par izhodov odgovori na vprašanje lastništva z enim pogledom.

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

Če se je pot spremenila, metrika vmesnika pa ne, je odjemalec namestil konkurenčno pot. Če se je metrika spremenila, je odjemalec prerazporedil vmesnike. Oboje je mogoče popraviti in popravi se na različnih mestih.

Ko je obseg NAT gosta trčenje

VirtualBox NAT privzeto uporablja 10.0.2.0/24, tunel, ki potiska isti obseg, pa prisili gosta, da ta promet pošlje svoji prehodni postaji NAT namesto pravemu cilju. Paket nikoli ne zapusti gostitelja, zato ga noben dnevnik požarnega zidu na drugi strani ne bo prikazal. Docker Machine ima isto vrsto konflikta v svojem načrtu samo za gostitelja, sprememba tega načrta pa lahko zahteva ponovno ustvarjanje stroja skupaj z njegovimi potrdili.

Izberite zamenjavo tako, da naštejete, kaj tunel že oglašuje, nato kaj uporablja pisarniško omrežje in nato kaj je zahteval vsak virtualni vmesnik na tem gostitelju. Usmerjanje zlomi prekrivanje, podobnost pa ni pomembna. En obseg lahko v celoti sedi znotraj drugega, čeprav na prvi pogled nista nič podobna.

Nastavite novi obseg ob ustvarjanju stroja ali ga spremenite in znova naložite, nato znova preizkusite neuspešno povezavo z gosta. Lastna tabela gosta je pogled, ki šteje.

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

Obnovite pot brez boja z odjemalcem

Vsaka platforma ponuja način, da predpono samo za gostitelja spet postavi naprej. V macOS statična pot do vmesnika samo za gostitelja deluje do naslednje povezave. V Windowsu nižja metrika vmesnika na virtualnem vmesniku ohranja njegovo prednost. V Linuxu operacija zamenjave pokrije eno predpono. Vse tri so nadomestne rešitve, ker odjemalec, ki znova uveljavlja svoje poti, jih bo razveljavil.

Skriptajte preverjanje namesto slepe ponovne povezave ob zagonu. Majhna skripta, ki po vsaki povezavi izpiše pot za predpono gosta, spremeni skrivnost v vrstico v dnevniku.

Če je profil celoten tunel, prosite lastnika omrežja za razdeljen tunel ali dokumentirano izjemo. Tiho dodajanje poti, ki obidejo varnostno politiko, ni popravilo, ampak druga težava, ki pride pozneje skupaj z revizorjem.

Preverite popravilo na obeh straneh

Po spremembi preverite tri poti: gostitelj do gosta, gost do korporativnega gostitelja in gost do interneta. Popravilo, ki eno obnovi in drugo pokvari, je sprememba konfiguracije, preoblečena v popravilo. Zajemite iste izhode, kot ste jih zbrali pred spremembo, da bo primerjava enaka z enakim.

Zabeležite vmesnik, metriko in pot, ki so se spremenili, skupaj s časom, da bo naslednji pojav iskanje in ne ponovna gradnja. Ta zapisek je vreden več kot dolga nit prijave.

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

Ko gostitelj znova doseže gosta in gost doseže LAN, ste obnovili pot, s katero ste začeli. Ko deluje le ena od teh, je preostala okvara na ozemlju drugega lastnika, razlika pa vam pove, katero ozemlje je to.