Nawawala ang Vagrant VM kapag kumonekta ang VPN: kanino ang sirang ruta

Sumagot ang makina isang minuto ang nakalipas, kumonekta ang VPN, at ngayon nag-time out ang parehong address. Tatlong depekto ang gumagawa ng sintomas na iyon, at nakatira sila sa magkaibang makina. Maaaring mawala ng host ang ruta patungo sa pribadong network, maaaring bumangga ang saklaw ng NAT ng bisita sa saklaw na inaanunsyo ngayon ng tunnel, o maaaring angkinin ng buong tunnel ang pagmamay-ari ng bawat ruta sa host. Alamin kung alin ang nangyari bago baguhin ang anumang configuration, dahil nakatira ang bawat pag-aayos sa ibang lugar.

Tingnan ang ruta, hindi ang makina

Tingnan ang desisyon sa pagruruta ng host para sa address ng bisita habang nakaangat ang tunnel. Ang rutang tumuturo pa rin sa host-only adapter ay hindi ang problema. Ang rutang tumuturo na ngayon sa VPN adapter ang problema, at ang client ang nagbago nito, hindi ikaw. Ang pananatili ng address ng adapter ay nagsasabing nakaligtas ang interface, ibang katotohanan ito kaysa sa pagkaligtas ng landas.

Ang SSH session na bumabagsak eksakto sa sandali ng koneksyon ay inaasahang pag-uugali. Nire-recycle ng client ang mga adapter at naglalagay ng ruta, kaya namamatay ang koneksyon nang ilang segundo. Ang depekto ay ang koneksyong hindi na bumabalik, hindi ang kumurap lang.

Kunin ang talahanayan bago ang tunnel at muli pagkatapos, pagkatapos ay ihambing ang dalawang output na iyon. Ang pagkakaiba ang diagnosis, at ito rin ang ebidensiyang hihilingin ng may-ari ng network.

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

Basahin ang talahanayan ng host bago at pagkatapos

Sa Linux ang preperensiya sa pagitan ng magkapatong na ruta ay nagmumula sa haba ng prefix at metric, kaya ang mas tiyak na rutang VPN ay nananalo kahit mali ito. Sa Windows ang metric ng interface ang nagpapasya ng tabla, at ang adapter ng tunnel ay kadalasang dumarating na may mas mababang metric kaysa sa virtual. Sa dalawang kaso ang nakikitang sintomas ay pareho: lumalabas ang mga packet sa adapter ng tunnel at nawawala.

I-print ang mga adapter at ang kanilang metric sa tabi ng ruta para sa prefix ng bisita. Ang pares ng output na iyon ay sumasagot sa tanong ng pagmamay-ari sa isang tingin.

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

Kung nagbago ang ruta pero hindi ang metric ng adapter, naglagay ang client ng katunggaling ruta. Kung nagbago ang metric, inayos muli ng client ang mga adapter. Pareho silang maaayos, at inaayos sila sa magkaibang lugar.

Kapag ang saklaw ng NAT ng bisita ang banggaan

Gumagamit ang VirtualBox NAT ng 10.0.2.0/24 bilang default, at ang tunnel na nagtutulak ng parehong saklaw ay nag-uudyok sa bisita na ipadala ang trapik na iyon sa sarili nitong NAT gateway sa halip na sa tunay na destinasyon. Hindi umaalis ang packet sa host, kaya walang firewall log sa kabilang panig ang magpapakita nito. May parehong uri ng salungatan ang Docker Machine sa host-only plan nito, at ang pagbabago ng planong iyon ay maaaring mangailangan ng muling paggawa ng makina kasama ang mga sertipiko nito.

Piliin ang kapalit sa pamamagitan ng paglilista ng inaanunsyo na ng tunnel, pagkatapos ng ginagamit ng network ng opisina, pagkatapos ng inangkin ng bawat virtual adapter sa host na ito. Ang pagpapatong ang sumisira sa pagruruta, at walang kinalaman ang pagkakahawig. Maaaring buong nakapuwesto ang isang saklaw sa loob ng isa habang walang pagkakahawig sa unang tingin.

Itakda ang bagong saklaw kapag ginawa ang makina, o baguhin ito at i-reload, pagkatapos ay subukan muli ang nabibigong koneksyon mula sa bisita. Ang talahanayan ng bisita mismo ang pananaw na mahalaga.

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

Ibalik ang landas nang hindi nakikipag-away sa client

Bawat plataporma ay nag-aalok ng paraan upang mauna muli ang host-only prefix. Sa macOS gumagana ang static na ruta patungo sa host-only interface hanggang sa susunod na koneksyon. Sa Windows pinapanatili ng mas mababang metric ng interface sa virtual adapter ang preperensiya nito. Sa Linux sinasaklaw ng operasyon ng pagpapalit ang isang prefix. Lahat ng tatlo ay pansamantalang solusyon, dahil ang client na muling igigiit ang mga ruta nito ay magpapawalang-bisa sa kanila.

I-script ang pagsusuri sa halip na bulag na muling pagkonekta sa boot. Ang maliit na script na nagpi-print ng ruta para sa prefix ng bisita pagkatapos ng bawat koneksyon ay ginagawang linya sa log ang isang misteryo.

Kung ang profile ay buong tunnel, hilingin sa may-ari ng network ang split tunnelling o dokumentadong eksepsiyon. Ang tahimik na pagdaragdag ng mga rutang lumalabpas sa patakaran sa seguridad ay hindi pag-aayos, ito ay ikalawang problema na dumarating mamaya kasama ang isang auditor.

Suriin ang pag-aayos sa magkabilang panig

I-verify ang tatlong landas pagkatapos ng pagbabago: host patungo sa bisita, bisita patungo sa corporate host, at bisita patungo sa internet. Ang pag-aayos na nagbabalik ng isa at sumisira ng iba ay pagbabago sa configuration na nagpapanggap na pagkukumpuni. Kunin ang parehong output na nakolekta bago ang pagbabago upang ang paghahambing ay pantay sa pantay.

Itala ang interface, metric at rutang nagbago, kasama ang oras, upang ang susunod na pangyayari ay paghahanap at hindi muling pagtatayo. Ang talaang iyon ay mas mahalaga kaysa sa mahabang thread ng ticket.

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

Kapag naabot muli ng host ang bisita at naabot ng bisita ang LAN, naibalik mo ang landas na sinimulan mo. Kapag isa lang sa mga iyon ang gumagana, ang natitirang depekto ay nasa teritoryo ng kabilang may-ari, at sinasabi ng pagkakaiba kung aling teritoryo iyon.