Miért nem mutat átjárót egy VPN-útvonal az ip route kimenetében

Az útvonaltáblákat gyakran hibásként olvassák, valahányszor az átjáró oszlopa üresen marad, pedig a sor általában önmagában is teljes. A via mező csak akkor jelenik meg, amikor a kernel átadja a csomagot egy következő ugrás címének; a csatolóhoz kötött útvonal a céljait inkább kapcsolati rétegű feloldással vagy pont-pont partneren keresztül éri el. Az oszlopok balról jobbra olvasása megmondja, melyik esetben van, és ezt az olvasást még azelőtt kell elvégezni, hogy bárki szerkesztene egy alapértelmezett útvonalat. A hiányzó átjáróról szóló jegyek többsége ennél a megkülönböztetésnél ér véget.

Olvassa végig az útvonal sort oszlopról oszlopra

Minden bejegyzés a céllal és annak előtaghosszával kezdődik, majd módosítókat ad hozzá egy rögzített szókészletből: via, dev, proto, scope, src és metric. Egy 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2-hez hasonló sor sűrű, de teljesen meghatározott. Semmi sem hiányzik belőle, és semmilyen útválasztó-cím nincs benne implikálva.

A via hiánya az érdekes rész. Következő ugrás nélkül a kernel közvetlenül a megnevezett csatolón oldja fel a célt, ami alagút esetén azt jelenti, hogy a keretet átadja az alagút-eszköznek, és az inkapszulációra bízza a továbbiakat. A proto kernel rögzíti, hogy a bejegyzés automatikusan telepítődött a cím kiosztásakor, nem pedig egy adminisztrátor gépelte be. A scope link szerint a cél azon a kapcsolaton útválasztó érintése nélkül elérhető, a src pedig megnevezi azt a címet, amelyet a kernel az egyező forgalom forrásaként előnyben részesít.

Most olvasson el egy alapértelmezett útvonalat ugyanígy: default via 192.0.2.254 dev eth0 proto static metric 100. Itt a via azért van jelen, mert a csomagnak valóban szüksége van következő ugrásra, és annak az ugrásnak magának is elérhetőnek kell lennie a eth0 felől. A két sor nem egymás változata; más-más kérdésre válaszolnak arról, hová megy a forgalom.

Két útvonalforma, amelyeket összekevernek egymással

Az alagút alhálózati útvonala és az alapértelmezett útvonal hasonlónak látszik egy képernyőképen, és teljesen másképp viselkedik. Használja az alábbi táblázatot a mezők olvasásának segédeszközeként, majd a valós számokat a hibakeresett gépen erősítse meg, ne pedig egy útmutató mintájában bízzon.

Amit a táblázat nem tud megmondani, az a szándék. Az alagúton keresztül egy magánhálózati tartomány felé vezető közvetlen útvonal szándékos osztott alagút kialakítás; ugyanez a forma egy olyan gazdagépen, amelynek mindent a VPN-en keresztül kellene küldenie, tünet. A szándék abban a konfigurációban él, amely a bejegyzést létrehozta, ezért nézze meg az eszközt, amely telepítette, mielőtt arra jutna, hogy a kernel valamit elrontott.

Ugyanígy a hiányzó átjáró nem engedély arra, hogy kitaláljunk egyet. Ha egy útvonalnak valóban szüksége van következő ugrásra, annak az ugrásnak elérhetőnek kell lennie azon a csatolón, amely hordozza, és pont-pont alagút esetén a partner címe nem ugyanaz az objektum, mint a helyi cím. A helyi alagútcímet Ethernet-útválasztóként kezelni gyakori módja annak, hogy helyesnek látszó, de semmit tovább nem küldő útvonal szülessen.

Kérdezze meg a kernelt, melyik sort fogja valóban használni

A táblázat olvasása nem ugyanaz, mint a keresés végrehajtása, mert a kernel válasz előtt szabályzatokat, több táblázatot és gyorsítótárazott bejegyzéseket is megkérdez. Az igazi keresést végrehajtó ige a ip route get, és kiírja az útvonalat, amelyet egy ilyen tulajdonságú csomag választana.

ip route get 203.0.113.37 from 198.51.100.2 iif tun0

Helyettesítse be a célt, amely valóban érdekli, majd adja hozzá a from vagy iif mezőt, amikor a forgalom forrás alapján kiválasztott vagy továbbított, mert egy közönséges helyi keresés más utat választhat, mint egy továbbított kliens. A válasz megnevezi a csatolót, a választott forrás címet és az esetleges következő ugrást, ami ugyanaz az információ, amellyel egy csomag abban a pillanatban útvonalra kerülne.

Ha a válasz meglepí, nyomtassa ki a szabályokat, mielőtt bármit módosítana: a ip -4 rule show prioritási sorrendben listázza őket, és egy olyan VPN-kliens, amely saját táblázatot vagy megjelölt csomagokra vonatkozó szabályt telepít, egyáltalán nem jelenik meg a fő táblázatban. Az összes táblázat listázása bezárja ezt a rést.

ip -4 route show table all | grep -E 'tun|default'

Ellenőrizze az alréteget, mielőtt lecseréli az alapértelmezett útvonalat

Az alagút saját csomagjainak el kell jutniuk a távoli végponthoz, és ezt a fizikai csatolón keresztül teszik, a VPN feljövetele előtt létező útvonalat használva. Az egész alapértelmezett útvonal lecserélése anélkül, hogy rögzítenék ezt a végpontot, a beburkolt csomagokat abba az alagútba küldi, amelyet állítólag építeniük kellene, és a kapcsolat összeomlik. Először a végpont útvonalát erősítse meg egy kizárólag a végpont címére indított kereséssel.

Három dolgot tartson külön a módosításkor: a végpont útvonalát, amelynek a fizikai csatolón kell maradnia, a magánhálózati tartományokat, amelyeknek az alagútba kellene kerülniük, és az alapértelmezettet, amely minden mást eldönt. Bontsa szét őket ebben a sorrendben, egyszerre egyet alkalmazzon, és minden lépés után futtassa újra a keresést. Egy későbbi sikertelen ping önmagában nagyon keveset bizonyít, mivel az engedélyek, a válaszok útvonalválasztása, a DNS és maga a szolgáltatás mind a helyes útvonal alatt helyezkednek el.

Jegyezze fel a szerkesztés előtt a sortól kapott négy értéket: cél, következő ugrás vagy annak hiánya, eszköz és a választott forrás. Ha egy későbbi változtatás bármelyiket elmozdítja, tudni fogja, melyik döntés változott meg valójában, és egy bejegyzést állíthat vissza ahelyett, hogy az egész táblázatot találgatná.