VPN-átjáró Raspberry Pi-n: egy hálózati kártya vagy külön kliensport

Van egy Pi-je, egy működő kimenő VPN-profilja és két eszköze, amelyeknek rajta keresztül kellene elérniük az internetet. A kérdés, amely az egész építést eldönti, nem az, hogy melyik útmutatót kövesse, hanem hogy mennyi elkülönítésre van szüksége. Egyetlen port hagyja, hogy a Pi ezen eszközök mellett álljon a router LAN-ján, és további átjáróként működjön; egy második port lehetővé teszi, hogy olyan szegmensbe tegye őket, ahol a Pi az egyetlen kifelé vezető út. Minden, ami e választás után jön — DHCP, a tűzfal hatóköre, DNS, a kiesés esete — abból következik.

Miben különbözik valójában a két elrendezés

Mindkét terv forgalmat irányít. A különbség az, hogy ki más áll a kábelen, és mi történik, ha a szabályzata hibás.

Az elkülönítés a valódi tengely. Az A elrendezés tanácsadó jellegű: az az eszköz, amely figyelmen kívül hagyja a DHCP által adott átjárót, és a routert választja, továbbra is működik, csak titkosítás nélkül. A B elrendezést a topológia kényszeríti ki, mert nincs más következő ugrás, amit választani lehetne.

A elrendezés: a Pi mint további átjáró a meglévő LAN-on

Tegyük fel, hogy az ISP router 192.168.50.1, a Pi 192.168.50.2, és a kiválasztott kliensek a Pi-re mutatnak. Az a fontos, hogy két különböző csomagfolyam osztozik egy kábelen. Az ügyfél belső csomagja megérkezik a Pi-re, és a tunelen keresztül kell távoznia; a Pi saját titkosított csomagjának a VPN-partner felé ugyanazon a kábelen kell kijutnia a router felé. Ellenkező irányban haladnak ugyanazon a csatolón, és különböző kezelést igényelnek.

A Pi címét a telepített hálózatkezelőn keresztül adja meg, ne egy régi csatolófájl-recepttel, amely az eszközért harcol vele. Ezután állítsa be a klienseket: statikus átjáró az egyik eszközön, vagy DHCP-foglalás, amely 192.168.50.2-t ad routerként. Ne változtassa meg a router teljes DHCP-tartományát két eszköz miatt, és ne feltételezze, hogy az ügyfél tiszteli a beállítást — ellenőrizze.

A gyengeség szerkezeti, nem javítható. A szegmens bármely ügyfele mutathat 192.168.50.1-re, és nyílt szövegben távozhat, a második csatolóval vagy mobilrádióval rendelkező eszköz pedig teljesen elhagyja a kényszerítési útvonalát. Ha ez a mondat elfogadhatatlan az adott eszköz számára, máris megvan a válasza: használja a B elrendezést.

B elrendezés: egy külön port bezárja az eszközöket

Itt a Pi megtartja a 192.168.50.2-t a felső kapcsolaton 192.168.50.1 átjáróval, és a második csatolón 10.20.0.1/24-et vesz fel a csatlakoztatott eszközök számára. A Pi most két hálózatú router, a csatlakoztatott szegmensnek pedig pontosan egy kijárata van.

Ellenőrizze a tartományt minden mással szemben, mielőtt elköteleződne: magának a tunelnek az alhálózata, más telephelyek közötti előtagok, és minden, ami a VPN-en keresztül elérhető. Egy 10.20.0.0/24, amely ütközik egy távoli LAN-nal, azt a félműködő eredményt adja, amelynek diagnosztizálása egy estét visz el. Ha a második port USB-adapter, erősítse meg, hogy támogatott, és rögzítse a nevét a hálózatkezelőben, hogy az újraindítás utáni átrendeződés ne mozdítsa el a LAN-címét.

A DHCP-figyelőt csak ezen a csatolón futtassa. A felső kapcsolaton válaszoló kiszolgáló verseng az ISP routerrel, és a szegmens címét a ház többi részének osztja ki. Kösse a LAN-csatolóhoz, korlátozza a bejelentett tartományra, és tartsa a Pi saját címét a poolon kívül.

Továbbítás, fordítás és a hiba esetén záró szabály

Négy dolgot gyakran egyként írnak le, és nem az. A továbbítás bekapcsolása (net.ipv4.ip_forward=1) csak azt mondja a kernelnek, hogy mozgathat csomagokat a csatolók között; önmagában semmit nem engedélyez, és semmilyen utat nem garantál. A kimenet kiválasztása útválasztási döntés. A csomag engedélyezése szabályzati döntés a forward láncban. A forrásának átírása postrouting döntés. Egy építés, amely csak az elsőt teszi, olyan Pi-t ad, amely vidáman továbbítja az ügyfélforgalmat kifelé a felső kapcsolaton.

Korlátozza az engedélyt a szándékolt forrásokra és arra a csatolóra, amelyet a forgalomnak használnia kell, és foglalja bele a visszautat és a Pi saját szükséges célállomásait. Ezután fordítson a tunel kimenetén, ha a szolgáltató nem irányítja vissza önhöz a LAN-előtagját. az nftables kézikönyve a továbbítást, a helyi kimenetet és a forrásfordítást külön műveletként kezeli, ami itt a helyes gondolkodási modell.

A gyakori hiba egy széles masquerade-szabály a fizikai csatolón. Ilyenkor a forgalom az ISP útvonalán éri el az internetet, miközben az ügyfél oldaláról pontosan úgy néz ki, mint egy működő VPN. Ez semmit nem bizonyít. Tartsa a fordítást a bejelentett kimenethez kötve, és tartsa a szabályait abban a tűzfalban, amelyet a gazdagép már használ, ahelyett hogy egy versengő szabálykészletet adna hozzá, amely kiürít egy megosztott postrouting láncot.

Ezután kezelje a tunel hiányát. Egy széles alapértelmezett útvonalat telepítő ügyfélprofil azt is jelenti, hogy amikor a tunel leesik, a szokásos alapértelmezés visszatérhet, és az ügyfélforgalom csendesen visszatér a felső kapcsolatra. Ahol a nyílt szövegre való visszaesés nem elfogadható, a forward szabályzatnak kifejezetten meg kell tagadnia az ügyféltől a felső kapcsolat felé irányuló forgalmat, abban az állapotban, amikor a VPN-útvonal eltűnt. Írja ezt elutasítási szabályként, ne feltételezésként. A Pi saját titkosított átvitele a VPN-partner felé külön local-output folyam, és engedélyezettnek kell maradnia, különben a tunel soha nem térhet vissza.

A DNS-nek és az IPv6-nak saját válasz kell

Ha az ügyfelek a Pi-t használják feloldóként, egy helyi figyelőhöz érnek, és a Pi új lekérdezést indít. Az a felső lekérdezés a Pi saját útvonalát követi, nem a forward szabályt, amelyet az ügyfeleknek írt, ezért az csak a tunelen át vezető ügyfélút plusz egy közvetlenül kimenő feloldó hibaüzenet nélküli szivárgás. Döntsön szándékosan: a tunelen keresztül elérhető feloldó, vagy egy helyi, amelyet közvetlenként elfogad, és igazítsa a Pi saját kimeneti szabályzatát ehhez a döntéshez.

Az IPv6 megint külön eset. Az IPv4-hez tartozó forward szabály semmit nem korlátoz az IPv6-tal kapcsolatban, és a felső kapcsolaton érkező routerhirdetések második alapértelmezést adhatnak a Pi-nek, és rajta keresztül a csatlakoztatott szegmensnek, amely megkerüli a szabályzatát. Vagy adjon az IPv6-nak saját védett utat ugyanazon az elven, vagy korlátozza kifejezetten az ügyfélszegmensen, és mondja ki.

Tesztelje a határt, mielőtt megbízik benne

Csak négy külön ellenőrzés után fogadja el a tervet, mert a csábító egyetlen teszt — böngésző megnyitása egy ügyfélen — több törött állapotban is átmegy.

Erősítse meg, hogy egy valódi ügyfél eléri az internetet a tunelen keresztül, majd erősítse meg, hogy ugyanaz az ügyfél nem éri el az internetet, amikor a tunel le van állítva. Erősítse meg, hogy a DNS-feloldás működik, és a lekérdezés onnan távozik, ahonnan szerette volna. Erősítse meg, hogy a Pi saját átvitele a tunel újraindítása után is működik, és a helyreállítás nem igényel gép-újraindítást. Végül ellenőrizzen egy eszközt, amelyet nem választott ki: az A elrendezésben továbbra is normálisan kell működnie, a B elrendezésben pedig egyáltalán nem szabadna léteznie azon a szegmensen.

• Két port és egy elutasítási szabály kényszerítést ad; egy port és egy DHCP-beállítás tanácsot ad.
• A fordítás a rossz csatolón sikernek látszik, és nem az.
• A Pi saját forgalmának, a DNS-nek és az IPv6-nak mindegyikének döntés kell, nem következtetés.