VPN-gateway på Raspberry Pi: eitt nettkort eller ein eigen klientport

Du har éin Pi, éin fungerande utgåande VPN-profil og to einingar som skal nå internett gjennom han. Spørsmålet som avgjer heile bygget, er ikkje kva rettleing du følgjer, men kor mykje innhegning du treng. Éin port lèt Pi-en stå ved sida av desse einingane på LAN-et til rutaren og verke som ein ekstra gateway; ein andre port lèt deg setje dei på eit segment der Pi-en er den einaste vegen ut. Alt etter det valet — DHCP, omfanget av brannmuren, DNS, utfallstilfellet — følgjer av det.

Kva dei to oppsetta eigentleg skil seg i

Begge designa rutar. Skilnaden er kven andre som står på kabelen, og kva som skjer når politikken din er feil.

Innhegning er den eigentlege aksen. Oppsett A er rådgivande: ei eining som ignorerer gatewayen frå DHCP og vel rutaren, verkar framleis, men ukryptert. Oppsett B blir handheva av topologien, fordi det ikkje finst noko anna neste hopp å velje.

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

Gå ut frå at ISP-rutaren er 192.168.50.1, at Pi-en er 192.168.50.2, og at dei valde klientane peikar på Pi-en. Det viktige er at to ulike pakkestraumar deler éin kabel. Den indre pakka til klienten kjem til Pi-en og må ut gjennom tunnelen; den eigne krypterte pakka til Pi-en til VPN-partnaren må ut gjennom same kabel til rutaren. Dei reiser i motsette retningar over same grensesnitt og treng ulik handsaming.

Gje Pi-en adressa si gjennom den installerte nettverkshandsamaren, ikkje med ein gammal grensesnittfil-oppskrift som slåst med han om eininga. Set så opp klientane: ein statisk gateway på éi eining, eller ein DHCP-reservasjon som deler ut 192.168.50.2 som rutar. Ikkje endre heile DHCP-området til rutaren for to einingar skuld, og ikkje gå ut frå at ein klient respekterer valet — verifiser det.

Svakheita er strukturell og ikkje reparerbar. Kvar klient på det segmentet kan peike på 192.168.50.1 og gå ut i klartekst, og ei eining med eit andre grensesnitt eller mobilradio forlèt handhevingvegen din heilt. Viss den setninga er uakseptabel for den aktuelle eininga, har du allereie svaret: bruk oppsett B.

Oppsett B: ein eigen port lukkar einingane inne

Her held Pi-en 192.168.50.2 på oppkoblinga med gateway 192.168.50.1, og tek 10.20.0.1/24 på eit andre grensesnitt for dei tilkopla einingane. Pi-en er no ein rutar med to nettverk, og det tilkopla segmentet har nøyaktig éin utgang.

Kontroller området mot alt anna før du bind deg: det eigne subnettet til tunnelen, andre områdeprefiks og alt som er nåbart gjennom VPN-en. Eit 10.20.0.0/24 som kolliderer med eit eksternt LAN gjev det halvfungerande resultatet som kostar ein kveld å diagnostisere. Viss den andre porten er ein USB-adapter, stadfest at han er støtta, og fest namnet i nettverkshandsamaren slik at ei omrokkering etter omstart ikkje flyttar LAN-adressa di.

Køyr DHCP-lyttaren berre på det grensesnittet. Ein tenar som svarar på oppkoblinga, konkurrerer med ISP-rutaren og deler ut adressene i segmentet ditt til resten av huset. Bind han til LAN-grensesnittet, avgrens han til det erklærte området, og hald den eigne adressa til Pi-en utanfor bassenget.

Vidaresending, omsetjing og regelen om å lukke ved feil

Fire ting blir ofte skildra som éin og er det ikkje. Å slå på vidaresending (net.ipv4.ip_forward=1) fortel berre kjernen at han kan flytte pakkar mellom grensesnitt; det tillét ingenting i seg sjølv og garanterer ingen veg. Å velje utgangen er eit rutingsvedtak. Å tillate pakka er eit politikkvedtak i forward-kjeda. Å skrive om kjelda er eit postrouting-vedtak. Eit bygg som berre gjer det første, gjev ein Pi som gledeleg vidaresender klienttrafikk ut gjennom oppkoblinga.

Avgrens løyvet til kjeldene du meinte og til grensesnittet trafikken skal bruke, og ta med returvegen og dei eigne naudsynte måla til Pi-en. Omset så på tunnelutgangen viss leverandøren ikkje rutar LAN-prefikset ditt tilbake til deg. nftables-handboka handsamar vidaresending, lokal utgang og kjeldeomsetjing som separate operasjonar, som er den rette tankemodellen her.

Den vanlege feilen er ein brei masquerade-regel på det fysiske grensesnittet. Då når trafikken internett via ISP-vegen, medan han frå klientsida ser ut nøyaktig som ein fungerande VPN. Det provar ingenting. Hald omsetjinga bunden til den erklærte utgangen, og hald reglane dine i brannmuren verten allereie brukar, i staden for å leggje til eit konkurrerande regelsett som tømmer ei delt postrouting-kjede.

Handsam så fråværet av tunnelen. Ein klientprofil som installerer ein brei standardrute betyr også at når tunnelen fell, kan standardruta kome tilbake, og klienttrafikken går stille tilbake til oppkoblinga. Der tilbakefall til klartekst ikkje er akseptabelt, må forward-politikken nekte trafikk frå klient til oppkobling uttrykkeleg, i den tilstanden der VPN-ruta er borte. Skriv det som ein avvisingregel, ikkje som ei føresetnad. Den eigne krypterte transporten til Pi-en til VPN-partnaren er ein separat local-output-straum og må halde fram med å vere tillaten, elles kan tunnelen aldri kome tilbake.

DNS og IPv6 treng sitt eige svar

Viss klientar brukar Pi-en som oppløysar, treffer dei ein lokal lyttar, og Pi-en startar ei ny spørjing. Den oppstraums spørjinga følgjer den eigne ruta til Pi-en, ikkje forward-regelen du skreiv for klientane, så ein klientveg berre gjennom tunnelen pluss ein oppløysar som går direkte ut er ein lekkasje utan noka feilmelding. Bestem med vilje: ein oppløysar som blir nådd gjennom tunnelen, eller ein lokal du godtek som direkte, og la den eigne utgangspolitikken til Pi-en stemme med det vedtaket.

IPv6 er igjen sitt eige tilfelle. Ein forward-regel for IPv4 avgrensar ingenting når det gjeld IPv6, og rutarannonsar på oppkoblinga kan gje Pi-en, og gjennom han det tilkopla segmentet, ei andre standardrute som omgår politikken din. Anten gje IPv6 sin eigen verna veg etter same prinsipp, eller avgrens det uttrykkeleg på klientssegmentet og sei det.

Test grensa før du stolar på henne

Godta designet først etter fire separate kontrollar, fordi den freistande enkelttesten — å opne ein nettlesar på éin klient — står i fleire øydelagde tilstandar.

Stadfest at éin ekte klient når internett gjennom tunnelen, og stadfest deretter at same klient ikkje når internett med tunnelen nede. Stadfest at DNS-oppslag verkar, og at spørjinga går ut der du meinte. Stadfest at den eigne transporten til Pi-en framleis verkar etter ein omstart av tunnelen, og at attoppretting ikkje krev omstart av maskinen. Til slutt, kontroller ei eining du ikkje valde: under oppsett A skal ho halde fram normalt, og under oppsett B skal ho ikkje finnast i det segmentet i det heile.

• To portar og ein avvisingregel gjev handheving; éin port og eit DHCP-val gjev råd.
• Omsetjing på feil grensesnitt ser ut som suksess og er det ikkje.
• Den eigne trafikken til Pi-en, DNS og IPv6 treng kvar sitt vedtak, ikkje ei slutning.