VPN-poarte op Raspberry Pi: ien netwurkkaart of in aparte klantpoarte
Ien Pi-poarte kin keazen klanten betsjinje, of in twadde poarte kin apparaten binnen slute. Kies de yndieling op grûn fan isolaasje, fallback-belied en wa’t DNS hat.
Jo hawwe ien Pi, ien wurkjend útgeand VPN-profyl en twa apparaten dy’t fia him it ynternet berikke moatte. De fraach dy’t de hiele bou bepaalt, is net hokker hantlieding jo folgje, mar hoefolle isolaasje jo nedich hawwe. Ien poarte lit de Pi njonken dy apparaten op it LAN fan de router stean en as ekstra poarte wurkje; in twadde poarte lit jo se op in segmint sette dêr’t de Pi de iennichste útgong is. Alles nei dy kar — DHCP, omfang fan de firewall, DNS, it gefal fan in steuring — folget dêrút.
Wêryn’t de twa yndielings eins ferskille
Beide ûntwerpen routearje. It ferskil is wa’t der noch mear oan ’e tried stiet en wat der bart as jo belied ferkeard is.
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
Isolaasje is de echte as. Yndieling A is advisearjend: in apparaat dat de poarte fan DHCP negearret en de router kiest, wurket noch, sûnder fersifering. Yndieling B wurdt troch de topology ôftwongen, want der is gjin oare folgjende hop om te kiezen.
Yndieling A: de Pi as ekstra poarte op it besteande LAN
Stel dat de ISP-router 192.168.50.1 is, de Pi 192.168.50.2, en de keazen klanten nei de Pi wize. It wichtichste is dat twa ferskillende pakketstreamen ien kabel diele. It ynderlike pakket fan de klant komt by de Pi en moat troch de tunnel nei bûten; it eigen fersifere pakket fan de Pi nei de VPN-partner moat fia deselde kabel nei de router. Se reizgje yn tsjinoerstelde rjochtingen oer deselde interface en hawwe ferskillende behanneling nedich.
Jou de Pi syn adres fia de ynstallearre netwurkbehearder, net fia in âld resept fan in interfacebestân dat mei him om it apparaat fjochtet. Stel dan de klanten yn: in statyske poarte op ien apparaat, of in DHCP-reservearring dy’t 192.168.50.2 as router jout. Feroarje net it hiele DHCP-berik fan de router foar twa apparaten, en nim net oan dat in klant de opsje respektearret — ferifiearje it.
De swakte is struktureel en net te reparearjen. Elke klant op dat segmint kin nei 192.168.50.1 wize en iepen nei bûten, en in apparaat mei in twadde interface of in sellulêre radio ferlit jo hanthavenjingspaad hielendal. As dy sin foar it oangeande apparaat net akseptabel is, hawwe jo it antwurd al: brûk yndieling B.
Yndieling B: in aparte poarte slút de apparaten binnen
Hjir hâldt de Pi 192.168.50.2 op de uplink mei poarte 192.168.50.1, en nimt 10.20.0.1/24 op in twadde interface foar de oansletten apparaten. No is de Pi in router mei twa netwurken, en it oansletten segmint hat presys ien útgong.
Kontrolearje it berik tsjin al it oare foardat jo jo fêstlizze: it eigen subnet fan de tunnel, oare foarheaksels tusken lokaasjes, en alles wat fia de VPN berikber is. In 10.20.0.0/24 dy’t botst mei in fiert LAN jout dat healwurkjende resultaat dat in jûn diagnostyk kostet. As de twadde poarte in USB-adapter is, befêstigje dan dat dy stipe wurdt en fêstigje syn namme yn de netwurkbehearder, sadat in oare folchoarder nei it opnij opstarten jo LAN-adres net ferpleatst.
Rin de DHCP-harker allinnich op dy interface. In tsjinner dy’t op de uplink antwurdet, konkurrearret mei de ISP-router en jout de adressen fan jo segmint oan de rest fan it hûs. Bynt it oan de LAN-interface, behein it ta it oankundige berik, en hâld it eigen adres fan de Pi bûten de pool.
Trochstjoere, oersette en de regel om te sluten by in steuring
Fjouwer dingen wurde faak as ien beskreaun en binne dat net. It ynskeakeljen fan trochstjoere (net.ipv4.ip_forward=1) fertelt de kearn allinnich dat er pakketten tusken interfaces ferpleatse mei; it stiet sels neat ta en garandearret gjin paad. It kiezen fan de útgong is in routingbeslút. It tastean fan it pakket is in beliedsbeslút yn ’e forward-keten. It weromskriuwen fan syn boarne is in postrouting-beslút. In bou dy’t allinnich it earste docht, jout in Pi dy’t bliid klantferkear fia de uplink nei bûten stjoert.
Behein de tastimming ta de boarnen dy’t jo bedoelden en ta de interface dy’t it ferkear brûke moat, en nim it werompaad en de eigen needsaaklike bestimmingen fan de Pi op. Oerset dan op de útgong fan de tunnel as de provider jo LAN-foarheaksel net werom nei jo routearret. hantlieding fan nftables behannelet trochstjoere, lokale útgong en boarne-oersetting as aparte operaasjes, dat is hjir it juste tinkmodel.
De gewoane steuring is in brede masquerade-regel op ’e fysike interface. Dan berikt it ferkear it ynternet fia it ISP-paad, wylst it fan ’e klantkant krekt as in wurkjend VPN liket. Dat bewiist neat. Hâld de oersetting bûn oan ’e oankundige útgong, en hâld jo regels yn ’e firewall dy’t de host al brûkt, ynstee fan in konkurrearjende regelset ta te foegjen dy’t in dielde postrouting-keten leechmakket.
Behannelje dan it ûntbrekken fan ’e tunnel. In klantprofyl dat in breed standertpaad ynstallearret, betsjut ek dat as de tunnel falt, de gewoane standert weromkomme kin en it klantferkear stil werom nei de uplink giet. Dêr’t weromfal nei iepen tekst net akseptabel is, moat it forward-belied ferkear fan klant nei uplink eksplisyt wegerje, yn ’e steat dêr’t it VPN-paad fuort is. Skriuw dat as in wegeringsregel, net as in oanname. It eigen fersifere transport fan de Pi nei de VPN-partner is in aparte local-output-stream en moat tastien bliuwe, oars kin de tunnel nea weromkomme.
DNS en IPv6 hawwe har eigen antwurd nedich
As klanten de Pi as resolver brûke, treffe se in lokale harker en de Pi begjint in nije fraach. Dy fraach nei boppen folget it eigen paad fan ’e Pi, net de forward-regel dy’t jo foar klanten skreaun hawwe, dus in klantpaad allinnich fia de tunnel plus in resolver dy’t direkt nei bûten giet is in lek sûnder ien flaterberjocht. Beslis bewust: in resolver dy’t fia de tunnel berikt wurdt, of in lokale dy’t jo as direkt akseptearje, en meitsje it eigen útgeand belied fan de Pi dêrmei yn oerienstimming.
IPv6 is wer in apart gefal. In forward-regel foar IPv4 beheint neat oangeande IPv6, en routeroankundigings op ’e uplink kinne de Pi, en fia him it oansletten segmint, in twadde standert jaan dy’t jo belied foarby giet. Jou IPv6 óf syn eigen beskerme paad neffens itselde prinsipe, óf behein it eksplisyt op it klantsegmint en sis dat.
Test de grins foardat jo der op fertrouwe
Akseptearje it ûntwerp pas nei fjouwer aparte kontrôles, want de ferlokjende inkelde test — in browser iepenje op ien klant — slagget yn ferskate stikken steaten.
Befêstigje dat ien echte klant fia de tunnel it ynternet berikt, en befêstigje dan dat deselde klant it ynternet net berikke kin as de tunnel del is. Befêstigje dat DNS-resolúsje wurket en dat de fraach fuortgiet dêr’t jo it woene. Befêstigje dat it eigen transport fan de Pi noch wurket nei in werstart fan ’e tunnel, en dat werstel gjin werstart fan ’e masine freget. Kontrolearje ta beslút in apparaat dat jo net keazen hawwe: ûnder yndieling A moat it normaal trochwurkje, en ûnder yndieling B moat it hielendal net bestean op dat segmint.
- Twa poarten en in wegeringsregel jouwe hanthavening; ien poarte en in DHCP-opsje jouwe advys.
- Oersetting op ’e ferkearde interface liket sukses en is dat net.
- It eigen ferkear fan de Pi, DNS en IPv6 hawwe elk in beslút nedich, gjin konklúzje.