VPN atebidea Raspberry Pirekin: sare-txartel bakarra edo bezero-portu dedikatu bat
Pi portu bakar batek hautatutako bezeroak zerbitza ditzake, edo bigarren portu batek gailuak barruratu ditzake. Aukeratu diseinua edukitzearen, ordezko politikaren eta DNS nori dagokion arabera.
Pi bat, irteerako VPN profil bat eta haren bidez internetera iritsi beharko luketen bi gailu dituzu. Eraikuntza osoa erabakitzen duen galdera ez da zein gidari jarraitu, baizik eta zenbat edukitze behar duzun. Portu bakar batek Pi routerraren LANean gailu horien ondoan egotea eta atebide gehigarri gisa jardutea ahalbidetzen du; bigarren portu batek Pi irteera bakarra den segmentu batean jartzea ahalbidetzen du. Aukera horren ondorengo guztia — DHCP, suebakiaren irismena, DNS, geldialdiaren kasua — hartatik dator.
Zertan bereizten dira bi diseinuak benetan
Bi diseinuek bideratzen dute. Aldea da nor dagoen gainera kablean eta zer gertatzen den zure politika okerra denean.
| 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 |
Edukitzea da benetako ardatza. A diseinua aholku ematekoa da: DHCPk emandako atebidea alde batera uzten duen eta routerra aukeratzen duen gailuak funtzionatzen jarraitzen du, baina zifratu gabe. B diseinua topologiak behartzen du, ez baitago aukeratzeko beste jauzi bat.
A diseinua: Pi lehendik dagoen LANeko atebide gehigarri gisa
Demagun ISPren routerra 192.168.50.1 dela, Pi 192.168.50.2 dela eta aukeratutako bezeroek Pi seinalatzen dutela. Garrantzitsua da bi pakete-fluxu desberdinek kable bakarra partekatzen dutela. Bezeroaren barne-paketea Piera iristen da eta tunelaren bidez atera behar du; Pi beraren pakete zifratuak VPN kidearenera kable beretik atera behar du routerrerantz. Norabide kontrakoetan bidaiatzen dute interfaze berean eta tratamendu desberdina behar dute.
Eman Pii bere helbidea instalatutako sare-kudeatzailearen bidez, gailuaren aldean borrokatzen duen interfaze-fitxategiko errezeta zahar baten ordez. Gero ezarri bezeroak: atebide estatikoa gailu batean, edo 192.168.50.2 router gisa ematen duen DHCP erreserba bat. Ez aldatu routerraren DHCP eremu osoa bi gailuren erruz, eta ez pentsatu bezeroak aukera errespetatzen duenik — egiaztatu.
Ahultasuna egiturazkoa da, ez konpontzekoa. Segmentu horretako edozein bezerok 192.168.50.1 seinala dezake eta argi atera, eta bigarren interfazea edo irrati mugikorra duen gailu batek zure betearazpen-bidea erabat uzten du. Esaldi hori arbuiagarria bada gailuarentzat, erantzuna baduzu: erabili B diseinua.
B diseinua: portu dedikatu batek gailuak barruan ixten ditu
Hemen Pik 192.168.50.2 mantentzen du goranzko estekan 192.168.50.1 atebidearekin, eta 10.20.0.1/24 hartzen du bigarren interfazean konektatutako gailuetarako. Pi orain bi sare dituen routerra da, eta konektatutako segmentuak irteera bakarra du.
Egiaztatu barrutia gainerako guztiaren aurka konprometitu aurretik: tunelaren azpisarea, beste gune arteko aurrizkiak eta VPNaren bidez iristeko modukoa den guztia. Urruneko LAN batekin bat egiten duen 10.20.0.0/24 batek arratsalde bat diagnostikatzen ematen duen erdi-funtzionatzen duen emaitza sortzen du. Bigarren portua USB egokigailua bada, egiaztatu onartua dela eta finkatu bere izena sare-kudeatzailean, berrabiarazi ondorengo berrantolaketak zure LAN helbidea mugi ez dezan.
Exekutatu DHCP entzulea interfaze horretan soilik. Goranzko estekan erantzuten duen zerbitzari batek ISPren routerrarekin lehiatzen du eta zure segmentuko helbideak etxeko gainerakoei ematen dizkie. Lotu LAN interfazera, mugatu deklaratutako barrutira eta eduki Piren helbidea beraren gordailutik kanpo.
Birbidalketa, itzulpena eta hutsegitean ixteko araua
Lau gauza bakartzat deskribatzen dira sarritan eta ez dira. Birbidalketa gaitzeak (net.ipv4.ip_forward=1) nukleoari bakarrik esaten dio paketeak interfazeen artean mugi ditzakeela; berez ez du ezer baimentzen eta ez du biderik bermatzen. Irteera aukeratzea bideratze-erabakia da. Paketea baimentzea forward kateko politika-erabakia da. Bere iturria berridaztea postrouting erabakia da. Lehenengoa bakarrik egiten duen eraikuntzak bezeroen trafikoa pozik goranzko estekatik birbidaltzen duen Pi bat lortzen du.
Mugatu baimena pentsatu zenituen iturrietara eta trafikoak erabili behar duen interfazera, eta sartu itzulera-bidea eta Pik behar dituen helmugak. Gero itzuli tunelaren irteeran, hornitzaileak zure LAN aurrizkia zuregana birbideratzen ez badu. nftables eskuliburua birbidalketa, irteera lokala eta iturri-itzulpena eragiketa bereizi gisa tratatzen ditu, eta hori da hemen pentsaera-eredu egokia.
Hutsegite arrunta interfaze fisikoan masquerade arau zabal bat da. Orduan trafikoak ISP bidearen bidez iristen da internetera, bezeroaren aldetik funtzionatzen duen VPN baten itxura zehatza duen bitartean. Horrek ez du ezer frogatzen. Eduki itzulpena deklaratutako irteerari lotuta, eta eduki zure arauak hostak dagoeneko erabiltzen duen suebakian, postrouting kate partekatua husten duen arau-multzo lehiakor bat gehitzen ibili gabe.
Gero aurre egin tunelaren absentziari. Bide lehenetsi zabal bat instalatzen duen bezero-profilak esan nahi du, halaber, tunela erortzen denean, ohiko lehenetsia itzul daitekeela eta bezero-trafikoa isilka goranzko estekara itzultzen dela. Non testu arruntera itzultzea onargarria ez den, forward politikak bezerotik goranzko estekarako trafikoa espresuki ukatu behar du, VPN bidea desagertu den egoeran. Idatzi hori ukapen-arau gisa, ez suposizio gisa. Piren garraio zifratua VPN kidearenera local-output fluxu bereizia da eta baimenduta egon behar du, bestela tunelak ez du inoiz itzuliko.
DNSek eta IPv6k beren erantzuna behar dute
Bezeroek Pi ebazle gisa erabiltzen badute, tokiko entzule batera iristen dira eta Pik kontsulta berria sortzen du. Goiko kontsulta horrek Piren bide propioa jarraitzen du, bezeroentzat idatzi zenuen forward araua ez, beraz tunelaren bidez soilik doan bezero-bide bat eta zuzenean irteten den ebazle bat errorerik gabeko ihesa da. Erabaki nahita: tunelaren bidez iristen den ebazle bat, edo zuzentzat onartzen duzun tokiko bat, eta egin Piren irteera-politika erabaki horrekin bat.
IPv6 berriro kasu bereizia da. IPv4rako forward arau batek ez du ezer mugatzen IPv6ri dagokionez, eta goranzko estekako router iragarkiek Pii, eta haren bidez konektatutako segmentuari, zure politika saihesten duen bigarren lehenetsia eman diezaiekete. Edo eman IPv6ri bere bide babestua printzipio berarekin, edo mugatu espresuki bezero-segmentuan eta esan.
Proba ezazu muga fidatu aurretik
Onartu diseinua lau egiaztapen bereizi ondoren soilik, proba bakun tentagarriak — bezero batean nabigatzailea irekitzea — egoera hondatu batzuetan gainditzen baitu.
Egiaztatu benetako bezero batek internetera tunelaren bidez iristen dela, gero egiaztatu bezero berak ezin duela internetera iritsi tunela behera dagoenean. Egiaztatu DNS ebazpena funtzionatzen duela eta kontsulta nahi zenuen lekutik irteten dela. Egiaztatu Piren garraioak tunela berrabiarazi ondoren ere funtzionatzen duela, eta berreskurapenak ez duela makinaren berrabiarazterik eskatzen. Azkenik, aukeratu ez zenuen gailu bat egiaztatu: A diseinuan normaltasunez funtzionatzen jarraitu beharko luke, eta B diseinuan ez luke segmentu horretan existitu behar.
- Bi portuk eta ukapen-arau batek betearazpena ematen dute; portu batek eta DHCP aukera batek aholkua ematen dute.
- Interfaze okerrean itzultzeak arrakasta dirudi eta ez da.
- Piren trafikoak berak, DNSek eta IPv6k bakoitzak erabaki bat behar du, ez ondorio bat.