VPN-gateway på Raspberry Pi: ett nettverkskort eller en egen klientport

Du har én Pi, én fungerende utgående VPN-profil og to enheter som skal nå internett gjennom den. Spørsmålet som avgjør hele bygget, er ikke hvilken veiledning du følger, men hvor mye innhegning du trenger. Én port lar Pi-en stå ved siden av disse enhetene på ruterens LAN og virke som en ekstra gateway; en andre port lar deg sette dem på et segment der Pi-en er den eneste veien ut. Alt etter det valget — DHCP, brannmurens omfang, DNS, utfallstilfellet — følger av det.

Hva de to oppsettene egentlig skiller seg i

Begge designene ruter. Forskjellen er hvem andre som står på kabelen, og hva som skjer når politikken din er feil.

Innhegning er den egentlige aksen. Oppsett A er rådgivende: en enhet som ignorerer gatewayen fra DHCP og velger ruteren, virker fortsatt, men ukryptert. Oppsett B håndheves av topologien, fordi det ikke finnes noe annet neste hopp å velge.

Oppsett A: Pi-en som ekstra gateway på det eksisterende LAN-et

Anta at ISP-ruteren er 192.168.50.1, at Pi-en er 192.168.50.2, og at de valgte klientene peker på Pi-en. Det viktige er at to ulike pakkestrømmer deler én kabel. Klientens indre pakke kommer til Pi-en og må ut gjennom tunnelen; Pi-ens egen krypterte pakke til VPN-partneren må ut gjennom samme kabel til ruteren. De reiser i motsatte retninger over samme grensesnitt og trenger ulik behandling.

Gi Pi-en adressen sin gjennom den installerte nettverksbehandleren, ikke med en gammel grensesnittfil-oppskrift som slåss med den om enheten. Sett så opp klientene: en statisk gateway på én enhet, eller en DHCP-reservasjon som deler ut 192.168.50.2 som ruter. Ikke endre hele DHCP-området til ruteren for to enheters skyld, og ikke anta at en klient respekterer valget — verifiser det.

Svakheten er strukturell og ikke reparerbar. Enhver klient på det segmentet kan peke på 192.168.50.1 og gå ut i klartekst, og en enhet med et andre grensesnitt eller mobilradio forlater håndhevelsesveien din helt. Hvis den setningen er uakseptabel for den aktuelle enheten, har du allerede svaret: bruk oppsett B.

Oppsett B: en egen port lukker enhetene inne

Her beholder Pi-en 192.168.50.2 på oppkoblingen med gateway 192.168.50.1, og tar 10.20.0.1/24 på et andre grensesnitt for de tilkoblede enhetene. Pi-en er nå en ruter med to nettverk, og det tilkoblede segmentet har nøyaktig én utgang.

Kontroller området mot alt annet før du binder deg: tunnelens eget subnett, andre områdeprefikser og alt som er nåbart gjennom VPN-en. Et 10.20.0.0/24 som kolliderer med et eksternt LAN gir det halvfungerende resultatet som koster en kveld å diagnostisere. Hvis den andre porten er en USB-adapter, bekreft at den støttes, og fest navnet i nettverksbehandleren slik at en omrokering etter omstart ikke flytter LAN-adressen din.

Kjør DHCP-lytteren bare på det grensesnittet. En server som svarer på oppkoblingen, konkurrerer med ISP-ruteren og deler ut adressene i segmentet ditt til resten av huset. Bind den til LAN-grensesnittet, begrens den til det erklærte området, og hold Pi-ens egen adresse utenfor poolen.

Videresending, oversettelse og regelen om å lukke ved feil

Fire ting beskrives ofte som én og er det ikke. Å slå på videresending (net.ipv4.ip_forward=1) forteller bare kjernen at den kan flytte pakker mellom grensesnitt; det tillater ingenting i seg selv og garanterer ingen vei. Å velge utgangen er en rutingbeslutning. Å tillate pakken er en politikkbeslutning i forward-kjeden. Å skrive om kilden er en postrouting-beslutning. Et bygg som bare gjør det første, gir en Pi som gladelig videresender klienttrafikk ut gjennom oppkoblingen.

Begrens tillatelsen til kildene du mente og til grensesnittet trafikken skal bruke, og ta med returveien og Pi-ens egne nødvendige mål. Oversett så på tunnelutgangen hvis leverandøren ikke ruter LAN-prefikset ditt tilbake til deg. nftables-håndboken behandler videresending, lokal utgang og kildeoversettelse som separate operasjoner, som er den riktige tankemodellen her.

Den vanlige feilen er en bred masquerade-regel på det fysiske grensesnittet. Da når trafikken internett via ISP-veien, mens den fra klientsiden ser ut nøyaktig som en fungerende VPN. Det beviser ingenting. Hold oversettelsen bundet til den erklærte utgangen, og hold reglene dine i brannmuren verten allerede bruker, i stedet for å legge til et konkurrerende regelsett som tømmer en delt postrouting-kjede.

Håndter så fraværet av tunnelen. En klientprofil som installerer en bred standardrute betyr også at når tunnelen faller, kan standardruten komme tilbake, og klienttrafikken går stille tilbake til oppkoblingen. Der tilbakefall til klartekst ikke er akseptabelt, må forward-politikken nekte trafikk fra klient til oppkobling uttrykkelig, i den tilstanden der VPN-ruten er borte. Skriv det som en avvisningsregel, ikke som en antakelse. Pi-ens egen krypterte transport til VPN-partneren er en separat local-output-strøm og må forbli tillatt, ellers kan tunnelen aldri komme tilbake.

DNS og IPv6 trenger sitt eget svar

Hvis klienter bruker Pi-en som oppløser, treffer de en lokal lytter, og Pi-en starter en ny spørring. Den oppstrøms spørringen følger Pi-ens egen rute, ikke forward-regelen du skrev for klientene, så en klientvei bare gjennom tunnelen pluss en oppløser som går direkte ut er en lekkasje uten noen feilmelding. Bestem bevisst: en oppløser som nås gjennom tunnelen, eller en lokal du godtar som direkte, og la Pi-ens egen utgangspolitikk stemme med den beslutningen.

IPv6 er igjen sitt eget tilfelle. En forward-regel for IPv4 begrenser ingenting angående IPv6, og ruterannonser på oppkoblingen kan gi Pi-en, og gjennom den det tilkoblede segmentet, en andre standardrute som omgår politikken din. Enten gi IPv6 sin egen beskyttede vei etter samme prinsipp, eller begrens det uttrykkelig på klientssegmentet og si det.

Test grensen før du stoler på den

Godta designet først etter fire separate kontroller, fordi den fristende enkelttesten — å åpne en nettleser på én klient — består i flere ødelagte tilstander.

Bekreft at én ekte klient når internett gjennom tunnelen, og bekreft deretter at samme klient ikke når internett med tunnelen nede. Bekreft at DNS-oppslag virker, og at spørringen går ut der du mente. Bekreft at Pi-ens egen transport fortsatt virker etter en omstart av tunnelen, og at gjenoppretting ikke krever omstart av maskinen. Til slutt, kontroller en enhet du ikke valgte: under oppsett A skal den fortsette normalt, og under oppsett B skal den ikke finnes i det segmentet i det hele tatt.

• To porter og en avvisningsregel gir håndhevelse; én port og et DHCP-valg gir råd.
• Oversettelse på feil grensesnitt ser ut som suksess og er det ikke.
• Pi-ens egen trafikk, DNS og IPv6 trenger hver sin beslutning, ikke en slutning.