VPN-gateway på Raspberry Pi: ett nätverkskort eller en egen klientport

Du har en Pi, en fungerande utgående VPN-profil och två enheter som ska nå internet genom den. Frågan som avgör hela bygget är inte vilken guide du följer, utan hur mycket inneslutning du behöver. En port låter Pi:n stå bredvid de enheterna på routerns LAN och verka som en extra gateway; en andra port låter dig sätta dem på ett segment där Pi:n är den enda vägen ut. Allt efter det valet — DHCP, brandväggens omfattning, DNS, utfallsärendet — följer av det.

Vad de två uppläggen egentligen skiljer sig i

Båda designerna routar. Skillnaden är vem annars som står på kabeln och vad som händer när din policy är fel.

Inneslutning är den egentliga axeln. Upplägg A är rådgivande: en enhet som ignorerar gatewayen från DHCP och väljer routern fungerar fortfarande, men okrypterat. Upplägg B genomdrivs av topologin, eftersom det inte finns någon annan nästa hopp att välja.

Upplägg A: Pi:n som extra gateway på det befintliga LAN:et

Anta att ISP-routern är 192.168.50.1, att Pi:n är 192.168.50.2 och att de valda klienterna pekar på Pi:n. Det viktiga är att två olika paketflöden delar en kabel. Klientens inre paket kommer till Pi:n och måste ut genom tunneln; Pi:ns eget krypterade paket till VPN-partnern måste ut genom samma kabel till routern. De färdas i motsatta riktningar över samma gränssnitt och behöver olika behandling.

Ge Pi:n sin adress via den installerade nätverkshanteraren, inte med ett gammalt gränssnittsfilrecept som slåss med den om enheten. Ställ sedan in klienterna: en statisk gateway på en enhet, eller en DHCP-reservation som delar ut 192.168.50.2 som router. Ändra inte routerns hela DHCP-område för två enheters skull, och anta inte att en klient respekterar valet — verifiera det.

Svagheten är strukturell och inte reparerbar. Varje klient på det segmentet kan peka på 192.168.50.1 och gå ut i klartext, och en enhet med ett andra gränssnitt eller mobilradio lämnar helt din framtvingningsväg. Om den meningen är oacceptabel för den aktuella enheten har du redan svaret: använd upplägg B.

Upplägg B: en egen port stänger in enheterna

Här behåller Pi:n 192.168.50.2 på upplänken med gateway 192.168.50.1 och tar 10.20.0.1/24 på ett andra gränssnitt för de anslutna enheterna. Pi:n är nu en router med två nät, och det anslutna segmentet har exakt en utgång.

Kontrollera området mot allt annat innan du binder dig: tunnelns eget subnät, andra platsöverskridande prefix och allt som nås via VPN:en. Ett 10.20.0.0/24 som krockar med ett avlägset LAN ger det halvfungerande resultatet som kostar en kväll att diagnostisera. Om den andra porten är en USB-adapter, bekräfta att den stöds och fäst namnet i nätverkshanteraren så att en omordning efter omstart inte flyttar din LAN-adress.

Kör DHCP-lyssnaren bara på det gränssnittet. En server som svarar på upplänken konkurrerar med ISP-routern och delar ut adresserna i ditt segment till resten av huset. Bind den till LAN-gränssnittet, begränsa den till det deklarerade området och håll Pi:ns egen adress utanför poolen.

Vidarebefordran, översättning och regeln att stänga vid fel

Fyra saker beskrivs ofta som en och är det inte. Att slå på vidarebefordran (net.ipv4.ip_forward=1) säger bara till kärnan att den får flytta paket mellan gränssnitt; det tillåter ingenting i sig och garanterar ingen väg. Att välja utgången är ett routingbeslut. Att tillåta paketet är ett policybeslut i forward-kedjan. Att skriva om dess källa är ett postrouting-beslut. Ett bygge som bara gör det första ger en Pi som glatt vidarebefordrar klienttrafik ut genom upplänken.

Begränsa tillståndet till de källor du menade och till det gränssnitt som trafiken ska använda, och ta med returvägen och Pi:ns egna nödvändiga mål. Översätt sedan på tunnelutgången om leverantören inte routar ditt LAN-prefix tillbaka till dig. nftables-handboken behandlar vidarebefordran, lokal utgång och källöversättning som separata operationer, vilket är rätt tankemodell här.

Det vanliga felet är en bred masquerade-regel på det fysiska gränssnittet. Då når trafiken internet via ISP-vägen medan den från klientsidan ser ut precis som en fungerande VPN. Det bevisar ingenting. Håll översättningen bunden till den deklarerade utgången och håll dina regler i brandväggen som värden redan använder, i stället för att lägga till en konkurrerande regeluppsättning som tömmer en delad postrouting-kedja.

Hantera sedan avsaknaden av tunneln. En klientprofil som installerar en bred standardrutt innebär också att när tunneln faller kan den vanliga standardrutten komma tillbaka och klienttrafiken återvänder tyst till upplänken. Där återfall till klartext inte är acceptabelt, måste forward-policyn uttryckligen neka trafik från klient till upplänk, i det tillstånd där VPN-rutten är borta. Skriv det som en avvisningsregel, inte som ett antagande. Pi:ns egen krypterade transport till VPN-partnern är ett separat local-output-flöde och måste förbli tillåtet, annars kan tunneln aldrig komma tillbaka.

DNS och IPv6 behöver sitt eget svar

Om klienter använder Pi:n som resolver träffar de en lokal lyssnare och Pi:n startar en ny fråga. Den uppströms frågan följer Pi:ns egen rutt, inte forward-regeln du skrev för klienterna, så en klientväg bara genom tunneln plus en resolver som går direkt ut är ett läckage utan något felmeddelande. Bestäm medvetet: en resolver som nås genom tunneln, eller en lokal som du accepterar som direkt, och låt Pi:ns egen utpolicy matcha det beslutet.

IPv6 är återigen ett eget fall. En forward-regel för IPv4 begränsar ingenting när det gäller IPv6, och routerannonser på upplänken kan ge Pi:n, och genom den det anslutna segmentet, en andra standardrutt som kringgår din policy. Ge antingen IPv6 sin egen skyddade väg enligt samma princip, eller begränsa det uttryckligen på klientssegmentet och säg det.

Testa gränsen innan du litar på den

Acceptera designen först efter fyra separata kontroller, eftersom det frestande enskilda testet — att öppna en webbläsare på en klient — går igenom i flera trasiga tillstånd.

Bekräfta att en riktig klient når internet genom tunneln och bekräfta sedan att samma klient inte når internet med tunneln nere. Bekräfta att DNS-uppslagning fungerar och att frågan går ut där du tänkte. Bekräfta att Pi:ns egen transport fortfarande fungerar efter en omstart av tunneln och att återställningen inte kräver omstart av maskinen. Kontrollera till sist en enhet du inte valde: under upplägg A ska den fortsätta normalt, och under upplägg B ska den inte finnas på det segmentet alls.

• Två portar och en avvisningsregel ger framtvingning; en port och ett DHCP-val ger råd.
• Översättning på fel gränssnitt ser ut som framgång och är det inte.
• Pi:ns egen trafik, DNS och IPv6 behöver var sitt beslut, inte en slutsats.