A VPN-útvonal metrikája megváltozott csatlakozás után: mit jelent ez
Az alacsonyabb metrika csak az egyformán specifikus útvonalak közötti holtversenyt dönti el. Olvassa el a házirend-szabályt, a prefixet és a végpont gazdagép-útvonalát, mielőtt bármilyen VPN-útvonal-számot módosítana.
Csatlakozik a VPN-hez, lefuttatja a route print parancsot, és az alapértelmezett útvonal most sokkal alacsonyabb metrikát hordoz, mint korábban. A természetes következtetés az, hogy a VPN átvette az alapértelmezett útvonalat, mert a száma kisebb. Néha pontosan ez történt. Gyakran a metrika egyáltalán nem döntő tényező, és a módosítása semmit nem változtat, mert a választás korábban született, a prefix hossza vagy egy házirend-szabály alapján.
A tünet valódi: a forgalom, amely korábban a Wi-Fi adapteren keresztül ment ki, most az alagúton keresztül megy ki, vagy fordítva. A metrika egyetlen bemenete egy fix sorrendben futó keresésnek, és éppen ezt a sorrendet kell elolvasni, mielőtt bármilyen számhoz nyúl.
Mivel versenyez valójában a szám
Az első összehasonlítás a specificitás, nem a preferencia. A 10.20.0.0/16 útvonal legyőzi a 10.0.0.0/8-at, és mindkettő legyőzi a 0.0.0.0/0-t, bármit mondanak a metrikák. Az a VPN, amely a gépen a legalacsonyabb metrikájú alapértelmezett útvonalat telepíti, továbbra is kikap minden nála specifikusabb útvonaltól, amely illeszkedik a célhoz, beleértve azt a gazdagép-útvonalat, amelyet a kliens a saját kiszolgálójához telepít.
Ezért az alapértelmezett útvonal metrikájának csökkentése nem tudja a közvetlenül csatlakoztatott alhálózatot az alagútba kényszeríteni. Ha azt az alhálózatot a VPN-en belül szeretné, adjon hozzá útvonalat a prefixhez, vagy válassza az alagút tábláját házirend-szabállyal. A metrika nem megfelelő eszköz erre a feladatra.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
A Linux a metrika előtt dönt a tábláról
Linuxon a kernel először a házirend-adatbázist kérdezi meg. A ip rule felsorolja a szabályokat és az általuk kiválasztott táblákat, a ip route get 203.0.113.10 pedig jelenti azt a táblát, útvonalat és forrás-címet, amelyet a kernel ehhez a célhoz ténylegesen használna. A 100-as táblán belüli metrika soha nem versenyez a fő tábla útvonalával, mert a szabály a táblát már az előtt kiválasztotta, hogy bármilyen metrikát összehasonlítottak volna.
Ezért előfordulhat, hogy egy útvonal helyesnek tűnik a ip route show table all kimenetében, és mégsem visz forgalmat. Olvassa el az illeszkedő szabályt, majd az általa kiválasztott táblát, majd hasonlítsa össze a benne lévő útvonalakat. Ha rossz táblát választottak ki, semmilyen metrika-módosítás a másik táblában nem segít.
A Windows két metrikát kombinál
A Windowsnak alapértelmezésben nincs házirend-adatbázisa, de kombinálja az útvonal-metrikát az interfész-metrikával, és az automatikus interfész-metrika változhat a kapcsolat sebességével és az adapter állapotával. Ezért ugyanaz az útvonal másképp viselkedhet, miután megjelenik egy dokkolóállomás vagy egy virtuális adapter. A Find-NetRoute -RemoteIPAddress 203.0.113.10 jelenti a kiválasztott forrás-címet, a következő ugrást és az interfészt, ami közelebb van a valódi döntéshez, mint a nyers tábla.
Olvassa együtt az útvonal- és interfész-értékeket. Az interfész-metrika emelése áthelyezheti a forgalmat anélkül, hogy bármely útvonalbejegyzés megváltozna, és az a VPN-kliens, amely a saját útvonalait birtokolja, újracsatlakozáskor újratelepíti azokat, és eldobja a módosítását.
Tartsa az alagút végpontját az alagúton kívül
Minden alagútnak szüksége van egy útra a saját kiszolgálójához, amely nem az alagúton keresztül vezet. A kliensek gazdagép-útvonalat telepítenek a végponthoz a fizikai átjárón keresztül, és ennek az útvonalnak specifikusabbnak kell maradnia annál az alapértelmezettnél, amelyet a kliens hozzáad. Törölje, vagy hagyja, hogy az alagút nyerje meg az adott címre vonatkozó keresést, és a beágyazott csomagok megpróbálnak belépni abba az alagútba, amelyet építeniük kellene. A kapcsolat megszakad vagy hurokba kerül.
Ellenőrizze ezt a gazdagép-útvonalat minden metrika-változás előtt és után: a fizikai következő ugrásra kell mutatnia, és túl kell élnie egy újracsatlakozást. Ha a kliens birtokolja, változtassa meg a profilt vagy a felügyelt konfigurációt egy futásidejű érték helyett, amelyet felülírnak.
Ellenőrizze mindkét címcsaládot és az alkalmazáskörnyezetet
Az IPv4 és az IPv6 külön döntés, külön táblákkal. A VPN vihet IPv4-et, miközben az IPv6 továbbra is a helyi útválasztót használja, és az egyik családban végrehajtott metrika-változás semmit nem mond a másikról. Ellenőrizze mindkettőt, majd ellenőrizze az alkalmazáskörnyezetet. Az interfészhez kötött folyamat, a konténer-névtér vagy az alkalmazásonkénti VPN a shelljétől eltérő táblát láthat.
A valódi célra vonatkozó döntést jelentő eszközzel ellenőrizze, nem a teljes táblalistával. Ha a kiválasztott útvonal az, amelyet a tervezés szán, álljon meg. Az a metrika, amely nem a legkisebb szám a képernyőn, nem hiba, és ha erre kényszeríti, eltörheti a végpont útját, amelytől az alagút függ.