Vagrant-VM katoaa, kun VPN yhdistää: kenen reitti katkesi

Kone vastasi minuutti sitten, VPN yhdisti ja nyt sama osoite aikakatkaistaan. Kolme vikaa tuottaa tuon oireen, ja ne asuvat eri koneilla. Isäntä voi menettää reitin yksityisverkkoon, vieraan NAT-alue voi törmätä alueeseen, jonka tunneli nyt ilmoittaa, tai täystunneli voi ottaa omistukseensa jokaisen reitin isännällä. Selvitä, mikä niistä tapahtui ennen kuin muutat mitään asetusta, koska jokainen korjaus asuu eri paikassa.

Seuraa reittiä, älä konetta

Katso isännän reitityspäätöstä vieraan osoitteelle, kun tunneli on pystyssä. Reitti, joka osoittaa edelleen vain isäntä -sovittimeen, ei ole ongelma. Reitti, joka osoittaa nyt VPN-sovittimeen, on ongelma, ja asiakasohjelma muutti sen, ei sinä. Se, että sovitin pitää osoitteensa, kertoo että liitäntä selvisi, mikä on eri asia kuin polun selviäminen.

SSH-istunto, joka katkeaa täsmälleen yhdistämishetkellä, on odotettua käytöstä. Asiakasohjelma kierrättää sovittimia ja asentaa reittejä, joten yhteys katkeaa muutamaksi sekunniksi. Vika on yhteys, joka ei koskaan palaa, ei se joka vain välähti.

Tallenna taulukko ennen tunnelia ja uudelleen sen jälkeen ja vertaa sitten näitä kahta tulostetta. Ero on diagnoosi, ja se sattuu olemaan myös todiste, jota verkon omistaja pyytää.

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

Lue isännän taulukko ennen ja jälkeen

Linuxissa päällekkäisten reittien etusija tulee etuliitteen pituudesta ja metriikasta, joten tarkempi VPN-reitti voittaa, vaikka se olisi väärä. Windowsissa liitännän metriikka ratkaisee tasapelin, ja tunnelisovitin saapuu yleensä pienemmällä metriikalla kuin virtuaalinen. Kummassakin tapauksessa näkyvä oire on sama: paketit lähtevät tunnelisovittimen kautta ja katoavat.

Tulosta sovittimet ja niiden metriikat vieraan etuliitteen reitin viereen. Tämä tulostepari vastaa omistuskysymykseen yhdellä silmäyksellä.

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

Jos reitti muuttui mutta sovittimen metriikka ei, asiakasohjelma asensi kilpailevan reitin. Jos metriikka muuttui, asiakasohjelma järjesti sovittimet uudelleen. Molemmat ovat korjattavissa, ja ne korjataan eri paikoissa.

Kun vieraan NAT-alue on törmäys

VirtualBox NAT käyttää oletuksena aluetta 10.0.2.0/24, ja tunneli, joka työntää saman alueen, saa vieraan lähettämään liikenteen NAT-yhdyskäytävälleen todellisen kohteen sijaan. Paketti ei koskaan poistu isännältä, joten mikään palomuuriloki toisella puolella ei näytä sitä. Docker Machinella on sama konfliktiluokka vain isäntä -suunnitelmassaan, ja sen suunnitelman muuttaminen voi vaatia koneen luomisen uudelleen sertifikaatteineen.

Valitse korvaava alue listaamalla, mitä tunneli jo ilmoittaa, sitten mitä toimiston verkko käyttää ja sitten mitä jokainen tämän isännän virtuaalisovitin on vaatinut. Päällekkäisyys rikkoo reitityksen, ja samankaltaisuus on merkityksetöntä. Yksi alue voi istua kokonaan toisen sisällä, vaikka ensi silmäyksellä ne eivät näytä lainkaan samalta.

Aseta uusi alue, kun kone luodaan, tai muuta sitä ja lataa uudelleen, ja testaa sitten epäonnistuva yhteys uudelleen vieraasta. Vieraan oma taulukko on se näkymä, jolla on merkitystä.

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

Palauta polku taistelematta asiakasohjelman kanssa

Jokainen alusta tarjoaa tavan tuoda vain isäntä -etuliite takaisin eteen. macOS:ssa staattinen reitti vain isäntä -liitäntään toimii seuraavaan yhteyteen asti. Windowsissa pienempi liitännän metriikka virtuaalisovittimella pitää sen etusijalla. Linuxissa korvausoperaatio kattaa yhden etuliitteen. Kaikki kolme ovat kiertoteitä, koska asiakasohjelma, joka vaatii reittinsä uudelleen, kumoaa ne.

Kirjoita tarkistus skriptiksi eikä sokeaksi uudelleenyhdistämiseksi käynnistyksessä. Pieni skripti, joka tulostaa vieraan etuliitteen reitin jokaisen yhteyden jälkeen, muuttaa mysteerin lokiriviksi.

Jos profiili on täystunneli, pyydä verkon omistajalta jaettua tunnelointia tai dokumentoitua poikkeusta. Reittien hiljainen lisääminen, jotka kiertävät turvallisuuskäytäntöä, ei ole korjaus vaan toinen ongelma, joka saapuu myöhemmin auditoijan kanssa.

Tarkista korjaus molemmilta puolilta

Tarkista kolme polkua muutoksen jälkeen: isäntä vieraaseen, vieras yrityksen isäntään ja vieras internetiin. Korjaus, joka palauttaa yhden ja rikkoo toisen, on asetusmuutos korjauksen valepuvussa. Tallenna samat tulosteet, jotka keräsit ennen muutosta, jotta vertailu on samanlaista samanlaiseen.

Kirjaa liitäntä, metriikka ja muuttunut reitti sekä aika, jotta seuraava kerta on haku eikä uudelleenrakennus. Se muistiinpano on arvokkaampi kuin pitkä tikettiketju.

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

Kun isäntä tavoittaa jälleen vieraan ja vieras tavoittaa lähiverkon, olet palauttanut polun, jolla aloitit. Kun vain toinen niistä toimii, jäljellä oleva vika on toisen omistajan alueella, ja ero kertoo sinulle, mikä alue se on.