Vagrant-VM verdwyn wanneer die VPN koppel: wie se roete het gebreek

Die boks het 'n minuut gelede geantwoord, die VPN het gekoppel, en nou is dieselfde adres onbereikbaar. Drie foute lewer daardie simptoom, en hulle sit op verskillende masjiene. Die gasheer kan die roete na die private netwerk verloor, die gas se NAT-reeks kan bots met 'n reeks wat die tonnel nou adverteer, of 'n volle tonnel kan die eienaarskap van elke roete op die gasheer oorneem. Vind uit watter een gebeur het voordat jy enige konfigurasie verander, want elke oplossing sit op 'n ander plek.

Kyk na die roete, nie na die boks nie

Kyk na die gasheer se roetebesluit vir die gas se adres terwyl die tonnel op is. 'n Roete wat steeds na die slegs-gasheer-adapter wys, is nie die probleem nie. 'n Roete wat nou na die VPN-adapter wys, is die probleem, en die kliënt het dit verander, nie jy nie. Die feit dat die adapter sy adres behou, sê die koppelvlak het oorleef, wat 'n ander feit is as dat die pad oorleef het.

'n SSH-sessie wat presies op die oomblik van koppeling val, is verwagte gedrag. Die kliënt hergebruik adapters en installeer roetes, so die verbinding sterf vir 'n paar sekondes. Die fout is die verbinding wat nooit terugkom nie, nie die een wat net geblink het nie.

Neem die tabel voor die tonnel en weer daarna vas, en vergelyk dan daardie twee uitsette. Die verskil is die diagnose, en dit is ook toevallig die bewyse wat 'n netwerkeienaar sal vra.

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

Lees die gasheer se tabel voor en ná die verbinding

Op Linux kom die voorkeur tussen oorvleuelende roetes van voorvoegsellengte en metrieke waarde, so 'n meer spesifieke VPN-roete wen selfs wanneer dit verkeerd is. Op Windows beslis die koppelvlak-metriek die gelykop, en die tonnel-adapter kom gewoonlik met 'n laer metrieke waarde as die virtuele een. In albei gevalle is die sigbare simptoom identies: pakkette verlaat die gasheer deur die tonnel-adapter en verdwyn.

Druk die adapters en hulle metrieke waarde langs die roete vir die gas se voorvoegsel. Daardie paar uitsette beantwoord die eienaarskapvraag met een oogopslag.

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

As die roete verander het maar die adapter se metrieke waarde nie, het die kliënt 'n mededingende roete geïnstalleer. As die metrieke waarde verander het, het die kliënt die adapters herrangskik. Albei is regmaakbaar, en hulle word op verskillende plekke reggemaak.

Wanneer die gas se NAT-reeks die botsing is

VirtualBox NAT gebruik by verstek 10.0.2.0/24, en 'n tonnel wat dieselfde reeks stoot, laat die gas daardie verkeer na sy NAT-gateway stuur in plaas van na die werklike bestemming. Die pakket verlaat nooit die gasheer nie, so geen firewall-log aan die oorkant sal dit wys nie. Docker Machine het dieselfde klas konflik in sy slegs-gasheer-plan, en om daardie plan te verander kan vereis dat die masjien saam met sy sertifikate herskep word.

Kies die vervanging deur te lys wat die tonnel reeds adverteer, dan wat die kantoornetwerk gebruik, en dan wat elke virtuele adapter op hierdie gasheer geëien het. Oorvleueling is wat roetering breek, en ooreenkoms is irrelevant. Een reeks kan heeltemal binne 'n ander sit terwyl dit met 'n oogopslag heeltemal anders lyk.

Stel die nuwe reeks toe wanneer die masjien geskep word, of verander dit en herlaai, en toets dan weer die mislukkende verbinding van die gas af. Die gas se eie tabel is die siening wat saak maak.

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 die pad sonder om met die kliënt te baklei

Elke platform bied 'n manier om die slegs-gasheer-voorvoegsel weer voor te plaas. Op macOS werk 'n statiese roete na die slegs-gasheer-koppelvlak tot die volgende verbinding. Op Windows hou 'n laer koppelvlak-metriek op die virtuele adapter dit verkies. Op Linux dek 'n vervangingsbewerking 'n enkele voorvoegsel. Al drie is noodoplossings, want 'n kliënt wat sy roetes weer bevestig, sal hulle ongedaan maak.

Skryf die kontrole as 'n script eerder as 'n blinde herverbinding by die opstart. 'n Klein script wat die roete vir die gas se voorvoegsel ná elke verbinding druk, maak van 'n raaisel 'n reël in 'n log.

As die profiel 'n volle tonnel is, vra die netwerkeienaar om gesplete tonneling of 'n gedokumenteerde uitsondering. Om stilweg roetes by te voeg wat 'n sekuriteitsbeleid omseil, is nie 'n oplossing nie, dit is 'n tweede probleem wat later saam met 'n ouditeur opdaag.

Kontroleer die oplossing aan beide kante

Verifieer drie paaie ná die verandering: gasheer na gas, gas na die korporatiewe gasheer, en gas na die internet. 'n Oplossing wat een daarvan herstel en 'n ander breek, is 'n konfigurasieverandering wat hom as 'n herstel voordoen. Neem dieselfde uitsette vas wat jy voor die verandering versamel het, sodat die vergelyking soortgelyk aan soortgelyk is.

Teken die koppelvlak, die metrieke waarde en die roete wat verander het aan, saam met die tyd, sodat die volgende gebeurtenis 'n naslaan is eerder as 'n herbou. Daardie nota is meer werd as 'n lang kaartjie-draad.

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 die gasheer weer by die gas uitkom en die gas by die LAN uitkom, het jy die pad herstel waarmee jy begin het. Wanneer net een van dié werk, is die oorblywende fout in die ander eienaar se gebied, en die verskil sê vir jou watter gebied dit is.