Vagrant-VM verdwijnt wanneer de VPN verbindt: wiens route brak

De machine antwoordde een minuut geleden, de VPN verbond, en nu loopt hetzelfde adres in een time-out. Drie fouten veroorzaken dat symptoom, en ze zitten op verschillende machines. De host kan de route naar het privénetwerk verliezen, het NAT-bereik van de gast kan botsen met een bereik dat de tunnel nu aankondigt, of een volledige tunnel kan het eigendom van elke route op de host overnemen. Zoek uit welke is gebeurd voordat u enige configuratie wijzigt, want elke oplossing zit ergens anders.

Kijk naar de route, niet naar de machine

Kijk naar de routeringsbeslissing van de host voor het adres van de gast terwijl de tunnel actief is. Een route die nog naar de host-only-adapter wijst, is niet het probleem. Een route die nu naar de VPN-adapter wijst, is het probleem, en de client heeft die gewijzigd, niet u. Dat de adapter zijn adres houdt, zegt dat de interface het overleefde, wat een ander feit is dan dat het pad het overleefde.

Een SSH-sessie die precies op het verbindingsmoment wegvalt, is verwacht gedrag. De client hergebruikt adapters en installeert routes, dus de verbinding sterft een paar seconden. De fout is de verbinding die nooit terugkomt, niet degene die alleen knipperde.

Leg de tabel vast vóór de tunnel en nog eens erna, en vergelijk dan die twee uitvoer. Het verschil is de diagnose, en het is ook het bewijs dat een netwerkbeheerder zal vragen.

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

Lees de tabel van de host voor en na

Op Linux komt de voorkeur tussen overlappende routes uit prefixlengte en metriek, dus een specifiekere VPN-route wint zelfs als die onjuist is. Op Windows beslist de interfacemetriek de gelijkstand, en de tunneladapter komt meestal met een lagere metriek dan de virtuele. In beide gevallen is het zichtbare symptoom identiek: pakketten verlaten de host via de tunneladapter en verdwijnen.

Druk de adapters en hun metriek af naast de route voor het prefix van de gast. Dat paar uitvoer beantwoordt de eigendomsvraag met één blik.

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

Is de route gewijzigd maar de metriek van de adapter niet, dan heeft de client een concurrerende route geïnstalleerd. Is de metriek gewijzigd, dan heeft de client de adapters herordend. Beide zijn te herstellen, en ze worden op verschillende plaatsen hersteld.

Wanneer het NAT-bereik van de gast de botsing is

VirtualBox NAT gebruikt standaard 10.0.2.0/24, en een tunnel die hetzelfde bereik pusht, laat de gast dat verkeer naar zijn NAT-gateway sturen in plaats van naar de echte bestemming. Het pakket verlaat de host nooit, dus geen firewalllog aan de andere kant zal het tonen. Docker Machine heeft dezelfde klasse conflict in zijn host-only-plan, en dat plan wijzigen kan vereisen dat de machine opnieuw wordt aangemaakt, samen met haar certificaten.

Kies de vervanging door te noteren wat de tunnel al aankondigt, dan wat het kantoornetwerk gebruikt, en dan wat elke virtuele adapter op deze host heeft opgeëist. Overlap is wat de routering breekt, en gelijkenis is irrelevant. Eén bereik kan volledig binnen een ander liggen terwijl het op het eerste gezicht totaal niet lijkt.

Stel het nieuwe bereik in wanneer de machine wordt aangemaakt, of wijzig het en herlaad, en test dan de falende verbinding opnieuw vanaf de gast. De eigen tabel van de gast is de weergave die telt.

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

Herstel het pad zonder met de client te vechten

Elk platform biedt een manier om het host-only-prefix weer vooraan te zetten. Op macOS werkt een statische route naar de host-only-interface tot de volgende verbinding. Op Windows houdt een lagere interfacemetriek op de virtuele adapter die preferent. Op Linux dekt een vervangingsbewerking één prefix. Alle drie zijn workarounds, want een client die zijn routes opnieuw laat gelden, maakt ze ongedaan.

Script de controle in plaats van een blinde herverbinding bij het opstarten. Een klein script dat na elke verbinding de route voor het prefix van de gast afdrukt, maakt van een raadsel een regel in een log.

Is het profiel een volledige tunnel, vraag de netwerkbeheerder dan om split-tunneling of een gedocumenteerde uitzondering. Stilletjes routes toevoegen die een beveiligingsbeleid omzeilen is geen oplossing, het is een tweede probleem dat later met een auditor op de stoep komt.

Controleer de oplossing aan beide kanten

Verifieer drie paden na de wijziging: host naar gast, gast naar de bedrijfsmatige host en gast naar het internet. Een oplossing die er één herstelt en een andere breekt, is een configuratiewijziging vermomd als reparatie. Leg dezelfde uitvoer vast als vóór de wijziging, zodat de vergelijking gelijk met gelijk is.

Noteer de interface, de metriek en de gewijzigde route, samen met het tijdstip, zodat de volgende keer een opzoeking is en geen herbouw. Die notitie is meer waard dan een lange ticketthread.

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

Wanneer de host de gast weer bereikt en de gast het LAN bereikt, hebt u het pad hersteld waarmee u begon. Wanneer slechts één van beide werkt, ligt de resterende fout op het terrein van de andere eigenaar, en het verschil vertelt u welk terrein dat is.