VPN tarpinė įranga Raspberry Pi: viena tinklo plokštė ar atskiras kliento prievadas
Vienas Pi prievadas gali aptarnauti pasirinktus klientus, arba antras prievadas gali uždaryti įrenginius viduje. Pasirinkite schemą pagal atskyrimą, atsarginę politiką ir tai, kam priklauso DNS.
Turite vieną Pi, vieną veikiantį išeinantį VPN profilį ir du įrenginius, kurie turėtų pasiekti internetą per jį. Klausimas, kuris lemia visą konstrukciją, yra ne tai, kurio vadovo laikytis, o tai, kiek atskyrimo jums reikia. Vienas prievadas leidžia Pi stovėti šalia tų įrenginių maršrutizatoriaus LAN tinkle ir veikti kaip papildoma tarpinė įranga; antras prievadas leidžia juos įdėti į segmentą, kuriame Pi yra vienintelė išeitis. Viskas po šio pasirinkimo — DHCP, ugniasienės apimtis, DNS, nutrūkimo atvejis — kyla iš jo.
Kuo abi schemos iš tikrųjų skiriasi
Abi konstrukcijos maršrutizuoja. Skirtumas tas, kas dar stovi ant kabelio ir kas nutinka, kai jūsų politika neteisinga.
| 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 |
Atskyrimas yra tikroji ašis. Schema A yra patariamoji: įrenginys, kuris nepaiso DHCP suteiktos tarpinės ir pasirenka maršrutizatorių, vis tiek veikia, bet be šifravimo. Schema B įgyvendinama topologija, nes nėra kito kito šuolio, kurį būtų galima pasirinkti.
Schema A: Pi kaip papildoma tarpinė įranga esamame LAN tinkle
Tarkime, ISP maršrutizatorius yra 192.168.50.1, Pi yra 192.168.50.2, o pasirinkti klientai rodo į Pi. Svarbu tai, kad du skirtingi paketų srautai dalijasi vienu kabeliu. Kliento vidinis paketas atvyksta į Pi ir turi išvykti per tunelį; Pi nuosavas šifruotas paketas VPN partneriui turi išvykti tuo pačiu kabeliu link maršrutizatoriaus. Jie juda priešingomis kryptimis per tą pačią sąsają ir reikalauja skirtingo apdorojimo.
Suteikite Pi jo adresą per įdiegtą tinklo tvarkyklę, o ne per seną sąsajos failo receptą, kuris su ja kovoja dėl įrenginio. Tada nustatykite klientus: statinę tarpinę viename įrenginyje arba DHCP rezervaciją, kuri išduoda 192.168.50.2 kaip maršrutizatorių. Nekeiskite viso maršrutizatoriaus DHCP diapazono dėl dviejų įrenginių ir nedarykite prielaidos, kad klientas gerbia šią parinktį — patikrinkite.
Silpnybė yra struktūrinė, o ne pataisoma. Bet kuris to segmento klientas gali rodyti į 192.168.50.1 ir išeiti atvirai, o įrenginys su antrąja sąsaja ar mobiliuoju radiju visiškai palieka jūsų vykdymo kelią. Jei šis sakinys yra nepriimtinas atitinkamam įrenginiui, atsakymas jau yra: naudokite schemą B.
Schema B: atskiras prievadas uždaro įrenginius viduje
Čia Pi išlaiko 192.168.50.2 ryšio linijoje su tarpine 192.168.50.1 ir antroje sąsajoje paima 10.20.0.1/24 prijungtiems įrenginiams. Dabar Pi yra maršrutizatorius su dviem tinklais, o prijungtas segmentas turi tiksliai vieną išėjimą.
Prieš įsipareigodami patikrinkite diapazoną su viskuo kitu: paties tunelio potinkliu, kitais tarpais tarp svetainių ir viskuo, kas pasiekiama per VPN. 10.20.0.0/24, kuri susiduria su nutolusiu LAN, duoda tą pusiau veikiantį rezultatą, kurio diagnostika kainuoja visą vakarą. Jei antras prievadas yra USB adapteris, patvirtinkite, kad jis palaikomas, ir užfiksuokite jo pavadinimą tinklo tvarkyklėje, kad pertvarkymas po perkrovimo nepajudintų jūsų LAN adreso.
Paleiskite DHCP klausytoją tik toje sąsajoje. Serveris, atsakantis ryšio linijoje, konkuruoja su ISP maršrutizatoriumi ir dalija jūsų segmento adresus likusiai namų daliai. Pririškite jį prie LAN sąsajos, apribokite deklaruotu diapazonu ir laikykite Pi nuosavą adresą už baseino ribų.
Peradresavimas, vertimas ir užsidarymo esant gedimui taisyklė
Keturi dalykai dažnai apibūdinami kaip vienas ir nėra. Peradresavimo įjungimas (net.ipv4.ip_forward=1) tik pasako branduoliui, kad jis gali perkelti paketus tarp sąsajų; jis pats savaime nieko neleidžia ir negarantuoja jokio kelio. Išėjimo pasirinkimas yra maršrutizavimo sprendimas. Paketo leidimas yra politikos sprendimas forward grandinėje. Jo šaltinio perrašymas yra postrouting sprendimas. Konstrukcija, daranti tik pirmąjį, duoda Pi, kuris džiaugsmingai peradresuoja klientų srautą lauk per ryšio liniją.
Apribokite leidimą tomis šaltiniais, kuriuos turėjote omenyje, ir ta sąsaja, kurią srautas turi naudoti, ir įtraukite grįžtamąjį kelią bei Pi reikalingus tikslus. Tada verskite tunelio išėjime, jei tiekėjas nenukreipia jūsų LAN priešdėlio atgal į jus. nftables vadovas peradresavimą, vietinę išvestį ir šaltinio vertimą traktuoja kaip atskiras operacijas, ir tai čia yra teisingas mąstymo modelis.
Įprasta klaida yra plati masquerade taisyklė fizinėje sąsajoje. Tada srautas pasiekia internetą ISP keliu, o iš kliento pusės atrodo lygiai kaip veikiantis VPN. Tai nieko neįrodo. Laikykite vertimą pririštą prie deklaruotos išėjimo ir laikykite savo taisykles ugniasienėje, kurią hostas jau naudoja, o ne pridėkite konkuruojantį taisyklių rinkinį, kuris ištuština bendrą postrouting grandinę.
Tada spręskite tunelio nebuvimą. Kliento profilis, įdiegiantis platų numatytąjį maršrutą, taip pat reiškia, kad tuneliui nukritus įprastas numatytasis gali grįžti ir kliento srautas tyliai grįžta į ryšio liniją. Ten, kur grįžimas prie atviro teksto yra nepriimtinas, forward politika turi aiškiai atmesti srautą iš kliento į ryšio liniją, būsenoje, kai VPN maršrutas dingo. Rašykite tai kaip atmetimo taisyklę, o ne kaip prielaidą. Pi nuosavas šifruotas transportas VPN partneriui yra atskiras local-output srautas ir turi likti leidžiamas, kitaip tunelis niekada negalės grįžti.
DNS ir IPv6 turi savo atsakymą
Jei klientai naudoja Pi kaip sprendėją, jie pasiekia vietinį klausytoją ir Pi pradeda naują užklausą. Ta aukštyn einanti užklausa seka Pi nuosavu maršrutu, o ne forward taisykle, kurią parašėte klientams, todėl kliento kelias tik per tunelį ir sprendėjas, išeinantis tiesiogiai, yra nutekėjimas be jokio klaidos pranešimo. Nuspręskite sąmoningai: sprendėjas, pasiekiamas per tunelį, ar vietinis, kurį priimate kaip tiesioginį, ir suderinkite Pi nuosavą išvesties politiką su tuo sprendimu.
IPv6 vėl yra atskiras atvejis. IPv4 forward taisyklė nieko neapriboja dėl IPv6, o maršrutizatoriaus skelbimai ryšio linijoje gali duoti Pi ir per jį prijungtam segmentui antrą numatytąjį, kuris apeina jūsų politiką. Arba suteikite IPv6 savo apsaugotą kelią tuo pačiu principu, arba aiškiai apribokite jį klientų segmente ir pasakykite tai.
Išbandykite ribą prieš ja pasitikėdami
Priimkite projektą tik po keturių atskirų patikrų, nes viliojantis vienintelis testas — atidaryti naršyklę viename kliente — praeina keliose sugedusiose būsenose.
Patvirtinkite, kad vienas tikras klientas pasiekia internetą per tunelį, tada patvirtinkite, kad tas pats klientas negali pasiekti interneto tunelį nuleidus. Patvirtinkite, kad DNS sprendimas veikia ir užklausa išeina ten, kur ketinote. Patvirtinkite, kad Pi nuosavas transportas vis dar veikia po tunelio paleidimo iš naujo, ir kad atkūrimas nereikalauja mašinos perkrovimo. Galiausiai patikrinkite įrenginį, kurio nepasirinkote: pagal schemą A jis turėtų toliau veikti normaliai, o pagal schemą B jo tame segmente apskritai neturėtų būti.
- Du prievadai ir atmetimo taisyklė duoda vykdymą; vienas prievadas ir DHCP parinktis duoda patarimą.
- Vertimas neteisingoje sąsajoje atrodo kaip sėkmė ir ja nėra.
- Pi nuosavas srautas, DNS ir IPv6 kiekvienas reikalauja sprendimo, o ne išvados.