Porta VPN në Raspberry Pi: një kartë rrjeti ose një portë klienti e veçantë
Një portë e Pi mund t'u shërbejë klientëve të zgjedhur, ose një portë e dytë mund t'i mbyllë pajisjet brenda. Zgjidhni skemën sipas izolimit, politikës së rezervës dhe kujt i përket DNS.
Keni një Pi, një profil VPN dalës që punon dhe dy pajisje që duhet të arrijnë internetin përmes tij. Pyetja që vendos gjithë ndërtimin nuk është cili udhëzues të ndiqet, por sa izolim ju nevojitet. Një portë e vetme lejon Pi-n të qëndrojë pranë atyre pajisjeve në LAN-in e ruterit dhe të veprojë si portë shtesë; një portë e dytë ju lejon t'i vendosni ato në një segment ku Pi është e vetmja rrugëdalje. Gjithçka pas kësaj zgjedhjeje — DHCP, shtrirja e firewall-it, DNS, rasti i ndërprerjes — rrjedh prej saj.
Në çfarë ndryshojnë vërtet dy skemat
Të dyja skemat bëjnë routing. Ndryshimi është kush tjetër qëndron në kabllo dhe çfarë ndodh kur politika juaj është e gabuar.
| 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 |
Izolimi është boshti i vërtetë. Skema A është këshilluese: një pajisje që shpërfill portën e dhënë nga DHCP dhe zgjedh ruterin vazhdon të punojë, por pa kriptim. Skema B imponohet nga topologjia, sepse nuk ka një hap tjetër tjetër për të zgjedhur.
Skema A: Pi si portë shtesë në LAN-in ekzistues
Supozoni se ruteri i ISP-së është 192.168.50.1, Pi është 192.168.50.2 dhe klientët e zgjedhur tregojnë drejt Pi. E rëndësishme është që dy rrjedha të ndryshme paketash ndajnë një kabllo. Paketa e brendshme e klientit arrin në Pi dhe duhet të dalë përmes tunelit; paketa e kriptuar e Pi vetë drejt partnerit VPN duhet të dalë përmes të njëjtës kabllo drejt ruterit. Ato udhëtojnë në drejtime të kundërta në të njëjtën ndërfaqe dhe kërkojnë trajtim të ndryshëm.
Jepini Pi adresën e tij përmes menaxherit të rrjetit të instaluar, jo përmes një recete të vjetër skedari ndërfaqeje që zihet me të për pajisjen. Pastaj konfiguroni klientët: një portë statike në një pajisje, ose një rezervim DHCP që jep 192.168.50.2 si ruter. Mos ndryshoni gjithë gamën DHCP të ruterit për dy pajisje dhe mos supozoni se një klient e respekton opsionin — verifikojeni.
Dobësia është strukturore, e pariparueshme. Çdo klient në atë segment mund të tregojë drejt 192.168.50.1 dhe të dalë në tekst të hapur, dhe një pajisje me një ndërfaqe të dytë ose radio celulare e braktis plotësisht rrugën tuaj të imponimit. Nëse ajo fjali është e papranueshme për pajisjen në fjalë, përgjigjen e keni tashmë: përdorni skemën B.
Skema B: një portë e veçantë i mbyll pajisjet brenda
Këtu Pi mban 192.168.50.2 në lidhjen lart me portën 192.168.50.1 dhe merr 10.20.0.1/24 në një ndërfaqe të dytë për pajisjet e lidhura. Tani Pi është një ruter me dy rrjete, dhe segmenti i lidhur ka saktësisht një dalje.
Kontrolloni gamën kundrejt gjithçkaje tjetër përpara se të angazhoheni: nënrrjeti i tunelit vetë, prefikset e tjera ndërmjet lokacioneve dhe çdo gjë e arritshme përmes VPN-së. Një 10.20.0.0/24 që përplaset me një LAN të largët jep atë rezultat gjysmë-pune që kushton një mbrëmje diagnostikim. Nëse porta e dytë është një përshtatës USB, konfirmoni që mbështetet dhe fiksoni emrin e tij në menaxherin e rrjetit, që një rirenditje pas rindezjes të mos e zhvendosë adresën tuaj LAN.
Ekzekutoni dëgjuesin DHCP vetëm në atë ndërfaqe. Një server që përgjigjet në lidhjen lart konkurron me ruterin e ISP-së dhe u jep adresat e segmentit tuaj pjesës tjetër të shtëpisë. Lidheni me ndërfaqen LAN, kufizojeni në gamën e deklaruar dhe mbajeni adresën e Pi vetë jashtë grupit.
Përcjellja, përkthimi dhe rregulli i mbylljes në dështim
Katër gjëra shpesh përshkruhen si një dhe nuk janë. Aktivizimi i përcjelljes (net.ipv4.ip_forward=1) i thotë vetëm kernelit se mund të lëvizë paketa midis ndërfaqeve; në vetvete nuk lejon asgjë dhe nuk garanton asnjë rrugë. Zgjedhja e daljes është një vendim routing-u. Lejimi i paketës është një vendim politike në zinxhirin forward. Rishkrimi i burimit të saj është një vendim postrouting. Një ndërtim që bën vetëm të parën prodhon një Pi që me gëzim përcjell trafikun e klientëve jashtë përmes lidhjes lart.
Kufizoni lejen në burimet që kishit ndërmend dhe në ndërfaqen që trafiku duhet të përdorë, dhe përfshini rrugën e kthimit dhe destinacionet që Pi ka nevojë. Pastaj përktheni në daljen e tunelit nëse ofruesi nuk e rrugëzon prefiksin tuaj LAN përsëri drejt jush. manualin e nftables e trajton përcjelljen, daljen lokale dhe përkthimin e burimit si operacione të ndara, që është modeli i saktë i mendimit këtu.
Dështimi i zakonshëm është një rregull masquerade i gjerë në ndërfaqen fizike. Atëherë trafiku arrin internetin përmes rrugës së ISP-së, ndërsa nga ana e klientit duket saktësisht si një VPN që punon. Kjo nuk provon asgjë. Mbajeni përkthimin të lidhur me daljen e deklaruar dhe mbajini rregullat tuaja në firewall-in që hosti tashmë përdor, në vend që të shtoni një grup rregullash konkurrues që zbraz një zinxhir postrouting të përbashkët.
Pastaj merruni me mungesën e tunelit. Një profil klienti që instalon një rrugë të gjerë të parazgjedhur do të thotë gjithashtu se, kur tuneli bie, e parazgjedhura e zakonshme mund të kthehet dhe trafiku i klientit kthehet në heshtje në lidhjen lart. Aty ku kthimi në tekst të hapur nuk është i pranueshëm, politika forward duhet të refuzojë shprehimisht trafikun nga klienti drejt lidhjes lart, në gjendjen kur rruga VPN ka humbur. Shkruajeni atë si rregull refuzimi, jo si supozim. Transporti i kriptuar i Pi vetë drejt partnerit VPN është një rrjedhë local-output e veçantë dhe duhet të mbetet i lejuar, përndryshe tuneli nuk mund të kthehet kurrë.
DNS dhe IPv6 kanë nevojë për përgjigjen e tyre
Nëse klientët përdorin Pi si zgjidhës, ata arrijnë një dëgjues lokal dhe Pi nis një kërkesë të re. Ajo kërkesë lart ndjek rrugën e Pi vetë, jo rregullin forward që shkruat për klientët, prandaj një rrugë klienti vetëm përmes tunelit plus një zgjidhës që del drejtpërdrejt është një rrjedhje pa asnjë mesazh gabimi. Vendosni me qëllim: një zgjidhës i arritshëm përmes tunelit, ose një lokal që e pranoni si të drejtpërdrejtë, dhe përshtatni politikën e daljes së Pi vetë me atë vendim.
IPv6 është përsëri rast i veçantë. Një rregull forward për IPv4 nuk kufizon asgjë në lidhje me IPv6, dhe shpalljet e ruterit në lidhjen lart mund t'i japin Pi, dhe përmes tij segmentit të lidhur, një të parazgjedhur të dytë që anashkalon politikën tuaj. Ose jepini IPv6 rrugën e tij të mbrojtur me të njëjtin parim, ose kufizojeni shprehimisht në segmentin e klientëve dhe thojeni.
Provoni kufirin përpara se t'i besoni
Pranojeni skemën vetëm pas katër kontrolleve të ndara, sepse testi i vetëm joshës — hapja e një shfletuesi në një klient — kalon në disa gjendje të prishura.
Konfirmoni që një klient i vërtetë arrin internetin përmes tunelit, pastaj konfirmoni që i njëjti klient nuk arrin internetin kur tuneli është poshtë. Konfirmoni që zgjidhja DNS punon dhe kërkesa del atje ku kishit ndërmend. Konfirmoni që transporti i Pi vetë punon ende pas një rindezjeje të tunelit dhe që rikuperimi nuk kërkon rindezje të makinës. Së fundi, kontrolloni një pajisje që nuk e zgjodhët: në skemën A duhet të vazhdojë normalisht, dhe në skemën B nuk duhet të ekzistojë fare në atë segment.
- Dy porta dhe një rregull refuzimi japin imponim; një portë dhe një opsion DHCP japin këshillë.
- Përkthimi në ndërfaqen e gabuar duket si sukses dhe nuk është.
- Trafiku i Pi vetë, DNS dhe IPv6 secili ka nevojë për një vendim, jo për një konkluzion.