Útválasztási tábla kontra tényleges keresés: hová megy a VPN-forgalom
Induljon ki egy célállomásból és annak forrásából, majd ellenőrizze, melyik szabály és tábla dönti el valójában az útvonalat. A tábla teljes kiírása e kontextus nélkül félrevezet.
Az útválasztási tábla kiírása a legkevésbé hasznos diagnosztika a VPN-hibakeresésben, és ezt illesztik be a leggyakrabban. Negyven előtag-sor azt mondja el, mit tehetne a gép, nem azt, mit tett a sikertelen kérésért. A mechanizmus, amit valójában szeretne, a keresés: adott ez a forrás és ez a cél, melyik szabály egyezett, melyik táblát kérdezték, és melyik interfész és következő ugrás jött ki. Induljon ki egy célállomásból és egy forrásból, majd olvassa a táblát ezzel a kérdéssel a kezében, és ugyanaz a kimenet bizonyítékká válik zaj helyett.
A tábla jelöltek halmaza, nem döntés
Minden bejegyzés egy előtagot és a hozzá illeszkedő forgalommal kapcsolatos teendőt ír le: küldje egy interfészre, adja tovább egy következő ugrásnak, vagy dobja el. Ebben a listában semmi sincs szándék szerint rendezve, és az embernek leginkább specifikusnak tűnő bejegyzés nem mindig az, amelyet a kernel kiválaszt, mert a kiválasztás a leghosszabb előtag-egyezést követi, azonos előtagok között pedig a metrikát.
Tehát az első lépés a kernel megkérdezése a lista olvasása helyett. A keresési parancs egy célállomásra válaszol, forrás-argumentummal pedig arra a pontos párra, amelyet egy továbbított vagy kötött kapcsolat használna:
ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40
A fenti címek mindegyike dokumentációs példa. A lényeg a válasz formája: interfész, kiválasztott forráscím, átjáró és a tábla, amelyből a bejegyzés származik. Ha ez a kimenet nem egyezik a várt interfésszel, egyetlen paranccsal lokalizálta a problémát, és a teljes tábla olvasása sem mondta volna meg, melyik jelölt nyert.
A keresés először szabályokon, majd táblákon halad át
Linuxon a döntés két szakaszban születik. A házirend-szabályokat prioritási sorrendben értékelik, és az első egyező szabály megnevez egy lekérdezendő táblát; az a tábla végzi el a leghosszabb előtag-egyezést. Egy szabály egyezhet forrásra, célra, tűzfaljelzésre, interfészre vagy kombinációra, ezért a főtábla kiírása lehet teljesen pontos és teljesen irreleváns a vizsgált csomag szempontjából.
ip rule show
ip route show table all | head -40
ip route show table 100
Ha egy szabály a VPN-készletéből származó forgalmat a 100-as táblára küldi, akkor a 100-as tábla számít, és a főtábla csali. Ez a mechanizmus áll a forrásalapú útválasztás mögött egy routeren is: ugyanannak a célnak két különböző válasza lehet attól függően, honnan érkezett a csomag, és csak a forrás-argumentummal végzett keresés mutatja meg, melyik érvényes.
Az IPv6-nak saját szabályai és táblái vannak. A mindkét családot futtató kialakításnak mindkét keresésre szüksége van, és egy működő IPv4-válasz semmit sem mond arról a v6-útvonalról, amelyet egy kettős veremű kliens előnyben részesíthet.
Mit telepít a VPN-kliens
A kliensek általában nem cserélik le az alapértelmezett útvonalat, mert az megtörné az alagút saját külső útvonalát. Valami specifikusabbat telepítenek, amely az előtag hosszával nyer: a 0.0.0.0/1 és 128.0.0.0/1 lefedésére szolgáló fél-alapértelmezett pár a klasszikus trükk, mivel mindkettő hosszabb előtag a 0.0.0.0/0-nál, és együtt lefedik az egész teret. Mások konkrét privát előtagokat és egy házirend-szabályt telepítenek, néhányan pedig jelzést adnak hozzá, hogy csak a kiválasztott forgalom legyen befogva.
Ezért a "a VPN nem változtatta meg az alapértelmezett útvonalamat" nem a hiba bizonyítéka. Ellenőrizze, mit adott mégis hozzá, és hogy a szóban forgó cél azokon az előtagokon belül van-e:
ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25
Két fél-útvonalat könnyű kihagyni egy kiírásból, mert nem úgy néznek ki, mint egy alapértelmezett. Az a split-tunnel konfiguráció, amely elfelejtett felvenni egy előtagot, pontosan azt a tünetet produkálja, amit üldöz: az alkalmazás, amelynek az alagutat kellene használnia, helyette helyben oldja fel és csatlakozik. Hasonlítsa össze a telepített előtagokat azokkal a célokkal, amelyekre a felhasználónak valóban szüksége van, nem azokkal a címekkel, amelyeket véletlenül tesztelt. Az a split-tunnel lista, amely lefedi a fájlszervert, de a feloldóját nem, olyan kapcsolatot hoz létre, amely nyilvános címre oldódik fel, majd hitelesítéskor meghiúsul, ami jelszóproblémának tűnik, és útvonalprobléma.
A külső útvonalnak is túl kell élnie
Az alagút maga is forgalom. A beágyazott hasznos terhet szállító csomagok a fizikai interfészen át a partner címére mennek, és ezt az útvonalat nem szabad visszairányítani az alagútba. Amikor mégis, megkapja azt a jellegzetes hibát, amikor az alagút felépül, majd abbahagyja a forgalom átengedését, mert az alagút szállítása most az alagúton belül van.
Ellenőrizze a partner címét ugyanúgy, ahogy a belső célt ellenőrizte, és erősítse meg, hogy a fizikai interfészre oldódik fel, nem az alagútra:
ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10
A rekurzív útvonal, a partnert elkapó házirend-szabály vagy a teljes alagútú kliens által lecserélt alapértelmezett útvonal a három szokásos ok. Mindhárom látható a külső keresésben, és egyik sem látható az utólag készített főtábla-kiírásban.
Mit nem tud megmondani az útválasztási kimenet
A helyes keresés azt jelenti, hogy a kernel a csomagot valahova értelmesen küldené. Ez nem jelenti azt, hogy a tűzfal engedi, az IPsec-házirend lefedi, a NAT-szabály lefordítja, vagy a távoli oldalnak van visszaútja. Ezek mindegyike későbbi szakasz, és a strongSwan továbbítási megjegyzései leírják azt a láncot, amelyen a csomagnak mindkét végén át kell haladnia.
Az alkalmazásszintű kötést sem veszi figyelembe. Egy folyamat köthet interfészhez, állíthat be jelzést, vagy használhatja a saját feloldóját, és olyan névvel kapcsolódhat, amely másképp oldódik fel, mint amit tesztelt. Amikor a keresés helyes, és a kapcsolat mégis meghiúsul, a következő kérdés, melyik folyamat hozza létre, és hogy az a folyamat ugyanazt a táblát látja-e, mint ön.
Tartsa tehát a diagnózist rendezetten: nevezze meg a célt és a forrást, futtassa a keresést, csak a keresés által megnevezett táblát és szabályt olvassa, majd tesztelje a következő szakaszt. Ez a sorrend percekben tartja az útválasztási vizsgálatot, és olyan feljegyzést hagy, amelyet más is követhet, amit egy beillesztett tábla soha nem tesz meg.