VPN-lüüs Raspberry Pi peal: üks võrgukaart või eraldi kliendiport
Üks Pi port võib teenindada valitud kliente või teine port saab seadmed sisse sulgeda. Valige lahendus isoleerituse, varuplaanipoliitika ja DNSi omandi järgi.
Teil on üks Pi, üks töötav väljuv VPN-profiil ja kaks seadet, mis peaksid selle kaudu internetti jõudma. Küsimus, mis määrab kogu ehituse, ei ole see, millist juhendit järgida, vaid kui palju isoleeritust vajate. Üks port laseb Pil seista nende seadmete kõrval ruuteri LAN-is ja toimida lisalüüsina; teine port laseb teil panna need segmenti, kus Pi on ainus väljapääs. Kõik pärast seda valikut — DHCP, tulemüüri ulatus, DNS, katkestuse juhtum — tuleneb sellest.
Milles need kaks lahendust tegelikult erinevad
Mõlemad lahendused marsruudivad. Erinevus on selles, kes veel kaablil seisab ja mis juhtub, kui teie poliitika on vale.
| 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 |
Tegelik telg on isoleeritus. Lahendus A on soovituslik: seade, mis eirab DHCP antud lüüsi ja valib ruuteri, töötab ikka, kuid krüpteerimata. Lahendus B on topoloogiaga peale surutud, sest valida pole ühtegi teist järgmist hüpet.
Lahendus A: Pi kui lisalüüs olemasolevas LAN-is
Oletame, et ISP ruuter on 192.168.50.1, Pi on 192.168.50.2 ja valitud kliendid osutavad Pi peale. Tähtis on see, et kaks erinevat paketivoogu jagavad ühte kaablit. Kliendi sisemine pakett jõuab Pile ja peab väljuma tunnelist; Pi enda krüpteeritud pakett VPN partneri poole peab väljuma sama kaabli kaudu ruuteri poole. Nad liiguvad vastassuundades üle sama liidese ja vajavad erinevat käsitlust.
Andke Pile aadress paigaldatud võrguhalduri kaudu, mitte vana liidesefaili retsepti järgi, mis võitleb sellega seadme pärast. Seejärel seadistage kliendid: staatiline lüüs ühel seadmel või DHCP reserveering, mis annab 192.168.50.2 ruuterina. Ärge muutke ruuteri tervet DHCP vahemikku kahe seadme pärast ja ärge eeldage, et klient seda valikut austab — kontrollige seda.
Nõrkus on struktuurne, mitte parandatav. Iga klient selles segmendis võib osutada 192.168.50.1 peale ja väljuda krüpteerimata, ning teise liidese või mobiilraadioga seade lahkub teie jõustamisteed täielikult. Kui see lause on kõnealuse seadme jaoks vastuvõetamatu, on vastus teil juba olemas: kasutage lahendust B.
Lahendus B: eraldi port sulgeb seadmed sisse
Siin hoiab Pi ülesvooluühendusel 192.168.50.2 lüüsiga 192.168.50.1 ja võtab teisel liidesel 10.20.0.1/24 ühendatud seadmete jaoks. Nüüd on Pi kahe võrguga ruuter ja ühendatud segmendil on täpselt üks väljapääs.
Kontrollige vahemikku kõige muu vastu enne kohustumist: tunneli enda alamvõrk, teised saidi-vahelised prefiksid ja kõik, mis on VPN kaudu kättesaadav. 10.20.0.0/24, mis põrkab kokku kaugema LAN-iga, annab selle pooltöötava tulemuse, mille diagnoosimine võtab õhtu. Kui teine port on USB adapter, kinnitage, et see on toetatud, ja kinnitage selle nimi võrguhalduris, et taaskäivituse järgne ümberjärjestus ei liigutaks teie LAN aadressi.
Käivitage DHCP kuulaja ainult sellel liidesel. Server, mis vastab ülesvooluühendusel, konkureerib ISP ruuteriga ja jagab teie segmendi aadressid ülejäänud majale. Siduge see LAN liidesega, piirake deklareeritud vahemikuga ja hoidke Pi enda aadress basseinist väljas.
Edastamine, tõlkimine ja rikke korral sulgemise reegel
Nelja asja kirjeldatakse sageli ühena ja need ei ole üks. Edastamise sisselülitamine (net.ipv4.ip_forward=1) ütleb tuumale ainult, et see tohib pakette liideste vahel liigutada; see iseenesest ei luba midagi ega garanteeri ühtegi teed. Väljundi valimine on marsruutimisotsus. Paketi lubamine on poliitikaotsus forward ahelas. Selle allika ümberkirjutamine on postrouting otsus. Ehitus, mis teeb ainult esimest, annab Pi, mis edastab rõõmsalt kliendiliiklust ülesvooluühendusest välja.
Piirake luba nende allikatega, mida mõtlesite, ja selle liidesega, mida liiklus peaks kasutama, ning lisage tagasitee ja Pi enda vajalikud sihtkohad. Seejärel tõlkige tunneli väljundis, kui teenusepakkuja ei marsruudi teie LAN prefiksit teie juurde tagasi. nftablesi käsiraamat käsitleb edastamist, kohalikku väljundit ja allika tõlkimist eraldi toimingutena, mis on siin õige mõttemudel.
Tavaline rike on lai masquerade reegel füüsilisel liidesel. Siis jõuab liiklus internetti ISP tee kaudu, näidates kliendi poolelt täpselt töötava VPN-ina. See ei tõesta midagi. Hoidke tõlkimine deklareeritud väljundi küljes ja hoidke oma reeglid tulemüüris, mida host juba kasutab, selle asemel et lisada konkureeriv reeglistik, mis tühjendab jagatud postrouting ahela.
Seejärel tegelege tunneli puudumisega. Kliendiprofiil, mis paigaldab laia vaikimisi marsruudi, tähendab ka seda, et kui tunnel alla kukub, võib tavaline vaikimisi marsruut tagasi tulla ja kliendiliiklus naaseb vaikselt ülesvooluühendusse. Seal, kus selge tekstiga tagasilangus ei ole vastuvõetav, peab forward poliitika kliendilt ülesvooluühendusse suunduva liikluse selgesõnaliselt keelama, selles olekus, kus VPN marsruut on kadunud. Kirjutage see keeldumisreeglina, mitte oletusena. Pi enda krüpteeritud transport VPN partneri poole on eraldi local-output voog ja peab jääma lubatuks, muidu ei saa tunnel kunagi tagasi tulla.
DNS ja IPv6 vajavad omaette vastust
Kui kliendid kasutavad Pi resolvijana, jõuavad nad kohaliku kuulajani ja Pi algatab uue päringu. See ülesvoolu päring järgib Pi enda marsruuti, mitte forward reeglit, mille kirjutasite klientidele, seega klienditee ainult läbi tunneli pluss otse väljuv resolvija on leke ilma ühegi veateateta. Otsustage teadlikult: tunnelist kättesaadav resolvija või kohalik, mille aktsepteerite otsesena, ja viige Pi enda väljundpoliitika selle otsusega kooskõlla.
IPv6 on jälle eraldi juhtum. IPv4 forward reegel ei piira IPv6 osas midagi ja ruuteri teated ülesvooluühendusel võivad anda Pile, ja selle kaudu ühendatud segmendile, teise vaikimisi marsruudi, mis läheb teie poliitikast mööda. Kas andke IPv6-le sama põhimõtte järgi oma kaitstud tee, või piirake seda kliendisegmendis selgesõnaliselt ja öelge seda.
Testige piiri enne, kui usaldate seda
Nõustuge lahendusega alles pärast nelja eraldi kontrolli, sest ahvatlev üksiktest — brauseri avamine ühes kliendis — läbib mitmes katkises olekus.
Kinnitage, et üks tegelik klient jõuab internetti läbi tunneli, seejärel kinnitage, et sama klient ei jõua internetti, kui tunnel on maas. Kinnitage, et DNS resolvimine töötab ja päring väljub sealt, kust kavatsesite. Kinnitage, et Pi enda transport töötab pärast tunneli taaskäivitust edasi ja et taastumine ei nõua masina taaskäivitust. Lõpuks kontrollige seadet, mida te ei valinud: lahenduse A korral peaks see tavaliselt edasi töötama ja lahenduse B korral ei peaks see selles segmendis üldse eksisteerima.
- Kaks porti ja keeldumisreegel annavad jõustamise; üks port ja DHCP valik annavad nõu.
- Tõlkimine valel liidesel näeb välja nagu edu ja seda ei ole.
- Pi enda liiklus, DNS ja IPv6 vajavad igaüks otsust, mitte järeldust.