Vagrant VM kaob VPN-i ühendamisel: kelle marsruut katki läks

Masin vastas minut tagasi, VPN ühendus ja nüüd sama aadress aegub. Kolm riket tekitavad selle sümptomi ja need elavad erinevates masinates. Host võib kaotada marsruudi privaatvõrku, külalise NAT-vahemik võib põrkuda kokku vahemikuga, mida tunnel nüüd kuulutab, või täistunnel võib võtta üle kõik marsruudid hostil. Tehke kindlaks, milline neist juhtus, enne kui muudate ükskõik millist seadistust, sest iga parandus elab mujal.

Jälgige marsruuti, mitte masinat

Vaadake hosti marsruutimisotsust külalise aadressi jaoks, kui tunnel on üleval. Marsruut, mis osutab endiselt ainult-hosti adapterile, ei ole probleem. Marsruut, mis osutab nüüd VPN-adapterile, on probleem, ja selle muutis klient, mitte teie. See, et adapter säilitab oma aadressi, ütleb, et liides jäi ellu, mis on erinev fakt tee ellujäämisest.

SSH-seanss, mis katkeb täpselt ühendamise hetkel, on oodatud käitumine. Klient ringleb adaptereid ja paigaldab marsruute, seega ühendus sureb mõneks sekundiks. Rike on ühendus, mis ei tule kunagi tagasi, mitte see, mis ainult vilkus.

Jäädvustage tabel enne tunnelit ja uuesti pärast seda, seejärel võrrelge neid kahte väljundit. Erinevus on diagnoos ja see on ühtlasi tõend, mida võrgu omanik küsib.

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

Lugege hosti tabelit enne ja pärast

Linuxis tuleb kattuvate marsruutide eelistus prefiksi pikkusest ja metrikast, seega konkreetsem VPN-marsruut võidab ka siis, kui see on vale. Windowsis otsustab viigi liidese metrika ja tunnel-adapter saabub tavaliselt madalama metrikaga kui virtuaalne. Mõlemal juhul on nähtav sümptom identne: paketid väljuvad tunnel-adapteri kaudu ja kaovad.

Printige adapterid ja nende metrikad külalise prefiksi marsruudi kõrvale. See väljundipaar vastab omandiküsimusele ühe pilguga.

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

Kui marsruut muutus, aga adapteri metrika mitte, paigaldas klient konkureeriva marsruudi. Kui metrika muutus, järjestas klient adapterid ümber. Mõlemad on parandatavad ja neid parandatakse erinevates kohtades.

Kui külalise NAT-vahemik on kokkupõrge

VirtualBox NAT kasutab vaikimisi 10.0.2.0/24 ja tunnel, mis surub sama vahemikku, paneb külalise saatma selle liikluse oma NAT-lüüsile, mitte tegelikule sihtkohale. Pakett ei lahku kunagi hostist, seega ükski tulemüüri logi teisel pool ei näita seda. Docker Machine'il on sama klass konflikti oma ainult-hosti plaanis ja selle plaani muutmine võib nõuda masina uuesti loomist koos selle sertifikaatidega.

Valige asendus, loetledes, mida tunnel juba kuulutab, seejärel mida kontorivõrk kasutab ja seejärel mida iga virtuaalne adapter sellel hostil on nõudnud. Marsruutimist lõhub kattuvus ja sarnasus on ebaoluline. Üks vahemik võib täielikult paikneda teise sees, samal ajal kui esmapilgul ei sarnane see üldse.

Määrake uus vahemik masina loomisel või muutke seda ja laadige uuesti, seejärel testige ebaõnnestuvat ühendust uuesti külalise poolt. Külalise enda tabel on vaade, mis loeb.

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

Taastage tee ilma kliendiga võitlemata

Iga platvorm pakub viisi, kuidas ainult-hosti prefiks uuesti ette tuua. macOS-is töötab staatiline marsruut ainult-hosti liidesele kuni järgmise ühenduseni. Windowsis hoiab madalam liidese metrika virtuaalsel adapteril seda eelistatuna. Linuxis katab asendustehing ühe prefiksi. Kõik kolm on ajutised lahendused, sest klient, kes oma marsruudid uuesti kehtestab, tühistab need.

Skriptige kontroll, mitte pime taastamine alglaadimisel. Väike skript, mis prindib pärast iga ühendust külalise prefiksi marsruudi, muudab mõistatuse logireaks.

Kui profiil on täistunnel, paluge võrgu omanikul jagatud tunnelit või dokumenteeritud erandit. Vaikselt marsruutide lisamine, mis mööduvad turvapoliitikast, ei ole parandus, vaid teine probleem, mis saabub hiljem koos audiitoriga.

Kontrollige parandust mõlemal poolel

Kontrollige pärast muudatust kolme teed: host külaliseni, külaline ettevõtte hostini ja külaline internetti. Parandus, mis taastab ühe neist ja rikub teise, on seadistusemuudatus, mis maskeerub remondiks. Jäädvustage samad väljundid, mille kogusite enne muudatust, et võrdlus oleks võrdne võrdsega.

Märkige üles liides, metrika ja muutunud marsruut koos ajaga, et järgmine kord oleks otsing, mitte ülesehitamine. See märkus on väärt rohkem kui pikk piletiahel.

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

Kui host jõuab uuesti külaliseni ja külaline jõuab LAN-ini, olete taastanud tee, millega alustasite. Kui töötab ainult üks neist, on ülejäänud rike teise omaniku territooriumil ja erinevus ütleb teile, milline territoorium see on.