Miért nem az adapterek sorrendje dönti el a labor VPN-útvonalát

Az, hogy az 1-es adapter az első a hypervisor listáján, csak megjelenítési sorrend, és a vendég útválasztási táblája nem olvassa. Az útvonalat az előtag, a metrika és bármely házirendszabály dönti el, amely mindkettő előtt érvényes. Ezért egy hídadapter hozzáadása egy labor-VM-hez második alapértelmezett útvonalat hozhat létre, miközben a régi NAT-interfész továbbra is jelenlévőként és másodikként számozva jelenik meg. Az eredmény egy VM, amely néha használja az alagutat, néha nem, anélkül hogy bármilyen konfigurációváltozás megmagyarázná.

Három feltétel dönti el az útvonalat

A három feltétel: melyik előtag a specifikusabb, mit tesznek a metrikák, amikor az előtagok egyenlők, és milyen szabályokat alkalmazott a vendég a hardverváltozás után. Mindegyik megválaszolható egyetlen paranccsal, és egyik sem függ a hypervisor számozásától.

Épp az utolsó pont a döntés: ha nem tudja megmondani, melyik előtag nyer a VPN-végpont saját címére, akkor nincs útválasztási házirendje, hanem olyan topológiája van, amely ma véletlenül működik.

Első feltétel: melyik előtag nyer

A 10.8.0.0/24 felé vezető útvonal legyőzi az alapértelmezett útvonalat a benne lévő címre, függetlenül a metrikáktól és az adapterek sorrendjétől. Ezért egy konkrét útvonalat telepítő VPN-kliens továbbra is működik, ha megjelenik egy második adapter alacsonyabb metrikával: a specifikusság a költség mérlegelése előtt nyer. Ellenőrizze az ip route show paranccsal azt a táblát, amelyet használatban hisz, és az ip route get 203.0.113.9 paranccsal azt a választ, amelyet a kernel egy adott célra valóban adna.

A végpont saját címe a legfontosabb teszt. Ha a VPN-kiszolgáló címe egy újonnan hozzáadott hídadapteren keresztül oldódik fel, az alagút esetleg soha nem jön létre, vagy létrejön, majd elveszíti saját szállítási útvonalát. Kifejezetten azt a címet kérdezze meg, ahelyett hogy feltételezné, az alagút-interfész a válasz.

Második feltétel: mit tesz a metrika és mit nem

A szerepe szűkebb, mint a legtöbben várják. A metrikák az azonos előtagú útvonalak közötti egyenlőséget döntik el; nem engedik, hogy egy szélesebb útvonal legyőzzön egy specifikusabbat. Egyenlőség esetén a kisebb szám élvez elsőbbséget, és a különböző operációs rendszerek ellentétes irányban számolnak, ezért a Linux és a Windows között átvett tanácsok gyakran önmaguknak mondanak ellene.

A vendégben az ip route show a metrikát minden útvonal mellett kiírja, a Windows Get-NetRoute pedig egy InterfaceMetric értéket plusz egy útvonal-metrikát ír ki. Olvassa mindkettőt, mert a tényleges preferencia lehet összeg és nem egyetlen mező. Ha két alapértelmezett útvonal létezik, az a lelet: a vendégnek két kifelé vezető útja van, és hogy melyik nyer, olyan számok függvénye, amelyeket egy hardverváltozás megváltoztathat.

Harmadik feltétel: mit alkalmazott a vendég valójában

A konfiguráció nem ugyanaz, mint az alkalmazott állapot. Az interfésznevek nem stabilak a hardverváltozások során minden platformon, és egy név alapján illeszkedő konfiguráció most talán semmire sem vonatkozik.

Az alkalmazott állapotot ellenőrizze, nem a tervezettet. Az ip -br link a most létező interfészeket mutatja, NetworkManageres hoszton pedig a nmcli connection show megmutatja, melyik profil melyik eszközhöz van kötve. Egy kötni nem tudó profil címzés nélkül hagyja fenn az interfészt, ami útválasztási problémának látszik, és névhasználati probléma. A visszaállított pillanatképek rontják ezt, mert a vendég mentett állapota olyan adapteridentitásokra hivatkozhat, amelyeket az új hardver már nem biztosít.

Tartsa a labor topológiáját reprodukálhatónak

Mentse a tervezett virtuális hálózati csatlakozásokat a vendég konfigurációja mellé, hogy a szerep és adapter közötti leképezés le legyen írva, ne egy lista pozíciójából legyen kikövetkeztetve.

Általában négy szerep elnevezése elegendő: privát kapcsolat, kezelés, külső szállítás és alagút. Mindegyiknek egy fájlban egy adott adapterhez és egy adott vendég-interfészhez kell rendelődnie.

Ezután tesztelje a tényleges alkalmazást hardverváltozás, újraindítás vagy visszaállított pillanatkép után, és a tesztbe foglalja bele a VPN-végpont felé vezető útvonalat is. Ha egy átjáró-VM-nek kell az egyetlen kijáratnak lennie, ellenőrizze, hogy a teszt-VM-nek nincs-e nem szándékolt második alapértelmezett útvonala, mert a hídadapter pontosan második alapértelmezett útvonalat ad hozzá. A vendégből teszteljen, ne a hypervisor konzoljából, mert a kettő vitatkozhat arról, melyik interfész melyik.

A VirtualBox hálózati dokumentációja leírja az adapter módokat és azt, hogy melyik mihez kapcsolódik, és ez az a rész, amelyet érdemes elolvasni egy második hozzáadása előtt. Az a labor, amely azonosítja, melyik adapter melyik szerepet szolgálja, magyarázhatóvá teszi az útvonalváltozást. Az a labor, amely a hypervisor számozására támaszkodik, minden változást kísérletté tesz.