A VPN-kliensek csatlakoznak, de nincs internet: három hiányzó darab

A kliens címet kap, a szerver válaszol a pingre, és mégis minden oldal időtúllépésbe fut. A legtöbben ezen a ponton kezdik szerkeszteni a kliensprofilt, ami általában hiábavaló erőfeszítés: ha az alagút áll, a szervernek routerként kell viselkednie. Három feltételnek kell egyszerre teljesülnie ahhoz, hogy egy csomag kimenjen és válasz jöjjön vissza, és a tünet ugyanaz, bármelyik is hiányzik.

Miért nincs még mindig kifelé út egy működő alagútnál

A kernelnek csomagokat kell továbbítania az interfészek között, ami a legtöbb Linux-disztribúción alapértelmezés szerint ki van kapcsolva. A forgalmat olyan címre kell fordítani, amelyre a külvilág válaszolni tud, hacsak minden felsőbb router már ismeri a visszautat az alagút alhálózatához. A tűzfal továbbítási útvonalának mindkét irányban engedélyeznie kell a forgalmat, a válaszokat is beleértve.

Ezek mindegyike külön javítható, és éppen ez a csapda. A továbbítás bekapcsolása címfordítási szabály nélkül azt eredményezi, hogy a csomagok privát forrással és visszaút nélkül mennek ki. A címfordítás hozzáadása továbbítási szabály nélkül azt eredményezi, hogy a kernel egy lépéssel később elejti a csomagot.

Tehát a három réteget tesztelje, ne a klienst, és egyszerre csak egyet változtasson, hogy az eredménynek legyen jelentése.

A továbbítás egy kernelkapcsoló, amelyet tartóssá kell tennie

Ellenőrizze a jelenlegi értéket a módosítás előtt, majd állítsa be, és erősítse meg, hogy a változás életbe lépett.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Az első parancs a jelenlegi értéket jelenti, a második futásidőben állítja be, a harmadik pedig bizonyítja, hogy az írás működött. A futásidejű érték a következő újraindításkor eltűnik, ezért egy működő munkamenet karbantartás után konfigurációváltozás nélkül is elromolhat.

Tegye tartóssá egy fájlban a /etc/sysctl.d/ alatt, majd alkalmazza azt a fájlt ahelyett, hogy újraindítana, hogy kiderüljön. FreeBSD-n a megfelelő a net.inet.ip.forwarding, a tartóssághoz pedig a gateway_enable=YES az rc.conf fájlban. Az az eszköz, amely a továbbítást kikapcsoltnak jelenti, a „csomagok érkeznek, és semmi nem jön vissza” típusú jelentések egész osztályát magyarázza. Minden frissítés után is ellenőrizze a beállítást, mert egy újraépített kernel vagy egy lecserélt eszközkép visszaállíthatja anélkül, hogy bárkinek szólna.

Válasszon masquerade-et vagy egy rögzített fordítási címet

Dinamikus külső cím esetén a masquerading a legegyszerűbb helyes forma. Nevezze meg az alagút alhálózatát forrásként, a külső interfészt pedig kijáratként.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Statikus nyilvános cím esetén a forrás fordítása pontosan arra a címre kiszámíthatóbb és könnyebben auditálható.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

A második forma karbantartási csapdát hordoz: egy keményen kódolt cím, amely később megváltozik, működésben tartja az alagutat, miközben az internet-hozzáférés csendben leáll. Vagy használjon masquerade-et, vagy frissítse a szabályt, valahányszor a szolgáltató áthelyezi. Az interfész is számít, mert egy routernek, amely a saját felsőbb alagútját osztja meg, azon az alagúton kell fordítania, nem a fizikai WAN-on.

A szűrőtábla a harmadik kapu

A továbbítás és a címfordítás is helyes lehet, miközben a csomag mégis meghal a szűrőtáblában. Az ufw gyakori bűnös: a továbbítási szabályzata DROP-ként érkezik, és a többi beállítás teljesen helyesnek tűnhet, miközben ez az egy beállítás megöli a forgalmat. Felemelni tudatos biztonsági döntés, nem jelölőnégyzet.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Az első szabály engedélyezi az új forgalmat az alagútból kifelé, a második pedig csak a válaszokat visszafelé. Szűkítse mindkettőt az alagút alhálózatára és a szándékolt célra, mert az alagút interfészén adott átfogó engedély nyitott kijárattá teszi a VPN-t bárki számára, aki hitelesíteni tud.

A hídba kötött alagút más választ kíván. A cím a hídhoz tartozik, nem a fizikai porthoz, ezért az interfész alávetése eltávolítja a korábbi címét, és a gazdagép elérhetetlennek tűnik, amíg maga a híd nem kap egyet, amit a dhclient br0 biztosíthat. Ez a hiba VPN-problémának látszik, és második rétegbeli probléma. Ellenőrizze a híd saját címét, mielőtt a tűzfalhoz nyúl, mert a szűrő módosítása nem tud megjavítani egy gazdagépet, amelynek már nincs címe, ahonnan küldhetne.

Hol nézzen, ha egy oldal soha nem töltődik be

Pingelje a szerver alagútcímét, hogy bizonyítsa az alagút létezését. Ezután futtasson traceroute-ot a kliensről egy nyilvános címre, és olvassa el, hol áll meg: a szerveren a csomag megérkezik, de nem továbbítódik és nem fordul; a szerveren túl a probléma felsőbb szinten van, és az Ön kezén kívül.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Az első parancs bizonyítja, hogy az alagút forgalmat visz magához a szerverhez, a második pedig megmutatja, milyen messzire jut egy csomag kifelé. Az alagútcímnél végződő nyom a szerver továbbítására vagy címfordítására utal, míg az egy ugrással később megálló nyom a szolgáltatóra vagy a felsőbb router visszaútjára.

A szerveren figyelje a külső interfészt, miközben egy kliens oldalt tölt. A privát forráscímmel kimenő forgalom azt jelenti, hogy hiányzik a címfordítás, a válasz teljes hiánya pedig azt, hogy a továbbítási útvonal vagy a felsőbb visszaút elejti.

Ha a távoli klienseknek a szerver LAN-ján lévő gazdagépeket is el kell érniük, ne feledje, hogy a LAN-nak visszaútra van szüksége az alagút alhálózatához. Ez útválasztás, nem címfordítás, és ez a lépés marad el leggyakrabban, miután az internetes útvonal végre működik.