OpenVPN-útvonalmetrika: miért veszít mégis a kiválasztott útvonal

Hozzáadott egy metrikát egy útvonalhoz a profilban, újracsatlakozott, és a forgalom még mindig a rossz interfészen keresztül távozik. A szám ritkán a probléma. A metrika csak azokat a jelölteket rendezi, amelyeket az operációs rendszer már összehasonlít, és egy konkrétabb előtag vagy egy korábbi házirend-tábla dönt, mielőtt bármely metrikát elolvasnának.

Először a profilt, aztán a telepített táblát, aztán a kiválasztási szabályokat vegye sorra. Ez a sorrend megfelel annak, ahogyan a kliens felépíti az útvonalat, és megakadályozza, hogy olyan értéket hangoljon, amely soha nem kerül be az összehasonlításba.

Olvassa az útvonalsort a mezők sorrendjében

Az OpenVPN 2.6 közösségi kliense négy mezőt fogad el egy IPv4 route sorban: hálózat, hálózati maszk, átjáró és egy opcionális metrika. Az átjáró helye az, ahová a speciális vpn_gateway kulcsszó kerül. Ez a kapcsolat VPN oldali következő ugrását jelenti, nem egy útválasztási tábla számát és nem a fizikai routerét. Ha ezt kihagyja, a sor többi része téves elképzeléssel olvasódik arról, mit tesz. hálózati beállítások referenciája mind a négy mezőt dokumentálja.

Privát cél esetén a sor így szólhat:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

A kifejezett 30 arra az útvonalra vonatkozik, az 50 pedig az alapértelmezés marad a profil minden más útvonala számára, amely kihagyja a számot. A sor balról jobbra olvasása elegendő annak megállapításához, melyik érték hol érvényes.

A route-metric alapértelmezés, nem rangsor

route-metric a tartalék értéket állítja be azoknak az útvonalaknak, amelyek nem hordozzák a saját számukat. Nem emel egy útvonalat semmi fölé, és nem rendezi át a kifejezett metrikákkal telepített útvonalakat.

Ez a különbség akkor számít, amikor a profil mindkét formát keveri. Egyetlen route-metric sor a teteje közelében tekintélyesnek tűnik, és könnyű hibáztatni, miközben a forgalmat ténylegesen vivő útvonal három sorral lejjebb hordozhatja a saját metrikáját.

Ha azt szeretné, hogy egy útvonal előnyben részesítsen egy útvonalat, tegye a számot arra az útvonalra. Ha egységes alapértelmezést szeretne egy generált profilon keresztül, használja a route-metric értéket, és hagyja békén az egyedi sorokat. A kettő ok nélküli keverése az, ahogyan egy profil olyan útvonallal végződik, amelyet senki sem tud megmagyarázni.

Vizsgálja meg, mit telepített a kliens

Az újracsatlakozás befejezése után a kernelt kérdezze, ne a profilt.

ip route show felsorolja a kliens által hozzáadott útvonalakat, a ip route get 172.20.5.10 pedig a hasznosabb kérdésre válaszol: melyik útvonalat használná ez a cél valójában, és mely forrás címmel. Ha a cél hiányzik a táblából, a kliens nem telepítette.

Egy helyi direktíva, egy kiszolgálói leküldés vagy egy másik hálózatkezelő hozzáadhatja vagy eltávolíthatja ugyanazt az előtagot, és az utolsó író nyer. Tartsa szem előtt a végpont útvonalát munka közben, mert a kapcsolatnak olyan útra van szüksége a távoli kiszolgáló felé, amely nem a felépülő alagúton halad át.

Miért veszít mégis egy kisebb metrika

A metrikák azonos cél felé irányuló útvonalakat hasonlítanak össze. Nem tesznek egy széles előtagot konkrétabbá. Amikor redirect-gateway def1 van játékban, a kliens telepíti a 0.0.0.0/1 és a 128.0.0.0/1 útvonalat, és ez a két előtag a teljes IPv4-teret konkrétabban fedi le, mint a 0.0.0.0/0. Az alapértelmezett útvonalon lévő 1 metrika nem előzi meg őket.

Ugyanez a logika vonatkozik minden átfedő párra. A /24 legyőzi a /16-ot a benne lévő cím esetében, függetlenül a csatolt számoktól, mert a keresés először a legkonkrétabb egyezést választja, és csak utána hasonlítja össze a metrikákat egyenlők között.

Ez az a rész, amely metrikahibának tűnik, és nem az. Ellenőrizze az előtag hosszát mindkét jelöltnél, mielőtt bármilyen számot megváltoztat.

A házirend-szabályok a tábla előtt futnak

Linuxon a ip rule dönti el, melyik útválasztási táblát kérdezik le. A szabályokat prioritási sorrendben értékelik, így egy korábbi tábla még azelőtt visszaadhat egy útvonalat, hogy a fő táblát egyáltalán elolvasnák. A main belsejében lévő metrika nem előzheti meg az elsőként lekérdezett tábla egyezését.

Használja a ip rule show parancsot, majd kérdezze le a konkrét táblát, például a ip route show table 100 parancsot, hogy lássa, mit adna vissza az a szabály. Ha egy VPN-kliens vagy egy konténer-futtatókörnyezet hozzáadott egy szabályt, a válasz ott lehet, nem abban a táblában, amelyet olvasott. A forrás cím is számít, mert egy szabály illeszkedhet a forrásra, és ugyanazt a célt másképp oldhatja meg alagútforgalom és LAN-forgalom esetén.

A célt ellenőrizze, ne a rangsort

A vitát lezáró teszt egyetlen lekérdezés a szándékolt alhálózaton belüli hoszthoz, plusz a kernel által választott forrás cím ellenőrzése. Ha ez a pár megfelel a tervezésnek, a metrika végzi a dolgát, akkor is, ha a lista nem tűnik tiszta rangsornak.

Hagyja ki az IPv6-ot és a DNS-t ebből az ellenőrzésből. Ezeket más direktívák konfigurálják, és más mechanizmusok oldják meg, egy működő IPv4-útvonal pedig semmit sem mond egyikről sem. Egyszerre egy réteget változtasson, és futtassa újra a lekérdezést.