A Vagrant VM eltűnik a VPN csatlakozásakor: kié az eltört útvonal

A gép egy perce válaszolt, a VPN csatlakozott, és most ugyanaz a cím időtúllépésbe fut. Három hiba okozza ezt a tünetet, és ezek különböző gépeken élnek. A gazdagép elveszítheti az útvonalat a magánhálózat felé, a vendég NAT-tartománya ütközhet egy tartománnyal, amelyet az alagút most hirdet, vagy egy teljes alagút átveheti a gazdagép összes útvonalának tulajdonjogát. Derítse ki, melyik történt, mielőtt bármilyen konfigurációt módosítana, mert minden javítás máshol él.

Az útvonalat nézze, ne a gépet

Nézze meg a gazdagép útválasztási döntését a vendég címére, amíg az alagút fenn áll. Az az útvonal, amely még mindig a csak-gazdagép adapterre mutat, nem a probléma. Az az útvonal, amely most a VPN-adapterre mutat, a probléma, és azt az ügyfél változtatta meg, nem ön. Az, hogy az adapter megtartja a címét, azt mondja, hogy a felület túlélte, ami más tény, mint az útvonal túlélése.

Az az SSH-munkamenet, amely pontosan a kapcsolódás pillanatában szakad meg, várható viselkedés. Az ügyfél újrahasznosítja az adaptereket és útvonalakat telepít, ezért a kapcsolat néhány másodpercre meghal. A hiba az a kapcsolat, amely soha nem tér vissza, nem az, amely csak pislogott.

Rögzítse a táblázatot az alagút előtt, majd utána is, és hasonlítsa össze a két kimenetet. A különbség a diagnózis, és egyben az a bizonyíték, amelyet a hálózat tulajdonosa kérni fog.

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

Olvassa el a gazdagép táblázatát előtte és utána

Linuxon az átfedő útvonalak közötti elsőbbség a prefix hosszából és a metrikából ered, ezért egy konkrétabb VPN-útvonal akkor is nyer, ha hibás. Windowson az interfész metrikája dönti el a holtversenyt, és az alagút adaptere általában alacsonyabb metrikával érkezik, mint a virtuális. Mindkét esetben a látható tünet azonos: a csomagok az alagút adapterén keresztül távoznak és eltűnnek.

Írja ki az adaptereket és a metrikáikat a vendég prefixének útvonala mellé. Ez a kimenetpár egy pillantással megválaszolja a tulajdonjog kérdését.

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

Ha az útvonal megváltozott, de az adapter metrikája nem, az ügyfél versengő útvonalat telepített. Ha a metrika változott, az ügyfél átrendezte az adaptereket. Mindkettő javítható, és különböző helyeken javítják.

Amikor a vendég NAT-tartománya az ütközés

A VirtualBox NAT alapértelmezés szerint a 10.0.2.0/24 tartományt használja, és az az alagút, amely ugyanezt a tartományt tolja, arra készteti a vendéget, hogy ezt a forgalmat a NAT-átjárójára küldje a valódi cél helyett. A csomag soha nem hagyja el a gazdagépet, ezért a túloldali tűzfalnapló nem fogja mutatni. A Docker Machine-nél ugyanez a konfliktusosztály van a csak-gazdagép tervében, és annak a tervnek a módosítása szükségessé teheti a gép újralétrehozását a tanúsítványaival együtt.

Válassza ki a cserét úgy, hogy felsorolja, mit hirdet már az alagút, aztán mit használ az irodai hálózat, aztán mit követelt minden virtuális adapter ezen a gazdagépen. Az átfedés töri meg az útválasztást, a hasonlóság pedig lényegtelen. Egy tartomány teljesen ülhet egy másikban, miközben első pillantásra egyáltalán nem hasonlítanak.

Állítsa be az új tartományt a gép létrehozásakor, vagy módosítsa és töltse újra, majd tesztelje újra a hibás kapcsolatot a vendégből. A vendég saját táblázata az a nézet, amely számít.

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

Állítsa helyre az útvonalat anélkül, hogy harcolna az ügyféllel

Minden platform kínál módot arra, hogy a csak-gazdagép prefixét újra előre hozza. macOS-en a csak-gazdagép felületre mutató statikus útvonal a következő kapcsolódásig működik. Windowson az alacsonyabb interfész-metrika a virtuális adapteren előnyben tartja. Linuxon a helyettesítő művelet egyetlen prefixet fed le. Mindhárom kerülőmegoldás, mert az ügyfél, amely újra érvényesíti az útvonalait, visszavonja őket.

Szkriptelje az ellenőrzést a vak újracsatlakozás helyett indításkor. Egy kis szkript, amely minden kapcsolódás után kiírja a vendég prefixének útvonalát, a rejtélyből naplósort csinál.

Ha a profil teljes alagút, kérjen a hálózat tulajdonosától osztott alagutat vagy dokumentált kivételt. Csendben olyan útvonalakat hozzáadni, amelyek megkerülnek egy biztonsági irányelvet, nem javítás, hanem egy második probléma, amely később egy auditorral együtt érkezik.

Ellenőrizze a javítást mindkét oldalon

A módosítás után ellenőrizzen három útvonalat: gazdagép a vendéghez, vendég a vállalati gazdagéphez és vendég az internethez. Az a javítás, amely az egyiket helyreállítja és a másikat elrontja, konfigurációmódosítás javításnak álcázva. Rögzítse ugyanazokat a kimeneteket, amelyeket a módosítás előtt gyűjtött, hogy az összehasonlítás egyenlő legyen az egyenlővel.

Jegyezze fel a felületet, a metrikát és a megváltozott útvonalat az időponttal együtt, hogy a következő eset keresés legyen, ne újjáépítés. Ez a jegyzet többet ér egy hosszú hibajegy-fonalnál.

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

Amikor a gazdagép újra eléri a vendéget, és a vendég eléri a LAN-t, helyreállította azt az útvonalat, amellyel kezdte. Amikor csak az egyik működik, a maradék hiba a másik tulajdonos területén van, és a különbség megmondja, melyik terület az.