Nyilvános előtag OpenVPN-en át: a visszaút javítása

Figyelje, ahogy a tunel felépül és a kliens pingeli a túloldalt, majd egy nyilvános cím, amely a VPN mögött található, máshonnan válaszol, vagy egyáltalán nem válaszol. Ennek a tünetnek általában semmi köze a titkosításhoz vagy a tanúsítványokhoz. A szolgáltató által irányított előtagot IP-útvonalként szállítják, és átvinni OpenVPN keresztül azt jelenti, hogy ezt az útvonalat két szinten újra létrehozzuk, és a visszaúton megőrizzük a forráscímet. A WAN áthidalása nem szükséges, és a cím hozzáadása egy interfészhez nem hozza létre a felső útvonalat.

Az előtagot először Önhöz kell irányítani

Kérdezze meg a szolgáltatót, hogyan szállítják a blokkot. A szerver főcímére irányított előtag más, mint azok a címek, amelyeket a szolgáltató közvetlenül egy WAN-szegmensen vár. Itt csak az első modell működik a bemutatott tervezéssel.

Ha a szolgáltató a 198.51.100.64/28 tartományt a belépő szerverére irányítja, a tartomány csomagjai megérkeznek a szerverre, és ott megállnak, hacsak nem továbbítja őket. Ha a szolgáltató inkább áthidalja a tartományt az uplinkjére, a szervernek ARP-választ kell adnia rá, ami más probléma.

Tesztelje a szállítási modellt, mielőtt hozzányúl az OpenVPN-hez: kívülről pingeljen meg egy címet a blokkban, és figyelje, melyik interfész fogadja. Ha semmi nem érkezik, semmilyen tunelkonfiguráció nem segít. Ha a cím közvetlenül a WAN-on válaszol, a szolgáltató áthidal ahelyett, hogy irányítana, és az alábbi tervezés nem érvényes.

Két útválasztási szint: kernelútvonal és iroute

Az OpenVPN-nek két helyen van szüksége az előtagra. A kernelnek tudnia kell, hogy az előtag a tuneleszközé, hogy a továbbított csomagok az OpenVPN-be kerüljenek az alapértelmezett útvonal helyett. Az OpenVPN-nek azt is tudnia kell, melyik hitelesített kliens birtokolja az előtagot, és ez az iroute bejegyzés a kliensspecifikus könyvtárban.

A kiszolgáló oldali útvonal így néz ki, az előtagnak és a maszknak meg kell felelnie a kiosztásnak:

ip route add 198.51.100.64/28 dev tun0

A kliensspecifikus konfiguráció tulajdonjogot rendel. Tegye a CCD-fájlba, amelyet a kliens tanúsítvány köznapi neve után neveztek el, és erősítse meg, hogy a kiszolgáló valóban ezt a könyvtárat olvassa:

iroute 198.51.100.64 255.255.255.240

Az OpenVPN irányított hálózatokról szóló dokumentációja leírja mindkét szintet, és hogy miért különülnek el. A kernelútvonal iroute nélkül gazdátlanul küldi a csomagokat a tunelbe, és az OpenVPN eldobja őket. Az iroute a kernelútvonal nélkül a kiszolgáló alapértelmezett útvonalán hagyja a csomagokat. Mindkét hiba kliensoldalról törött tunelnek látszik.

Hol él a szolgáltatás címe

A delegált előtag nem ugyanaz, mint a tunel saját címei. Számozza a kapcsolatot a privát tartományból, ha szeretné, és helyezze a nyilvános szolgáltatáscímet oda, ahol a szolgáltatás valóban fut.

Egy Linux-kliensen, amely helyben lezárja a szolgáltatást, egyetlen hosztcím elég:

ip address add 198.51.100.70/32 dev lo

Ha az előtagot tovább irányítják egy VM-hoszthoz vagy egy másik LAN-hoz, akkor inkább azt a lefelé irányuló útvonalat és annak visszaútvonalát konfigurálja. A blokk minden címét a VPN-klienshez rendelni nem szükséges, és később ütközéseket okoz.

Tartsa meg a nyilvános forrást a visszaúton

A delegált előtagból érkező válasznak a tunelen keresztül kell kilépnie, és el kell érnie a szolgáltató útvonalát. Ha a távoli hoszt a saját ISP-jén keresztül küldi, a forráscím hamisnak tűnik, és a szolgáltató vagy a cél eldobja. A megoldás egy forrásalapú szabály vagy egy dedikált útválasztási tábla, nem egy szélesebb NAT. Enélkül a szolgáltatás a tunel partnerétől működik, és minden más helyről meghiúsul.

A belépő szerveren egy széles masquerade-szabály a szokásos bűnös. Átírja a nyilvános forrást a szerver főcímére, és a kliens soha nem látja az igazit:

iptables -t nat -S POSTROUTING

Korlátozza a NAT-ot azokra a privát VPN-kliensekre, amelyeknek szükségük van rá, és hagyja a delegált előtagot lefordítatlanul. Ezután erősítse meg, hogy a szerver egyáltalán továbbítja az előtagot, mert az alapértelmezésben tiltó továbbítási lánc csendesen eldobja.

Ellenőrizze mindkét irányt, mielőtt megbízik benne

Az ellenőrzés négy megfigyelés, nem egy. Erősítse meg, hogy megérkezik a szolgáltató útvonala, a kernel a tunelbe küldi az előtagot, az OpenVPN a megfelelő klienshez rendeli, és a válasz érintetlen nyilvános forrással tér vissza. Minden megfigyelésnek saját parancsa van, így a hiba egy rétegre mutat, nem az egész tervezésre. Minden konfigurációmódosítás után ebben a sorrendben futtassa őket.

Kérdezze meg a kernelt, melyik útvonalat veszi egy delegált cím, és figyelje a tunelt, miközben egy kérés fut:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

A fordított útvonal szűrése érvényteleníthet egy helyes útvonalat. Ellenőrizze a tényleges beállítást a tunelen és az uplinkon, és ne feledje, hogy a szigorú mód elutasítja azt a forgalmat, amelynek forrása nem egyezik azzal az interfésszel, amelyen érkezett:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Végül tesztelje a hibaesetet. Állítsa le a tunelt, és erősítse meg, hogy a nyilvános előtag nem szivárog ki a szokásos uplinkon. A VPN visszaállítása vissza kell hozza a szolgáltatást anélkül, hogy bővítené, mely portokat teszi elérhetővé a hoszt.