Hídba kötött OpenVPN-klienseknek nincs internet? Ellenőrizze a NAT-szabályt

A hídba kötött szerver fut, a masquerade-szabály ott van, és a kliens böngészője mégis pörög. Minden úgy néz ki, mintha működnie kellene, és éppen ezért megy el az első óra az alagút és a hitelesítő adatok ellenőrzésével. Aztán leolvassa a NAT-szabály számlálóját, és egy nullát talál, amely nem mozdult. Egy szabály, amely soha nem számolt egyetlen csomagot sem, soha nem is illeszkedett egyhez sem, hídba kötött szerveren pedig az ok szerkezeti: az ügyfélforgalom a virtuális tap-eszközön keresztül lép ki, míg a szabály a fizikai kártyát nevezi meg, amelyet egy régebbi útmutatóból másolt.

A számláló a bizonyíték, nem a táblázat sora

A létező szabályok és az illeszkedő szabályok különböző dolgok, és a számláló választja el őket. Listázza a NAT-táblát részletes számlálókkal, és olvassa el az egyes szabályok melletti számokat, mielőtt bármit módosítana. A nullán álló számláló forgalom közben azt jelenti, hogy a szabályt kihagyták, bármennyire értelmesek is a címei. A számláló, amely emelkedik, miközben a kapcsolat továbbra is meghiúsul, máshová irányítja: továbbítás, visszaút vagy a távoli vég.

iptables -t nat -L POSTROUTING -v -n

Először az interfész-egyezés melletti számlálót olvassa le. Ha a forrás tartománya helyes, a kimeneti oldal viszont hibás, a javítás egyetlen szó a szabályban, nem pedig egy teljesen új szabály.

Keresse meg a nevet, amelyet a kernel valóban rögzít

Azonosítsa az alagút eszközét név szerint, mielőtt megírja a szabályt, az interfészek listáját használva az emlékezet helyett. Hídba kötött OpenVPN beállításnál az eszköz általában a szerver által létrehozott tap-interfész, és a neve a helyi konfiguráció része, nem egyetemes állandó. Erősítse meg, hogy létezik, amíg az alagút fut, mert egy eszköz, amely csak egy kliens csatlakozása után jelenik meg, egy korábbi tesztet szabályproblémának láttat.

ip -brief link

Írja fel a nevet. Ebben a diagnózisban minden későbbi parancs rá hivatkozik, és egy elgépelés itt pontosan ugyanazt a nulla számlálót adja, mint az eredeti hiba.

Írja át a szabályt az alagút eszközére

Irányítsa a szabályt az alagút eszközére, és tartsa meg az ügyféltartományt illeszkedési feltételként, hogy lefedje az alagútforgalmat, és békén hagyja a gazdagép saját kapcsolatait. Helyettesítse be a saját tartományát és eszköznevét, mert az alábbi két példa példa, és egyik sem hordozható telepítések között.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

Ezután ellenőrizze a másik két feltételt, amelyet ugyanez a tünet elrejt. Ellenőrizze, hogy a továbbítás engedélyezve van-e, és ha nem, engedélyezze a disztribúció saját konfigurációjában, nem pedig egy echo-val, amely újraindításkor eltűnik. Olvassa le a forward-lánc számlálóit is, és ha eldobja az alagútforgalmat, kifejezetten engedélyezze azt az interfészt, és hagyja érintetlenül a lánc szabályzatát.

A forward-lánc számlálókkal való kiolvasása egyetlen parancsba kerül, és kizárja a fennmaradó lehetőségek felét, mielőtt egy másik szabályhoz hozzányúlna.

Miért nem illeszkedik soha a fizikai kártya

A híd egy szoftverkapcsoló, amely a tap-eszközből és egy fizikai interfészből áll. A kliens kerete belép ebbe a kapcsolóba, és a fizikai hálózat felé a híd tagjaként lép ki, nem a kártyán lévő csomagként. Ezért a kernel a csomagot a hídhoz és annak portjához rendeli, és éppen ezért nem jelenik meg soha az illeszkedésben az a kártya, amelyre gondolt. A fizikai interfésszel nincs semmi baj; egyszerűen nem az az eszköz, amelyhez a kernel azt a csomagot rendeli.

A következő probléma, amelybe az emberek belefutnak, ugyanebből a szerkezetből jön: a keretszűrés egy hídon külön létesítmény az IP-szűréstől. Ha a követelmény keretszintű korlátozás, a hídszűréshez tartozik, nem egy IP-tábla szabályához.

Bizonyítsa végig, aztán tegye tartóssá

Indítson el egyetlen klienst, és pingeljen valamit a szerver helyi hálózatán; ez az útvonal továbbítást gyakorol minden fordítás nélkül. Ezután kérjen valami nyilvánosat, hogy a masquerade-szabályt használni kelljen, és olvassa le újra a számlálót: ennél a tesztnél kell mozdulnia, nem az előzőnél. Az alagút eszközén vett rögzítés megmutatja, hol jelenik meg a keret, és milyen címet hordoz.

Utolsó lépés: tegye a működő szabályokat abba a konfigurációba, amelyet újraindítás olvas, és jegyezze fel annak az eszköznek a nevét, amelyet ennek a gazdagépnek a hídja valóban használ. Bármi, amit kézzel gépeltek, eltűnik újraindítás után, és ugyanaz a hiba tér vissza anélkül, hogy bármi megmagyarázná.

Ha a számláló az átírás után sem mozdul, hasonlítsa össze a szabály forrástartományát azzal a címmel, amelyet a kliens valóban kapott, mert egy hídba kötött szerver olyan tartományból is oszthat címeket, amelyet nem szándékolt.