Raspberry Pi as VPN-gateway: een netwerkkaart of ’n toegewyde kliëntpoort

Jy het een Pi, een werkende uitgaande VPN-profiel, en twee toestelle wat deur dit die internet moet bereik. Die vraag wat die hele bouwerk bepaal, is nie watter gids om te volg nie, maar hoeveel afskorting jy nodig het. ’n Enkele poort laat die Pi langs daardie toestelle op die router se LAN sit en as ’n ekstra gateway optree; ’n tweede poort laat jou hulle op ’n segment plaas waar die Pi die enigste uitweg is. Alles ná daardie keuse — DHCP, firewall-omvang, DNS, die onderbrekingsgeval — volg daaruit.

Waarin die twee uitlegte werklik verskil

Albei ontwerpe doen routering. Die verskil is wie anders op die draad staan en wat gebeur wanneer jou beleid verkeerd is.

Afskorting is die werklike as. Uitleg A is adviserend: ’n toestel wat jou DHCP-verskafte gateway ignoreer en die router kies, werk steeds, onversleuteld. Uitleg B word deur topologie afgedwing, want daar is geen ander volgende sprong om te kies nie.

Uitleg A: die Pi as ’n ekstra gateway op die bestaande LAN

Aanvaar die ISP-router is 192.168.50.1, die Pi is 192.168.50.2, en die gekose kliënte wys na die Pi. Wat saak maak, is dat twee verskillende pakketstrome een kabel deel. Die kliënt se binnepakket kom by die Pi aan en moet deur die tonnel vertrek; die Pi se eie versleutelde pakket na die VPN-eweknie moet deur dieselfde kabel na die router vertrek. Hulle beweeg in teenoorgestelde rigtings oor dieselfde koppelvlak en het verskillende behandeling nodig.

Gee die Pi sy adres deur die geïnstalleerde netwerkbestuurder eerder as ’n ou koppelvlaklêer-resep wat daarmee om die toestel veg. Stel dan die kliënte: ’n statiese gateway op een toestel, of ’n DHCP-reservering wat 192.168.50.2 as router uitdeel. Moenie die router se hele DHCP-omvang vir twee toestelle verander nie, en moenie aanvaar dat ’n kliënt die opsie respekteer nie — verifieer dit.

Die swakheid is struktureel eerder as herstelbaar. Enige kliënt op daardie segment kan na 192.168.50.1 wys en onversleuteld vertrek, en ’n toestel met ’n tweede koppelvlak of ’n sellulêre radio verlaat jou afdwingingspad heeltemal. As daardie sin vir die betrokke toestel onaanvaarbaar is, het jy reeds jou antwoord: gebruik Uitleg B.

Uitleg B: ’n toegewyde poort keer die toestelle in

Hier hou die Pi 192.168.50.2 op die oplyn met gateway 192.168.50.1, en neem 10.20.0.1/24 op ’n tweede koppelvlak vir die aangehegte toestelle. Die Pi is nou ’n router met twee netwerke, en die aangehegte segment het presies een uitgang.

Kontroleer die reeks teen alles anders voordat jy vaslê: die tonnel se eie subnet, ander werf-tot-werf-voorvoegsels, en alles wat deur die VPN bereikbaar is. ’n 10.20.0.0/24 wat met ’n afgeleë LAN bots, lewer die soort halfwerkende resultaat wat ’n aand se diagnose verg. As die tweede poort ’n USB-aanpas is, bevestig dat dit ondersteun word en pen sy naam in die netwerkbestuurder vas sodat ’n herrangskikking ná herbegin nie jou LAN-adres verskuif nie.

Laat die DHCP-luisteraar net op daardie koppelvlak loop. ’n Bediener wat op die oplyn antwoord, kompeteer met die ISP-router en deel jou segment se adresse aan die res van die huis uit. Bind dit aan die LAN-koppelvlak, beperk dit tot die verklaarde reeks, en hou die Pi se eie adres uit die poel.

Aanstuur, vertaling en die reël om by faling toe te maak

Vier dinge word dikwels as een beskryf en is nie. Om aanstuur te aktiveer (net.ipv4.ip_forward=1) sê net vir die kern dat hy pakkette tussen koppelvlakke mag skuif; dit laat niks op sigself toe nie en waarborg geen pad nie. Om die uitgang te kies is ’n routeringsbesluit. Om die pakket toe te laat is ’n beleidsbesluit in die forward-ketting. Om sy bron te herskryf is ’n postrouting-besluit. ’n Bouwerk wat net die eerste doen, lewer ’n Pi wat kliëntverkeer vrolik deur die oplyn aanstuur.

Beperk die toestemming tot die bronne wat jy bedoel het en die koppelvlak wat die verkeer moet gebruik, en sluit die terugpad en die Pi se eie vereiste bestemmings in. Vertaal dan op die tonnel-uitgang as die verskaffer nie jou LAN-voorvoegsel terug na jou roeteer nie. Die nftables-handleiding behandel aanstuur, plaaslike uitvoer en bronvertaling as aparte bewerkings, wat hier die regte denkmodel is.

Die algemene fout is ’n breë masquerade-reël op die fisiese koppelvlak. Verkeer bereik dan die internet deur die ISP-pad terwyl dit van die kliënt se kant af presies soos ’n werkende VPN lyk. Dit bewys niks. Hou vertaling gekoppel aan die verklaarde uitgang, en hou jou reëls in die firewall wat die gasheer reeds gebruik eerder as om ’n mededingende reëlstel by te voeg wat ’n gedeelde postrouting-ketting leegmaak.

Hanteer dan die afwesigheid van die tonnel. ’n Kliëntprofiel wat ’n breë verstekroete installeer, beteken ook dat wanneer die tonnel val, die gewone verstek kan terugkom en kliëntverkeer stilweg na die oplyn terugkeer. Waar terugval na duidelike teks nie aanvaarbaar is nie, moet die forward-beleid kliënt-na-oplyn-verkeer eksplisiet weier, in die toestand waarin die VPN-roete weg is. Skryf dit as ’n reject-reël, nie as ’n aanname nie. Die Pi se eie versleutelde vervoer na die VPN-eweknie is ’n aparte local-output-stroom en moet toegelaat bly, anders kan die tonnel nooit terugkom nie.

DNS en IPv6 het hul eie antwoord nodig

As kliënte die Pi as oplosser gebruik, tref hulle ’n plaaslike luisteraar en die Pi begin ’n nuwe navraag. Daardie opstroom-navraag volg die Pi se eie roete, nie die forward-reël wat jy vir kliënte geskryf het nie, so ’n kliëntpad wat net deur die tonnel gaan plus ’n oplosser wat direk uitgaan is ’n lek sonder enige foutboodskap. Besluit doelbewus: ’n oplosser wat deur die tonnel bereik word, of ’n plaaslike een wat jy as direk aanvaar, en maak die Pi se eie uitvoerbeleid by daardie besluit pas.

IPv6 is weer apart. ’n IPv4-forward-reël beperk niks omtrent IPv6 nie, en router-advertensies op die oplyn kan vir die Pi, en daardeur die aangehegte segment, ’n tweede verstek gee wat jou beleid omseil. Gee IPv6 óf sy eie beskermde pad op dieselfde beginsel, óf beperk dit eksplisiet op die kliëntsegment en sê so.

Toets die grens voordat jy dit vertrou

Aanvaar die ontwerp eers ná vier afsonderlike kontroles, want die verleidelike enkele toets — maak ’n blaaier op een kliënt oop — slaag in verskeie gebrekkige toestande.

Bevestig dat een werklike kliënt die internet deur die tonnel bereik, en bevestig dan dat dieselfde kliënt nie die internet kan bereik met die tonnel af nie. Bevestig dat DNS-resolusie werk en dat die navraag vertrek waar jy bedoel het. Bevestig dat die Pi se eie vervoer ná ’n tonnel-herbegin steeds werk, en dat herstel nie ’n herbegin van die stelsel vereis nie. Kyk laastens na ’n toestel wat jy nie gekies het nie: onder Uitleg A moet dit normaal aanhou werk, en onder Uitleg B moet dit glad nie op daardie segment bestaan nie.

• Twee poorte en ’n weier-reël gee afdwinging; een poort en ’n DHCP-opsie gee advies.
• Vertaling op die verkeerde koppelvlak lyk soos sukses en is dit nie.
• Die Pi se eie verkeer, DNS en IPv6 het elkeen ’n besluit nodig, nie ’n afleiding nie.