VM-ul Vagrant dispare când VPN-ul se conectează: a cui este ruta ruptă

O mașină care răspundea acum un minut dispare în momentul conectării. Decideți a cui este ruta ruptă înainte de a schimba ceva.

Mașina răspundea acum un minut, VPN-ul s-a conectat și acum aceeași adresă depășește timpul. Trei defecte produc acel simptom și ele locuiesc pe mașini diferite. Gazda poate pierde ruta către rețeaua privată, intervalul NAT al invitatului poate intra în coliziune cu un interval pe care tunelul îl anunță acum, sau un tunel complet poate prelua proprietatea fiecărei rute de pe gazdă. Aflați care s-a întâmplat înainte de a schimba orice configurație, pentru că fiecare remediere locuiește în altă parte.

Priviți ruta, nu mașina

Priviți decizia de rutare a gazdei pentru adresa invitatului cât timp tunelul este activ. O rută care indică încă adaptorul doar-gazdă nu este problema. O rută care indică acum adaptorul VPN este problema, și clientul a schimbat-o, nu dumneavoastră. Faptul că adaptorul își păstrează adresa spune că interfața a supraviețuit, ceea ce este un fapt diferit de supraviețuirea căii.

O sesiune SSH care cade exact în momentul conectării este comportament așteptat. Clientul reciclează adaptoare și instalează rute, așa că conexiunea moare câteva secunde. Defectul este conexiunea care nu revine niciodată, nu cea care doar a clipit.

Capturați tabelul înainte de tunel și încă o dată după el, apoi comparați cele două ieșiri. Diferența este diagnosticul și este totodată dovada pe care o va cere proprietarul rețelei.

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

Citiți tabelul gazdei înainte și după

În Linux, preferința între rutele suprapuse vine din lungimea prefixului și din metrică, așa că o rută VPN mai specifică câștigă chiar și când este greșită. În Windows metrica interfeței decide egalitatea, iar adaptorul tunelului vine de obicei cu o metrică mai mică decât cel virtual. În ambele cazuri simptomul vizibil este identic: pachetele pleacă prin adaptorul tunelului și dispar.

Tipăriți adaptoarele și metricele lor lângă ruta pentru prefixul invitatului. Acea pereche de ieșiri răspunde la întrebarea proprietății dintr-o singură privire.

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

Dacă ruta s-a schimbat, dar metrica adaptorului nu, clientul a instalat o rută concurentă. Dacă metrica s-a schimbat, clientul a reordonat adaptoarele. Ambele sunt reparabile și se repară în locuri diferite.

Când intervalul NAT al invitatului este coliziunea

VirtualBox NAT folosește implicit 10.0.2.0/24, iar un tunel care împinge același interval face invitatul să trimită acel trafic către poarta sa NAT în loc de destinația reală. Pachetul nu părăsește niciodată gazda, așa că niciun jurnal de firewall de cealaltă parte nu îl va arăta. Docker Machine are aceeași clasă de conflict în planul său doar-gazdă, iar schimbarea acelui plan poate cere recrearea mașinii împreună cu certificatele ei.

Alegeți înlocuitorul listând ce anunță deja tunelul, apoi ce folosește rețeaua biroului, apoi ce a revendicat fiecare adaptor virtual de pe această gazdă. Suprapunerea este cea care rupe rutarea, iar asemănarea este irelevantă. Un interval poate sta complet în interiorul altuia fără să semene deloc la prima vedere.

Stabiliți noul interval când se creează mașina, sau schimbați-l și reîncărcați, apoi testați din nou conexiunea care eșuează din invitat. Tabelul invitatului însuși este vederea care contează.

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

Restabiliți calea fără să vă luptați cu clientul

Fiecare platformă oferă o modalitate de a readuce prefixul doar-gazdă în față. În macOS o rută statică către interfața doar-gazdă funcționează până la următoarea conectare. În Windows o metrică de interfață mai mică pe adaptorul virtual îl menține preferat. În Linux o operație de înlocuire acoperă un singur prefix. Toate trei sunt soluții de ocol, pentru că un client care își reafirmă rutele le va anula.

Scrieți verificarea ca script în loc de o reconectare oarbă la pornire. Un script mic care tipărește ruta pentru prefixul invitatului după fiecare conectare transformă un mister într-o linie de jurnal.

Dacă profilul este un tunel complet, cereți proprietarului rețelei un tunel divizat sau o excepție documentată. A adăuga în liniște rute care ocolesc o politică de securitate nu este o remediere, ci o a doua problemă care sosește mai târziu cu un auditor.

Verificați remedierea pe ambele părți

Verificați trei căi după schimbare: gazdă la invitat, invitat la gazda corporativă și invitat la internet. O remediere care restabilește una și rupe alta este o schimbare de configurație deghizată în reparație. Capturați aceleași ieșiri pe care le-ați adunat înainte de schimbare, ca comparația să fie egală cu egală.

Notați interfața, metrica și ruta care s-au schimbat, împreună cu ora, ca următoarea apariție să fie o căutare și nu o reconstrucție. Acea notă valorează mai mult decât un fir lung de tichete.

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

Când gazda ajunge din nou la invitat și invitatul ajunge la LAN, ați restabilit calea cu care ați început. Când doar una dintre ele funcționează, defectul rămas este pe teritoriul celuilalt proprietar, iar diferența vă spune care teritoriu este.

Articole similare