Klientët e hotspot-it në një Pi nuk arrijnë LAN-in e shtëpisë përmes një VPN TUN

Klientët lokalë Wi-Fi dhe Ethernet lidhen me hotspot-in e Pi-t, marrin një adresë nga diapazoni i tij DHCP dhe ngarkojnë faqe interneti pa ankesa. Të njëjtët klientë më pas skadojnë kur hapin një ndarje skedarësh ose një ndërfaqe web në LAN-in e shtëpisë, ndërsa vetë Pi arrin atë LAN përmes tunelit. Asgjë në shtresën pa tela nuk është thyer. Ajo që mungon është një kontratë e rrugëtuar: prefiksi i hotspot-it duhet të bartet në ndërfaqen TUN, dhe diçka në anën e shtëpisë duhet të dijë si t'i dërgojë përgjigjet atje. Të dyja gjysmat duhet të ekzistojnë para se një paketë të mund të përfundojë udhëtimin vajtje-ardhje.

Tre lidhje me tre detyra të ndryshme

Një urë Ethernet Linux përcjell kornizat sipas adresës MAC të destinacionit. OpenVPN në modalitetin TUN transporton paketa IP dhe nuk ka fare shtresë MAC, prandaj shtimi i një ure lokale nuk e regjistron kurrë tunelin si portë. dokumentacioni i kernelit për TUN/TAP shpjegon atë ndarje: një pajisje TAP duket si ndërfaqe Ethernet, një pajisje TUN jo. Një projekt që urëzon dy porta lokale dhe më pas rrugëton është router, çfarëdo që thonë emrat e ndërfaqeve.

Ai dallim vendos pronësinë. Nënrrjeti i klientëve, gateway-i i tyre i paracaktuar dhe autoriteti DHCP për atë diapazon i përkasin planit lokal të Pi-t. Transmetimet DHCP të shtëpisë nuk kalojnë një tunel të rrugëtuar, dhe asnjë rregullim ure nuk e ndryshon atë; drejtimi i klientëve nga një server DHCP shtëpie është një projekt relay i veçantë dhe i qëllimshëm me mënyrat e veta të dështimit.

Mbaje modemin edhe jashtë urës së klientëve. Një lidhje PPP nuk është pajisje Ethernet me etiketë tjetër, dhe logjika e dokumentuar e rrugës së paracaktuar e pppd ekzekutohet pas negociatës IPCP dhe e tërheq rrugën e saj kur ajo lidhje bie. Kopjimi i një modeli DHCP dhe riemërtimi i çdo usb0 në ppp0 nuk provon asgjë për gateway, metrikë ose cikël jetësor.

Zgjidh prefikset përpara se të redaktosh çfarëdo konfigurimi

Prefikset e mbivendosura humbin më shumë mbrëmje sesa rregullat e firewall-it, sepse mbivendosja e dërgon kërkimin e rrugës në ndërfaqen e gabuar edhe kur tuneli është i shëndetshëm. Filloni duke listuar atë që ekziston tashmë në Pi, pastaj lexoni rezultatin si katër pellgje të veçanta.

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

Pellgu i parë është adresa underlay që operatori i dha modemit; duhet të mbetet jashtë çdo plani të drejtuar nga klientët. I dyti është nënrrjeti i tunelit që zgjodhi serveri, shpesh një /24 privat i tij. I treti është ura e hotspot-it, dhe i katërti është prefiksi i shtëpisë që dëshironi të arrini. Në këtë ecje hotspot-i merr 172.28.90.0/24 me urën në 172.28.90.1, dhe LAN-i i shërbimeve të shtëpisë mban 192.168.77.0/24, çka shmang parazgjedhjet 192.168.1.0/24 dhe 10.0.0.0/24 që vijnë me routerat e konsumatorit dhe intervalin e operatorit 100.64.0.0/10.

Shpallni adresën e urës si gateway në diapazonin DHCP të hotspot-it dhe asgjë tjetër. Kurrë mos u jepni klientëve të hotspot-it një adresë shtëpie si gateway; ata nuk kanë rrugë në shtresën e lidhjes drejt atij segmenti.

Rrugëto çdo drejtim në anën që e zotëron

Pi-t i duhet një rrugë për prefiksin e shtëpisë përmes tunelit. Serverat në modalitetin server zakonisht e shtyjnë atë rrugë, prandaj së pari konfirmoni që përcjellja është e aktivizuar dhe që kernel-i zgjidh një adresë shtëpie nga tun0.

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

Nëse ip route get ende raporton ndërfaqen underlay, ndaloni atje; asgjë më tej në rrugë nuk mund të rregullojë një kërkim të gabuar.

Pajisjet e shtëpisë nuk kanë rrugë drejt 172.28.90.0/24, prandaj përgjigjet e tyre ndjekin gateway-in e paracaktuar dhe vdesin në router. Ekzistojnë dy riparime të mbështetura. Ose shtoni një rrugë statike në routerin e shtëpisë që drejton prefiksin e hotspot-it në adresën LAN të serverit VPN, ose, kur serveri është vetë gateway-i, regjistroni prefiksin e klientit në tabelën e rrugëtimit të vetë serverit. Në modalitetin shumë-klientësh të OpenVPN, drejtoria specifike e klientit mbart atë asociim: një skedar i emërtuar sipas emrit të përbashkët të certifikatës së klientit, që përmban iroute 172.28.90.0 255.255.255.0 plus rreshtin përkatës route që e instalon në kernelin e serverit. Një rrugë kerneli e hamendësuar në server nuk është e njëjta deklaratë si t'i thuash serverit cili klient zotëron prefiksin.

Mos e zhvendos shërbimin DHCP të rrjetit të shtëpisë në serverin VPN që kjo të funksionojë. Zëvendësimi i gateway-it të paracaktuar për një shtëpi të tërë është një ndryshim shumë më i madh sesa shtimi i një rrugë kthimi private, dhe tërheq DNS, rezervimet e adresave dhe çdo pajisje që injoron qiranë e re në dështim.

Hap përcjelljen pa hamendësuar firewall-in

Përcjellja e aktivizuar nuk do të thotë që paketa lejohet të kalojë. Trafiku nga ura në tunel godet ende rregullat e filtrimit, dhe një politikë e paracaktuar përcjelljeje drop i hedh tutje trafikun e hotspot-it ndërsa trafiku i vetë Pi-t vazhdon të punojë, çka prodhon saktësisht simptomën e ndarë më sipër.

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

Kërko një rregull pranimi nga br0 në tun0 dhe drejtimin përkatës të përgjigjes, dhe një rregull postrouting që mund të rishkruajë burimin. Nëse politika e zinxhirit është drop dhe asnjë rregull nuk përputhet, shtoni pranimet e ngushta dhe riprovoni në vend që ta ktheni politikën në accept.

Përkthimi është zgjedhje politike, jo kërkesë. NAT-i i burimit drejt LAN-it të shtëpisë e bën çdo klient hotspot të duket si adresa e tunelit të Pi-t, çka humb atribuimin për klient në regjistrat e shtëpisë dhe thyen shërbimet që presin burimin origjinal. Rrugëtimi pa NAT i mban adresat e klientëve të dukshme por varet nga rruga e kthimit më sipër. Zgjidh një dhe trajto DNS dhe IPv6 në të njëjtën mënyrë, sepse një rrugë IPv4 që punon pranë një rruge IPv6 të thyer lexohet ende si gjysmë e thyer në shfletues.

Verifiko udhëtimin vajtje-ardhje, pastaj thyeje qëllimisht

Testo nga një klient hotspot, kurrë nga Pi, sepse trafiku i vetë Pi-t anashkalon si rrugën përpara ashtu edhe atë të kthimit. Vëzhgo të dyja ndërfaqet ndërsa një klient përpiqet të arrijë një shërbim shtëpie.

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

Lexo të dyja regjistrimet bashkë. Kërkesat në br0 që nuk shfaqen kurrë në tun0 do të thotë që Pi nuk përcjell ose rruga tregon diku tjetër. Kërkesat në tun0 pa përgjigje do të thotë që ana e shtëpisë nuk ka rrugë kthimi ose serveri e filtroi paketën. Përgjigjet në tun0 që nuk rishfaqen kurrë në br0 do të thotë që mungon rregulli i filtrimit të kundërt, ku tuneli duket i përsosur dhe klienti ende nuk sheh asgjë.

Pastaj thyeje rrugën qëllimisht. Ulni lidhjen e modemit dhe ngrijeni përsëri dhe riekzekutoni kontrollet e rrugës dhe të regjistrimit; një rrugë që i mbijeton tunelit por zhduket në rilidhje i përket profilit të lidhjes, jo një komande të vetme. Konfirmo që transporti i tunelit ende del përmes underlay dhe jo përmes vetvetes, laku klasik kur një rrugë e paracaktuar e shtyrë pranohet pa një rrugë hosti drejt peer-it.

Prano projektin vetëm kur një klient hotspot mund të zgjidhë një emër shtëpie, të hapë një shërbim TCP dhe të mbajë një sesion gjallë përgjatë një rilidhjeje modemi. Nëse një aplikacion kërkon vërtet zbulim në nivel Ethernet në segmentin e shtëpisë, zgjidh një projekt Layer 2 të mbështetur në vend që ta përshkruash urën lokale si të urëzuar dhe të presësh transmetimin.