Piko hotspot bezeroek ez dute etxeko LANera iristen TUN VPN baten bidez

Tokiko Wi-Fi eta Ethernet bezeroak Pi-ren hotspotera konektatzen dira, haren DHCP barrutitik helbide bat hartzen dute eta interneteko orriak kexarik gabe kargatzen dituzte. Bezero berberek, gero, denbora agortzen dute etxeko LANeko fitxategi partekatze bat edo web interfaze bat irekitzean, Pi bera tunelaren bidez LAN horretara iristen den bitartean. Haririk gabeko geruzan ez dago ezer hautsita. Faltan dagoena kontratu bideratua da: hotspot aurrizkia TUN interfazera eraman behar da, eta etxeko aldean zerbait jakin behar du erantzunak hara nola bidali. Bi erdiek existitu behar dute pakete bakar batek joan-etorria osatu ahal izateko.

Hiru konexio, hiru lan desberdinekin

Linux Ethernet zubi batek markoak helburuko MAC helbidearen arabera birbidaltzen ditu. OpenVPN TUN moduan IP paketeak garraiatzen ditu eta ez du MAC geruzarik batere, beraz zubi lokal bat gehitzeak ez du tunela inoiz portu gisa inskribatzen. kernelaren TUN/TAP dokumentazioak banaketa hori azaltzen du: TAP gailu bat Ethernet interfaze baten antzekoa da, TUN gailu bat ez. Bi portu lokal zubitu eta gero bideratzen dituen diseinua bideratzaile bat da, interfazeen izenek zer esan ere.

Bereizketa horrek jabetza erabakitzen du. Bezeroen azpisarea, haien ate lehenetsia eta barruti horren DHCP autoritatea Pi-ren plan lokalarenak dira. Etxeko DHCP difusioek ez dute tunel bideratua zeharkatzen, eta zubi ezarpen batek ere ez du hori aldatzen; bezeroak etxeko DHCP zerbitzari batera bideratzea beste errele diseinu bat da, nahita egina eta bere porrot moduekin.

Eduki modem-a bezeroen zubitik kanpo ere. PPP konexio bat ez da etiketa desberdineko Ethernet gailu bat, eta pppd-ren dokumentatutako bide lehenetsiaren logika IPCP negoziazioaren ondoren exekutatzen da eta bere bidea erretiratzen du esteka hori erortzen denean. DHCP txantiloi bat kopiatu eta usb0 bakoitza ppp0 izendatzeak ez du ezer frogatzen ate, metrika edo bizi-zikloari buruz.

Aukeratu aurrizkiak edozein konfigurazio editatu aurretik

Aurrizki gainjarriek suebaki arauek baino arratsalde gehiago galtzen dituzte, gainjartze batek bide bilaketa interfaze okerrean jartzen baitu tunela osasuntsu dagoenean ere. Hasi Pi-n dagoeneko existitzen dena zerrendatzen, eta gero irakurri emaitza lau igerileku bereizi gisa.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

Lehen igerilekua operadoreak modemari eman zion underlay helbidea da; bezeroei begira dagoen edozein planetik kanpo egon behar du. Bigarrena zerbitzariak aukeratutako tunel azpisarea da, askotan bere /24 pribatu bat. Hirugarrena hotspot zubia da, eta laugarrena lortu nahi duzun etxeko aurrizkia. Ibilbide honetan hotspot-ak 172.28.90.0/24 jasotzen du zubia 172.28.90.1-n duelarik, eta etxeko zerbitzu LAN-ak 192.168.77.0/24 gordetzen du, eta horrek kontsumo bideratzaileek dakarten 192.168.1.0/24 eta 10.0.0.0/24 lehenetsiak eta 100.64.0.0/10 operadore barrutia saihesten ditu.

Iragarri zubiaren helbidea ate gisa hotspot-aren DHCP barrutian eta besterik ez. Inoiz ez eman hotspot bezeroei etxeko helbiderik ate gisa; ez dute esteka mailako biderik segmentu horretara.

Bideratu norabide bakoitza hura duen aldean

Pi-k bide bat behar du etxeko aurrizkirako tunelaren bidez. Zerbitzari moduan dauden zerbitzariek bide hori bultzatzen dute normalean, beraz lehenengo egiaztatu birbidalketa aktibatuta dagoela eta kernel-ak etxeko helbide bat tun0-tik ebazten duela.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Tokiko ip route get-k oraindik underlay interfazea salatzen badu, gelditu hor; bidean aurrerago ezerk ezin du bilaketa oker bat konpondu.

Etxeko gailuek ez dute 172.28.90.0/24-rako biderik, beraz haien erantzunek ate lehenetsia jarraitzen dute eta bideratzailean hiltzen dira. Bi konponketa onartu daude. Edo gehitu bide estatiko bat etxeko bideratzailean hotspot aurrizkia VPN zerbitzariaren LAN helbidera bideratzen duena, edo, zerbitzaria bera atea denean, erregistratu bezeroaren aurrizkia zerbitzariaren beraren bideratze taulan. OpenVPN-ren bezero anitzeko moduan bezeroaren direktorio espezifikoak elkarte hori darama: bezeroaren ziurtagiriaren izen arruntaren arabera izendatutako fitxategi bat, iroute 172.28.90.0 255.255.255.0 gehi route lerro parekidea duelarik, zerbitzariaren kernel-ean instalatzen duena. Zerbitzarian asmatutako kernel bide bat ez da adierazpen bera zerbitzariari zein bezerok duen aurrizkia esatea.

Ez ezazu eraman etxeko sarearen DHCP zerbitzua VPN zerbitzarira hori funtziona dezan. Etxe oso baterako ate lehenetsia ordezkatzea bide pribatu bat gehitzea baino aldaketa askoz handiagoa da, eta DNS, helbide erreserbak eta alokairu berria alde batera uzten duen gailu oro porrotera eramaten ditu.

Ireki birbidalketa suebakia asmatu gabe

Birbidalketa aktibatuta egoteak ez du esan nahi paketea pasatzen denik. Zubitik tunelera doan trafikoak iragazte arauak jotzen ditu oraindik, eta drop birbidaltze politika lehenetsi batek hotspot trafikoa botatzen du Pi-ren trafiko propioak funtzionatzen jarraitzen duen bitartean, eta horrek goiko sintoma zatitua sortzen du zehazki.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Bilatu br0-tik tun0-rako onarpen arau bat eta erantzun norabide parekidea, eta iturria berridatzi dezakeen postrouting araua. Katearen politika drop bada eta arazorik bat datorrela ez bada, gehitu onarpen estuak eta berriro probatu politika accept-era biratu beharrean.

Itzulpena politika aukera bat da, ez baldintza bat. Etxeko LANera doan iturri NAT-ak hotspot bezero bakoitza Pi-ren tunel helbidearen antzeko egiten du, eta horrek bezero bakoitzeko egozpena galtzen du etxeko erregistroetan eta jatorrizko iturria espero duten zerbitzuak apurtzen ditu. NAT gabe bideratzeak bezeroen helbideak ikusgai mantentzen ditu baina goiko itzulera bidearen mende dago. Aukeratu bat eta tratatu DNS eta IPv6 modu berean, IPv6 bide hautsitik ondoan funtzionatzen duen IPv4 bide batek oraindik erdi-hautsita irakurtzen baita nabigatzailean.

Egiaztatu joan-etorria, eta gero hautsi ezazu nahita

Probatu hotspot bezero batetik, inoiz ez Pi-tik, Pi-ren trafiko propioak aurrera eta itzulera bideak saihesten baititu. Behatu bi interfazeak bezero batek etxeko zerbitzu bat lortu nahi duen bitartean.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Irakurri bi harrapaketak elkarrekin. br0-n agertzen diren eta inoiz tun0-n agertzen ez diren eskaerek Pi birbidaltzen ari ez dela edo bideak beste norabait seinalatzen duela esan nahi dute. tun0-n erantzunik gabeko eskaerek etxeko aldeak itzulera biderik ez duela edo zerbitzariak paketea iragazi duela esan nahi dute. tun0-n agertzen diren eta inoiz br0-n berriro agertzen ez diren erantzunek iragazki arau alderantzizkoa falta dela esan nahi dute, tunela perfektua dirudienean eta bezeroak oraindik ezer ikusten ez duenean.

Gero hautsi bidea nahita. Jaitsi modem konexioa eta igo berriro eta exekutatu berriro bide eta harrapaketa egiaztapenak; tunelak irauten duen baina berriro konektatzean desagertzen den bide bat konexio profilean dagokio, ez behin-behineko komando batean. Egiaztatu tunelaren garraioak underlay bidez irteten jarraitzen duela eta ez bere buruaren bidez, peer-era host biderik gabe bultzatutako bide lehenetsi bat onartzen denean sortzen den begizta klasikoa.

Onartu diseinua hotspot bezero batek etxeko izen bat ebatz dezakeenean, TCP zerbitzu bat ireki eta saio bat bizirik mantendu modem berriz konexio batean zehar soilik. Aplikazio batek etxeko segmentuan Ethernet mailako aurkikuntza benetan behar badu, aukeratu onartutako Layer 2 diseinu bat, zubi lokala zubituta dagoela deskribatu eta difusioa agertu zain egon beharrean.