Miért válaszol a VPN-kliens mögötti kiszolgáló az alagúton keresztül

Egy olyan gazdagép felé irányuló bejövő kapcsolatok, amely VPN-klienst is futtat, nagyon sajátos módon hiúsulnak meg: a kézfogás megérkezik, a démon válaszol, és az ügyfél semmit sem kap vissza. Semmi sem blokkolja a portot. A válasz az alagúton keresztül távozott, mert az alagút birtokolja az alapértelmezett útvonalat, és a kernel a válaszokat cél szerint irányítja, nem annak emléke szerint, honnan érkezett a kérés. Ez az egyetlen kihagyás magyarázza az összes következő tünetet.

A válasz útvonalat kap, nem emléket

Az alapértelmezett útvonalat telepítő VPN-kliens olyan bejegyzést ad hozzá, amely felülmúlja a LAN-átjárót, akár metrika, akár a tér két pontosabb felére osztása révén. A kimenő csomagok most az alagút interfészét választják. A kernel soha nem kérdezi, honnan érkezett eredetileg a megválaszolt csomag. Ez az egyetlen mulasztás magyarázza az összes következő tünetet.

Az előre irányt cél szerint irányítja, és a visszirányt is. A válasz egy nyilvános ügyfélnek szól, amelyet az alagút szívesen szállít. A távoli vég olyan csomagot kap, amelynek forrását nem birtokolja, eldobja, és az eredeti ügyfél addig vár, amíg le nem jár az idő.

A szigorú fordított útvonal szűrés még azelőtt eldobhatja a bejövő csomagot, hogy a démon egyáltalán elolvasná. Először azt a számlálót ellenőrizze, mert a szűrő általi eldobás és az útválasztási hiba kívülről azonosnak tűnik.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Az első parancs megmutatja, melyik alapértelmezett útvonal nyer jelenleg. A második jelzi, hogy a szigorú szűrés globálisan vagy interfészenként érvényes-e, a harmadik pedig bármely továbbítási láncbeli szabályt mutat, amely érintett lehet.

Három mód a visszaút megtartására

A szolgáltatás céljának az alagútból való kizárása a legszűkebb lehetőség. A LAN-átjáró felé mutató gazdagép-útvonal, valamint a fizikai címhez, nem minden címhez kötött démon azon az egy folyamon kívül tartja az alagutat. A változtatás helyi és könnyen visszafordítható.

A házirend-alapú útválasztás az általános válasz. A forráscímre vagy tűzfaljelzésre kulcsolt szabály olyan táblát választ, amelynek alapértelmezett útvonala a WAN-átjáróra mutat, miközben a gazdagép saját kapcsolatai továbbra is az alagutat használják. Tartsa a prioritást explicit módon, hogy a szabályt később ne lehessen elfedni.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Az első két parancs felépíti az alternatív útvonalat a nyilvános címről érkező válaszokhoz. A harmadik megkérdezi a kernelt, pontosan melyik utat venné az a forrás és cél, és így igazolja, hogy a szabálynak egyáltalán van hatása.

A forrásfordítás a harmadik lehetőség, és az egyetlen, amely túlél egy olyan útválasztót, amely már NAT-ot végez a szolgáltatás előtt. A válasznak vissza kell térnie ahhoz az útválasztóhoz, és a WAN-interfészre történő álcázás ezt eléri, miközben elrejti az ügyfelet a szolgáltatás naplóiból. Az alapértelmezett útvonal kézi lecserélése csatlakozás után diagnosztika, mert az ügyfél a következő újracsatlakozáskor újraírja a táblát.

Amikor a doboz LAN számára is irányít

Ugyanez a hiba egy ugrással távolabb jelenik meg, amikor a gazdagép a mögötte lévő eszközök számára irányít. Egy bejövő kapcsolat továbbítódik egy belső eszközhöz, amelynek egyetlen visszauta az alagút, és a válasz a szolgáltató címéről éri el a külső ügyfelet. A belső eszköz végig helyesen működik.

A kapcsolatkövetés ekkor olyan folyam válaszát látja, amelyet soha nem rögzített, és eldobja. A célfordítás eljuttatja a bejövő kapcsolatot az eszközhöz, a forrásfordítás pedig úgy mutatja a választ, mintha magától az útválasztótól eredne.

Az a házirend-útvonal, amely a továbbított portot a WAN-on tartja, miközben az útválasztó saját forgalma az alagutat használja, a tisztább megfelelő. Forrásfordítás nélkül a válasz a külső ügyfélnek szól, és a belső eszköznek egyáltalán nincs útvonala arra a címre.

Három próba, amely szétválasztja az okokat

Futtasson három próbát: egy kapcsolatot a dobozba az internetről, egy kapcsolatot onnan egy nyilvános gazdagéphez, és egy névkeresést. Amikor az első kettő ellentmond, a visszaút a hibás. Amikor a nevek mindkét irányban meghiúsulnak, a feloldó egy másik hiba, amely csak osztozik az alagúton.

Először az útválasztás kérdését javítsa, aztán nézze a neveket. A kettő keverése az, ahogyan egy működő kiszolgálót egy törött feloldó miatt hibáztatnak.

Jegyezze fel, melyik interfészt nevezi meg a kivétel, és tartsa a konfigurációt verziókezelés alatt. Egy olyan interfész ellen írt szabály, amelyet frissítés után átneveznek, ma átmegy, és a következő újraindítás után meghiúsul.