Vagrant-VM forsvinn når VPN-en koplar til: kven sin rute braut

Maskinen svara for eit minutt sidan, VPN-en kopla til, og no går same adresse i timeout. Tre feil gir det symptomet, og dei bur på ulike maskinar. Verten kan miste ruta til det private nettet, NAT-området til gjesten kan kollidere med eit område som tunnelen no annonserer, eller ein full tunnel kan ta over eigarskapet til kvar rute på verten. Finn ut kva som skjedde før du endrar nokon konfigurasjon, for kvar retting bur ein annan stad.

Sjå på ruta, ikkje på maskinen

Sjå på rutingsavgjerda til verten for gjesteadressa medan tunnelen er oppe. Ei rute som framleis peikar på berre-vert-adapteren, er ikkje problemet. Ei rute som no peikar på VPN-adapteren, er problemet, og det var klienten som endra ho, ikkje du. At adapteren held på adressa, fortel at grensesnittet overlevde, noko som er eit anna faktum enn at vegen overlevde.

Ein SSH-økt som fell nøyaktig i tilkoplingsaugneblinken, er venta åtferd. Klienten resirkulerer adapterar og installerer ruter, så sambandet døyr i nokre sekund. Feilen er sambandet som aldri kjem attende, ikkje det som berre blunka.

Ta tabellen før tunnelen og igjen etter han, og samanlikn så dei to utskriftene. Skilnaden er diagnosen, og han er òg beviset ein nettverkseigar vil be om.

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

Les tabellen til verten før og etter

På Linux kjem forrangen mellom overlappande ruter frå prefikslengd og metrikk, så ei meir spesifikk VPN-rute vinn sjølv når ho er feil. På Windows avgjer grensesnittmetrikken uavgjort, og tunneladapteren kjem vanlegvis med lågare metrikk enn den virtuelle. I båe tilfelle er det synlege symptomet identisk: pakkane går ut via tunneladapteren og forsvinn.

Skriv ut adapterane og metrikkane deira ved sida av ruta for gjesteprefikset. Det paret med utskrifter svarar på eigarspørsmålet med eitt blikk.

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

Om ruta endra seg, men metrikken til adapteren ikkje, installerte klienten ei konkurrerande rute. Om metrikken endra seg, omorganiserte klienten adapterane. Båe kan rettast, og dei vert retta på ulike stader.

Når NAT-området til gjesten er kollisjonen

VirtualBox NAT brukar 10.0.2.0/24 som standard, og ein tunnel som dyttar same område, får gjesten til å sende den trafikken til NAT-gatewayen sin i staden for til den verkelege destinasjonen. Pakken forlèt aldri verten, så ingen brannmurlogg på hi sida vil vise han. Docker Machine har same klasse konflikt i berre-vert-planen sin, og å endre den planen kan krevje at maskinen vert attskapt saman med sertifikata sine.

Vel erstatninga ved å liste opp kva tunnelen alt annonserer, så kva kontornettet brukar, så kva kvar virtuell adapter på denne verten har kravd. Overlapp er det som bryt rutinga, og likskap er irrelevant. Eitt område kan liggje heilt inne i eit anna medan det ved første augekast ikkje liknar i det heile.

Set det nye området når maskinen vert oppretta, eller endre det og last inn på nytt, og test så det feilande sambandet igjen frå gjesten. Tabellen til gjesten sjølv er visinga som tel.

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

Gjenopprett vegen utan å kjempe mot klienten

Kvar plattform tilbyr ein måte å setje berre-vert-prefikset framst igjen. På macOS verkar ei statisk rute til berre-vert-grensesnittet til neste tilkopling. På Windows held ein lågare grensesnittmetrikk på den virtuelle adapteren han framsett. På Linux dekkjer ein erstattingsoperasjon eitt prefiks. Alle tre er workarounds, fordi ein klient som hevdar rutene sine på nytt, vil oppheve dei.

Skript kontrollen i staden for ein blind attkopling ved oppstart. Eit lite skript som skriv ut ruta for gjesteprefikset etter kvar tilkopling, gjer eit mysterium til ei linje i ein logg.

Er profilen ein full tunnel, be nettverkseigaren om splitta tunnel eller eit dokumentert unntak. Å leggje til ruter i det stille som omgår ein tryggingspolicy, er ikkje ei retting, det er eit andre problem som kjem seinare med ein revisor på slep.

Kontroller rettinga på båe sider

Verifiser tre vegar etter endringa: vert til gjest, gjest til den bedriftsmessige verten og gjest til internett. Ei retting som gjenopprettar éin av dei og øydelegg ein annan, er ei konfigurasjonsendring forkledd som reparasjon. Ta dei same utskriftene som du samla inn før endringa, så samanlikninga vert lik med lik.

Noter grensesnittet, metrikken og ruta som endra seg, saman med tidspunktet, så neste førekomst er eit oppslag og ikkje ein attoppbygging. Den nota er meir verd enn ein lang sakstråd.

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

Når verten når gjesten igjen og gjesten når LAN-et, har du gjenoppretta vegen du starta med. Når berre éin av dei verkar, er den gjenverande feilen på området til den andre eigaren, og skilnaden fortel deg kva område det er.