VPN brána na Raspberry Pi: jeden síťový port, nebo vyhrazený klientský port
Jeden port Pi může obsloužit vybrané klienty, nebo druhý port může zařízení uzavřít dovnitř. Vyberte uspořádání podle izolace, politiky při výpadku a podle toho, komu patří DNS.
Máte jedno Pi, jeden funkční odchozí VPN profil a dvě zařízení, která by se přes něj měla dostat na internet. Otázka, která rozhoduje celou stavbu, není kterého návodu se držet, ale kolik izolace potřebujete. Jeden port nechá Pi stát vedle těch zařízení v LAN routeru a působit jako další brána; druhý port vám umožní umístit je do segmentu, kde je Pi jediným východem. Všechno po této volbě — DHCP, rozsah firewallu, DNS, případ výpadku — z ní vyplývá.
V čem se obě uspořádání skutečně liší
Obě konstrukce směrují. Rozdíl je v tom, kdo další stojí na kabelu a co se stane, když je vaše politika špatná.
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
Skutečnou osou je izolace. Uspořádání A je doporučující: zařízení, které ignoruje bránu přidělenou DHCP a zvolí router, stále funguje, ale nešifrovaně. Uspořádání B je vynuceno topologií, protože není jiný další skok, který by šlo zvolit.
Uspořádání A: Pi jako další brána ve stávající LAN
Předpokládejme, že router ISP je 192.168.50.1, Pi je 192.168.50.2 a vybraní klienti míří na Pi. Důležité je, že dva různé toky paketů sdílejí jeden kabel. Vnitřní paket klienta dorazí do Pi a musí odejít tunelem; vlastní šifrovaný paket Pi k VPN protějšku musí odejít stejným kabelem k routeru. Putují opačnými směry po stejném rozhraní a potřebují různé zacházení.
Přidělte Pi adresu přes nainstalovaného správce sítě, ne přes starý recept s konfiguračním souborem rozhraní, který s ním o zařízení soupeří. Pak nastavte klienty: statická brána na jednom zařízení, nebo DHCP rezervace, která vydává 192.168.50.2 jako router. Neměňte celý rozsah DHCP routeru kvůli dvěma zařízením a nepředpokládejte, že klient tuto volbu respektuje — ověřte to.
Slabina je strukturální, ne opravitelná. Jakýkoli klient v tom segmentu může mířit na 192.168.50.1 a odejít bez šifrování, a zařízení s druhým rozhraním nebo mobilním rádiem opouští vaši vynucovací cestu úplně. Pokud je ta věta pro dotyčné zařízení nepřijatelná, odpověď už máte: použijte uspořádání B.
Uspořádání B: vyhrazený port zařízení uzavře dovnitř
Tady si Pi drží 192.168.50.2 na uplinku s bránou 192.168.50.1 a na druhém rozhraní vezme 10.20.0.1/24 pro připojená zařízení. Pi je teď router se dvěma sítěmi a připojený segment má přesně jeden východ.
Zkontrolujte rozsah proti všemu ostatnímu, než se zavážete: vlastní podsíť tunelu, další prefixy mezi lokalitami a cokoli dostupného přes VPN. 10.20.0.0/24, která koliduje se vzdálenou LAN, dává ten polofunkční výsledek, jehož diagnostika stojí celý večer. Pokud je druhý port USB adaptér, ověřte, že je podporovaný, a zafixujte jeho jméno ve správci sítě, aby přečíslování po restartu nepohnulo vaší adresou LAN.
Spusťte DHCP posluchač jen na tomto rozhraní. Server, který odpovídá na uplinku, soupeří s routerem ISP a rozdává adresy vašeho segmentu zbytku domácnosti. Přivažte ho k rozhraní LAN, omezte ho na deklarovaný rozsah a držte vlastní adresu Pi mimo pool.
Přeposílání, překlad a pravidlo uzavření při výpadku
Čtyři věci se často popisují jako jedna a nejsou. Zapnutí přeposílání (net.ipv4.ip_forward=1) jen říká jádru, že smí přesouvat pakety mezi rozhraními; samo o sobě nic nepovoluje a nezaručuje žádnou cestu. Volba výstupu je rozhodnutí o směrování. Povolení paketu je rozhodnutí o politice v řetězci forward. Přepsání jeho zdroje je rozhodnutí postrouting. Stavba, která dělá jen to první, vytvoří Pi, které ochotně přeposílá klientský provoz ven přes uplink.
Omezte povolení na zdroje, které jste mysleli, a na rozhraní, které má provoz použít, a zahrňte zpáteční cestu a vlastní potřebné cíle Pi. Pak překládejte na výstupu tunelu, pokud poskytovatel nesměruje váš prefix LAN zpět k vám. manuál nftables pojímá přeposílání, místní výstup a překlad zdroje jako oddělené operace, což je tady správný myšlenkový model.
Častou poruchou je široké pravidlo masquerade na fyzickém rozhraní. Provoz se pak dostane na internet cestou ISP, zatímco z pohledu klienta vypadá přesně jako fungující VPN. Nic to nedokazuje. Držte překlad vázaný na deklarovaný výstup a držte svá pravidla ve firewallu, který hostitel už používá, místo abyste přidávali konkurenční sadu pravidel, která vyčistí sdílený řetězec postrouting.
Pak řešte nepřítomnost tunelu. Klientský profil, který instaluje širokou výchozí cestu, také znamená, že když tunel spadne, běžná výchozí cesta se může vrátit a klientský provoz se tiše vrací na uplink. Tam, kde návrat k otevřenému textu není přijatelný, musí politika forward výslovně odmítnout provoz z klienta na uplink, ve stavu, kdy je cesta VPN pryč. Napište to jako pravidlo reject, ne jako předpoklad. Vlastní šifrovaný přenos Pi k VPN protějšku je samostatný tok local-output a musí zůstat povolen, jinak se tunel nikdy nevrátí.
DNS a IPv6 potřebují vlastní odpověď
Pokud klienti používají Pi jako resolver, narazí na místní posluchač a Pi zahájí nový dotaz. Tento dotaz nahoru sleduje vlastní cestu Pi, ne pravidlo forward, které jste napsali pro klienty, takže klientská cesta jen tunelem plus resolver, který vychází přímo, je únik bez jakékoli chybové zprávy. Rozhodněte se vědomě: resolver dostupný přes tunel, nebo místní, který přijímáte jako přímý, a slučte vlastní výstupní politiku Pi s tímto rozhodnutím.
IPv6 je zase zvlášť. Pravidlo forward pro IPv4 nic neomezuje ohledně IPv6 a ohlášení routeru na uplinku mohou dát Pi, a skrze ni připojenému segmentu, druhou výchozí cestu, která obchází vaši politiku. Buď dejte IPv6 vlastní chráněnou cestu na stejném principu, nebo ji v klientském segmentu výslovně omezte a řekněte to.
Otestujte hranici, než jí uvěříte
Přijměte návrh až po čtyřech samostatných kontrolách, protože lákavý jediný test — otevřít prohlížeč na jednom klientu — projde v několika rozbitých stavech.
Ověřte, že jeden skutečný klient dosáhne internetu tunelem, a pak ověřte, že stejný klient nedosáhne internetu s vypnutým tunelem. Ověřte, že rozlišení DNS funguje a že dotaz vychází tam, kam jste chtěli. Ověřte, že vlastní přenos Pi po restartu tunelu stále funguje a že obnova nevyžaduje restart stroje. Nakonec zkontrolujte zařízení, které jste nevybrali: v uspořádání A má dál normálně fungovat a v uspořádání B v tom segmentu vůbec nemá existovat.
- Dva porty a pravidlo odmítnutí dávají vynucení; jeden port a volba DHCP dávají radu.
- Překlad na špatném rozhraní vypadá jako úspěch a není.
- Vlastní provoz Pi, DNS a IPv6 každé potřebují rozhodnutí, ne odvození.