VPN-gateway på Raspberry Pi: ét netværkskort eller en dedikeret klientport

Du har én Pi, én fungerende udgående VPN-profil og to enheder, der skal nå internettet gennem den. Spørgsmålet, der afgør hele opbygningen, er ikke, hvilken guide du skal følge, men hvor meget inddæmning du har brug for. Én port lader Pi’en stå ved siden af de enheder på routerens LAN og fungere som ekstra gateway; en anden port lader dig sætte dem på et segment, hvor Pi’en er den eneste vej ud. Alt efter det valg — DHCP, firewallens omfang, DNS, udfaldstilfældet — følger af det.

Hvad de to opsætninger egentlig adskiller sig i

Begge designs ruter. Forskellen er, hvem der ellers står på kablet, og hvad der sker, når din politik er forkert.

Inddæmning er den egentlige akse. Opsætning A er rådgivende: en enhed, der ignorerer den DHCP-udleverede gateway og vælger routeren, virker stadig, ukrypteret. Opsætning B håndhæves af topologien, fordi der ikke er noget andet næste hop at vælge.

Opsætning A: Pi’en som ekstra gateway på det eksisterende LAN

Antag, at ISP-routeren er 192.168.50.1, at Pi’en er 192.168.50.2, og at de valgte klienter peger på Pi’en. Det afgørende er, at to forskellige pakkestrømme deler ét kabel. Klientens indre pakke ankommer til Pi’en og skal ud gennem tunnelen; Pi’ens egen krypterede pakke til VPN-partneren skal ud gennem samme kabel til routeren. De rejser i modsatte retninger over samme interface og kræver forskellig behandling.

Giv Pi’en sin adresse gennem den installerede netværksmanager i stedet for en gammel interface-fil-opskrift, der kæmper med den om enheden. Indstil derefter klienterne: en statisk gateway på én enhed, eller en DHCP-reservation, der udleverer 192.168.50.2 som router. Ændr ikke routerens samlede DHCP-område for to enheders skyld, og antag ikke, at en klient respekterer valgmuligheden — verificér det.

Svagheden er strukturel snarere end reparerbar. Enhver klient på det segment kan pege på 192.168.50.1 og gå ud i klartekst, og en enhed med et andet interface eller et mobilradio forlader helt din håndhævelsesvej. Hvis den sætning er uacceptabel for den pågældende enhed, har du allerede svaret: brug opsætning B.

Opsætning B: en dedikeret port lukker enhederne inde

Her beholder Pi’en 192.168.50.2 på uplink med gateway 192.168.50.1 og tager 10.20.0.1/24 på et andet interface til de tilsluttede enheder. Pi’en er nu en router med to netværk, og det tilsluttede segment har præcis én udgang.

Kontrollér området mod alt andet, før du binder dig: tunnelens eget subnet, andre site-til-site-præfikser og alt, hvad der er nåbart gennem VPN’en. Et 10.20.0.0/24, der kolliderer med et fjern-LAN, giver den slags halvt fungerende resultat, som koster en aften at diagnosticere. Hvis den anden port er en USB-adapter, så bekræft, at den understøttes, og fastlås dens navn i netværksmanageren, så en omrokering efter genstart ikke flytter din LAN-adresse.

Kør DHCP-lytteren på det interface alene. En server, der svarer på uplink, konkurrerer med ISP-routeren og udleverer dit segments adresser til resten af huset. Bind den til LAN-interfacet, begræns den til det erklærede område, og hold Pi’ens egen adresse uden for poolen.

Videresendelse, oversættelse og reglen om at lukke ved fejl

Fire ting beskrives ofte som én og er det ikke. At slå videresendelse til (net.ipv4.ip_forward=1) fortæller kun kernen, at den må flytte pakker mellem interfaces; det tillader intet i sig selv og garanterer ingen vej. At vælge udgangen er en rutingbeslutning. At tillade pakken er en politikbeslutning i forward-kæden. At omskrive dens kilde er en postrouting-beslutning. En opbygning, der kun gør det første, giver en Pi, som gladeligt videresender klienttrafik ud gennem uplink.

Begræns tilladelsen til de kilder, du mente, og til det interface, trafikken skal bruge, og medtag returvejen og Pi’ens egne nødvendige destinationer. Oversæt derefter på tunneludgangen, hvis udbyderen ikke ruter dit LAN-præfiks tilbage til dig. nftables-manualen behandler videresendelse, lokal udgang og kildeoversættelse som separate operationer, hvilket er den rigtige tankemodel her.

Den almindelige fejl er en bred masquerade-regel på det fysiske interface. Så når trafikken internettet ad ISP-vejen, mens den fra klientsiden ser ud præcis som en fungerende VPN. Det beviser intet. Hold oversættelsen bundet til den erklærede udgang, og hold dine regler i den firewall, værten allerede bruger, i stedet for at tilføje et konkurrerende regelsæt, der skyller en delt postrouting-kæde.

Håndtér derefter tunnelens fravær. En klientprofil, der installerer en bred standardrute, betyder også, at når tunnelen falder, kan den almindelige standardrute komme tilbage, og klienttrafikken vender stille tilbage til uplink. Hvor tilbagefald til klartekst ikke er acceptabelt, skal forward-politikken udtrykkeligt afvise trafik fra klient til uplink, i den tilstand hvor VPN-ruten er væk. Skriv det som en afvisningsregel, ikke som en antagelse. Pi’ens egen krypterede transport til VPN-partneren er en separat local-output-strøm og skal forblive tilladt, ellers kan tunnelen aldrig komme tilbage.

DNS og IPv6 har brug for deres eget svar

Hvis klienter bruger Pi’en som resolver, rammer de en lokal lytter, og Pi’en starter en ny forespørgsel. Den opstrøms forespørgsel følger Pi’ens egen rute, ikke den forward-regel, du skrev for klienterne, så en klientvej kun gennem tunnelen plus en resolver, der går direkte ud, er en lækage uden nogen fejlmeddelelse. Beslut det bevidst: en resolver, der nås gennem tunnelen, eller en lokal, du accepterer som direkte, og lad Pi’ens egen udgangspolitik matche den beslutning.

IPv6 er igen sit eget tilfælde. En forward-regel for IPv4 begrænser intet vedrørende IPv6, og routerannoncer på uplink kan give Pi’en, og gennem den det tilsluttede segment, en anden standardrute, der omgår din politik. Giv enten IPv6 sin egen beskyttede vej efter samme princip, eller begræns det udtrykkeligt på klientssegmentet og sig det.

Test grænsen, før du stoler på den

Accepter designet først efter fire separate kontroller, fordi den fristende enkelttest — åbn en browser på én klient — består i flere brudte tilstande.

Bekræft, at én rigtig klient når internettet gennem tunnelen, og bekræft derefter, at samme klient ikke kan nå internettet med tunnelen nede. Bekræft, at DNS-opslag virker, og at forespørgslen forlader det sted, du havde tænkt. Bekræft, at Pi’ens egen transport stadig virker efter en genstart af tunnelen, og at genopretning ikke kræver genstart af maskinen. Kontrollér til sidst en enhed, du ikke valgte: under opsætning A skal den fortsætte normalt, og under opsætning B skal den slet ikke findes på det segment.

• To porte og en afvisningsregel giver håndhævelse; én port og en DHCP-valgmulighed giver råd.
• Oversættelse på det forkerte interface ser ud som succes og er det ikke.
• Pi’ens egen trafik, DNS og IPv6 kræver hver en beslutning, ikke en slutning.