VPN brána na Raspberry Pi: jedna sieťová karta alebo samostatný klientsky port

Máte jedno Pi, jeden funkčný odchádzajúci profil VPN a dve zariadenia, ktoré by sa mali cez neho dostať na internet. Otázka, ktorá rozhoduje celú stavbu, nie je, ktorého návodu sa držať, ale koľko izolácie potrebujete. Jeden port nechá Pi stáť vedľa tých zariadení v LAN routera a pôsobiť ako ďalšia brána; druhý port vám umožní umiestniť ich do segmentu, kde je Pi jediným východom. Všetko po tejto voľbe — DHCP, rozsah firewallu, DNS, prípad výpadku — z nej vyplýva.

Čím sa obe usporiadania naozaj líšia

Obe riešenia smerujú. Rozdiel je v tom, kto ešte stojí na kábli a čo sa stane, keď je vaša politika nesprávna.

Izolácia je skutočná os. Usporiadanie A je odporúčajúce: zariadenie, ktoré ignoruje bránu pridelenú DHCP a vyberie router, stále funguje, ale bez šifrovania. Usporiadanie B je vynútené topológiou, pretože nie je iný ďalší skok na výber.

Usporiadanie A: Pi ako ďalšia brána v existujúcej LAN

Predpokladajme, že router ISP je 192.168.50.1, Pi je 192.168.50.2 a vybraní klienti ukazujú na Pi. Dôležité je, že dva rôzne toky paketov zdieľajú jeden kábel. Vnútorný paket klienta prichádza na Pi a musí odísť cez tunel; vlastný šifrovaný paket Pi k partnerovi VPN musí odísť tým istým káblom k routeru. Pohybujú sa opačnými smermi po tom istom rozhraní a potrebujú odlišné zaobchádzanie.

Dajte Pi jeho adresu cez nainštalovaného správcu siete, nie cez starý recept s konfiguračným súborom rozhrania, ktorý s ním súperí o zariadenie. Potom nastavte klientov: statickú bránu na jednom zariadení alebo DHCP rezerváciu, ktorá vydáva 192.168.50.2 ako router. Nemeňte celý rozsah DHCP routera pre dve zariadenia a nepredpokladajte, že klient túto voľbu rešpektuje — overte to.

Slabina je štrukturálna, nie opraviteľná. Každý klient v tom segmente môže ukázať na 192.168.50.1 a odísť v otvorenom texte, a zariadenie s druhým rozhraním alebo mobilným rádiom opúšťa vašu cestu presadzovania úplne. Ak je tá veta pre príslušné zariadenie neprijateľná, odpoveď už máte: použite usporiadanie B.

Usporiadanie B: samostatný port uzavrie zariadenia vnútri

Tu si Pi drží 192.168.50.2 na odchádzajúcom spoji s bránou 192.168.50.1 a na druhom rozhraní vezme 10.20.0.1/24 pre pripojené zariadenia. Pi je teraz router s dvoma sieťami a pripojený segment má presne jeden východ.

Skontrolujte rozsah voči všetkému ostatnému, kým sa zaviažete: vlastná podsieť tunela, ďalšie medzilokalitné prefixy a všetko dostupné cez VPN. 10.20.0.0/24, ktorá koliduje so vzdialenou LAN, dáva ten polofunkčný výsledok, ktorého diagnostika stojí celý večer. Ak je druhý port USB adaptér, overte, že je podporovaný, a zafixujte jeho názov v správcovi siete, aby prečíslovanie po reštarte nepohlo vašou adresou LAN.

Spustite DHCP poslucháč len na tomto rozhraní. Server, ktorý odpovedá na odchádzajúcom spoji, súperí s routerom ISP a rozdáva adresy vášho segmentu zvyšku domácnosti. Priviažte ho k rozhraniu LAN, obmedzte ho na deklarovaný rozsah a držte vlastnú adresu Pi mimo fondu.

Preposielanie, preklad a pravidlo zatvorenia pri výpadku

Štyri veci sa často opisujú ako jedna a nie sú. Zapnutie preposielania (net.ipv4.ip_forward=1) len hovorí jadru, že smie presúvať pakety medzi rozhraniami; samo o sebe nič nepovoľuje a nezaručuje žiadnu cestu. Výber východu je rozhodnutie o smerovaní. Povolenie paketu je rozhodnutie o politike v reťazci forward. Prepis jeho zdroja je rozhodnutie postrouting. Stavba, ktorá robí len prvé, dáva Pi, ktoré ochotne preposiela klientsku prevádzku von odchádzajúcim spojom.

Obmedzte povolenie na zdroje, ktoré ste mali na mysli, a na rozhranie, ktoré má prevádzka používať, a zahrňte spätnú cestu a vlastné potrebné ciele Pi. Potom prekladajte na výstupe tunela, ak poskytovateľ nesmeruje váš prefix LAN späť k vám. manuál nftables chápe preposielanie, lokálny výstup a preklad zdroja ako oddelené operácie, čo je tu správny myšlienkový model.

Častou poruchou je široké pravidlo masquerade na fyzickom rozhraní. Potom sa prevádzka dostane na internet cestou ISP, zatiaľ čo z pohľadu klienta vyzerá presne ako fungujúca VPN. Nič to nedokazuje. Držte preklad viazaný na deklarovaný výstup a držte svoje pravidlá vo firewalle, ktorý hostiteľ už používa, namiesto pridania konkurenčnej sady pravidiel, ktorá vyprázdni zdieľaný reťazec postrouting.

Potom riešte neprítomnosť tunela. Klientsky profil, ktorý nainštaluje širokú predvolenú trasu, tiež znamená, že keď tunel padne, bežná predvolená trasa sa môže vrátiť a klientska prevádzka sa ticho vráti na odchádzajúci spoj. Tam, kde návrat k otvorenému textu nie je prijateľný, musí politika forward výslovne odmietnuť prevádzku od klienta k odchádzajúcemu spoju, v stave, keď je trasa VPN preč. Napíšte to ako pravidlo odmietnutia, nie ako predpoklad. Vlastná šifrovaná doprava Pi k partnerovi VPN je samostatný tok local-output a musí zostať povolená, inak sa tunel nikdy nevráti.

DNS a IPv6 potrebujú vlastnú odpoveď

Ak klienti používajú Pi ako resolver, narazia na lokálneho poslucháča a Pi začne nový dotaz. Ten dotaz nahor sleduje vlastnú trasu Pi, nie pravidlo forward, ktoré ste napísali pre klientov, takže klientska cesta len cez tunel plus resolver, ktorý vychádza priamo, je únik bez akéhokoľvek chybového hlásenia. Rozhodnite sa vedome: resolver dostupný cez tunel, alebo lokálny, ktorý prijímate ako priamy, a zosúlaďte vlastnú výstupnú politiku Pi s týmto rozhodnutím.

IPv6 je opäť samostatný prípad. Pravidlo forward pre IPv4 nič neobmedzuje ohľadne IPv6 a ohlásenia routera na odchádzajúcom spoji môžu dať Pi a cez neho pripojenému segmentu druhú predvolenú trasu, ktorá obchádza vašu politiku. Buď dajte IPv6 vlastnú chránenú cestu podľa toho istého princípu, alebo ho výslovne obmedzte na klientskom segmente a povedzte to.

Otestujte hranicu, kým jej uveríte

Prijmite návrh až po štyroch samostatných kontrolách, pretože lákavý jediný test — otvorenie prehliadača na jednom klientovi — prejde v niekoľkých pokazených stavoch.

Overte, že jeden skutočný klient dosiahne internet cez tunel, potom overte, že ten istý klient nedosiahne internet s vypnutým tunelom. Overte, že rozlišovanie DNS funguje a dotaz vychádza tam, kam ste zamýšľali. Overte, že vlastná doprava Pi po reštarte tunela ešte funguje a že obnova nevyžaduje reštart stroja. Nakoniec skontrolujte zariadenie, ktoré ste nevybrali: v usporiadaní A má fungovať normálne ďalej, a v usporiadaní B v tom segmente vôbec nemá existovať.

• Dva porty a pravidlo odmietnutia dávajú presadzovanie; jeden port a voľba DHCP dávajú radu.
• Preklad na nesprávnom rozhraní vyzerá ako úspech a nie je.
• Vlastná prevádzka Pi, DNS a IPv6 každé potrebuje rozhodnutie, nie odvodenie.