hostapd dhe OpenVPN në një Pi të vetëm: e kujt është rruga e paracaktuar?

Telefonat lidhen me pikën e aksesit, marrin një adresë dhe më pas nuk arrijnë asgjë sapo tuneli ngrihet. hostapd zakonisht është i shëndetshëm në atë gjendje, dhe OpenVPN gjithashtu; ajo që prishet është rruga e paracaktuar, e cila ose nuk ka ekzistuar kurrë në urë ose u zëvendësua nga tuneli pa lënë një shteg drejt vetë serverit VPN. Ky udhëzues e kthen atë rrugë në vendin e vet dhe e vërteton rezultatin nga një klient dhe jo nga Pi. Çdo hap është i kthyeshëm, dhe asgjë këtu nuk ndryshon konfigurimin e tunelit derisa të dini çfarë trafiku dëshironi brenda tij.

Inventarizoni ndërfaqet përpara se të redaktoni ndonjë gjë

Paraqitja e njohur e vendos radion pa tela dhe portin me tela brenda br0, nis hostapd kundër urës dhe shpërndan qira nga dnsmasq, ndërsa një klient OpenVPN krijon tun0. Atëherë tre kërkesa të ndara duken si një: klientët e pikës së aksesit kanë nevojë për Pi si portën e tyre, Pi ka nevojë për një rrugë drejt internetit për të arritur serverin e vet, dhe ura ka nevojë për një adresë porte që ata klientë mund të përdorin.

Lexoni gjendjen aktuale përpara se ta ndryshoni, sepse këto katër komanda ndajnë një problem ndërfaqeje nga një problem rrugëtimi.

ip -br addr
ip route show
ip link show master br0
bridge link show

Nëse br0 mban një adresë por asnjë rrugë të paracaktuar, klientët arrijnë Pi dhe asgjë përtej tij. Nëse rruga e paracaktuar tregon drejt tun0 ndërsa tuneli është poshtë, Pi nuk ka fare shteg funksional, dhe simptoma e klientit duket saktësisht e njëjtë. Të dyja rastet duken identike nga një telefon, prandaj tabela e rrugëve duhet lexuar drejtpërdrejt.

Jepini urës një rrugë të paracaktuar që i përket asaj

Raspberry Pi OS shpesh e lë urën pa rrugë të paracaktuar kur ura lindi pasi u shkrua skedari i ndërfaqes. Blloku i përket /etc/dhcpcd.conf dhe duhet të përmendë ruterin e mësipërm dhe jo Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

Në atë shembull 192.168.50.1 është ruteri ekzistues dhe 192.168.50.2 është adresa e urës së Pi në të njëjtën nënrrjetë, prandaj zëvendësojeni me planin tuaj në vend që të kopjoni numrat. Anëtarët e urës gjithashtu nuk duhet të kërkojnë ruter, përndryshe Pi mbetet me rrugë të paracaktuara konkurruese fituesi i të cilave varet nga metrika dhe koha dhe jo nga qëllimi.

Pas systemctl restart dhcpcd ip route show default duhet të listojë br0 një herë dhe asnjë dublikatë nga porti me tela. Konfirmoni kërkimin dhe jo tabelën, sepse një zë i vjetër mund të rrijë pranë një fituesi: ip -4 route get 203.0.113.10 duhet të përmendë br0. Ajo adresë vjen nga diapazoni i dokumentacionit TEST-NET-3, prandaj nuk mund të përplaset me një server të vërtetë ndërsa lexoni këtë.

Ndaleni tunelin të mos rrëmbejë shtegun drejt serverit të vet

Një klient OpenVPN që pranon redirect-gateway e merr rrugën e paracaktuar dhe e drejton atë brenda tunelit. Kjo është e saktë kur çdo klient i pikës së aksesit duhet të përdorë VPN-në, dhe e gabuar kur duhet vetëm disa destinacione. Në çdo rast, lidhja e vetë Pi me serverin nuk duhet të udhëtojë brenda tunelit që ai ende po ndërton. OpenVPN shton një rrugë pritësi drejt të largëtit përmes portës origjinale kur e ridrejton të paracaktuarën, dhe pikërisht ky është sjellja që e mban transportin gjallë; nëse ajo rrugë mungon, tuneli shembet sapo vendoset.

Një krahasim i shpejtë i atij shtegu transporti para dhe pas lidhjes ia vlen ato dhjetë sekonda. ip -4 route get 203.0.113.10 duhet të përmendë pajisjen e shtresës së poshtme në të dyja gjendjet, ndryshon vetëm metrika. Nëse përmend tun0 pasi tuneli ngrihet, rruga e pritësit nuk u instalua kurrë dhe rilidhja tjetër do të dështojë.

Kur vetëm parashtesat e zgjedhura duhet të kalojnë tunelin, përdorni route-nopull dhe shtoni rrugët e dëshiruara me dorë, ose shtyni një grup më të ngushtë nga serveri. Ura mban rrugën e paracaktuar në atë dizajn, dhe DNS bëhet vendimi pasardhës: përcjellja e dnsmasq drejt një zgjidhësi shtëpiak ka kuptim vetëm për emrat që jetojnë vërtet atje.

Vendosni për përcjelljen dhe NAT

Tuneli i plotë kërkon përcjellje të aktivizuar në Pi dhe një portë në anën tjetër të gatshme të rrugëtojë nënrrjetën e pikës së aksesit. Kontrolloni përcjelljen para çdo gjëje tjetër, sepse një zero e bën çdo ndryshim rruge të parëndësishëm.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Rregulli NAT është shkurtesa që funksionon kur serveri nuk do të pranojë parashtesën e pikës së aksesit, me koston që çdo klient të shfaqet si adresa e tunelit të Pi në regjistrat e anës tjetër. Rrugëtimi i parashtesës pa NAT i mban adresat të dukshme dhe varet nga një rrugë kthimi për 192.168.50.0/24 në anën e shtëpisë.

Shkruajeni zgjedhjen pranë rregullave të firewall-it, sepse një rregull NAT i padukshëm në dizajn bëhet i pashpjegueshëm gjashtë muaj më vonë. Mbani IPv6 në të njëjtin vendim; një shteg IPv4 që funksionon pranë një shtegu IPv6 të prishur lexohet ende si gjysmë i prishur në një shfletues.

Verifikoni nga një klient, pastaj kthehuni pastër

Provoni në këtë rend nga një telefon ose laptop në pikën e aksesit: një qira nga dnsmasq, një ping drejt adresës së urës, pastaj një destinacion në anën tjetër të tunelit. Çdo hap izolon një shtresë në vend që të prodhojë një dështim të vetëm të padobishëm.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Pastaj konfirmoni që Pi ka ende daljen e vet: ip route get 203.0.113.10 duhet të përmendë pajisjen e shtresës së poshtme, dhe ping -c 3 -I br0 203.0.113.10 duhet të përgjigjet nëse serveri lejon ICMP. Nëse dy hapat e parë të klientit kalojnë dhe i treti dështon, defekti është në përcjellje ose NAT. Nëse hapi i dytë dështon, ura ose DHCP janë ende të paplota.

Kthimi pas është një redaktim skedari dhe dy komanda: hiqni bllokun, rinisni dhcpcd dhe zëvendësoni rrugën e paracaktuar shprehimisht me ip route replace default via 192.168.50.1 dev br0. Bëjeni këtë përpara se të mbyllet dritarja e mirëmbajtjes dhe jo pas, sepse një Pi që ka humbur rrugën e paracaktuar është i paarritshëm nga rrjeti që do të përdornit për ta riparuar.