Hapi tjetër në një rrugë VPN: pse porta duhet të jetë e arritshme lokalisht

Një rrugë drejt një rrjeti VPN mbart dy adresa që ngatërrohen lehtë: prefiksi i destinacionit që pakoja përpiqet të arrijë dhe hapi tjetër që do ta lëvizë një hap më afër. Në një host LAN, ai hap tjetër duhet të jetë një ruter të cilin vërtet mund ta arrini në të njëjtën lidhje. Adresa VPN e largët nuk është një hap tjetër, sado mirë t'i përshtatet destinacionit që keni në mendje.

Ky manual mbulon rastin e zakonshëm: një laptop në 192.168.20.0/24, një portë VPN me adresë LAN 192.168.20.5 dhe një rrjet i largët 10.70.0.0/24 pas asaj porte. Të gjitha komandat më poshtë supozojnë se jeni në laptop, përveç rasteve kur thuhet ndryshe.

Dy adresa, një rrugë

Hyrja e synuar është 10.70.0.0/24 via 192.168.20.5. Prefiksi thotë ku shkon pakoja; adresa via thotë kush e çon atje. Bërthama refuzon të instalojë një rrugë, portën e së cilës nuk mund ta arrijë përmes ndërfaqes që përmendni, dhe ai refuzim është i gjithë qëllimi: një hap tjetër që ka nevojë për tunelin për të qenë i arritshëm nuk mund të jetë hapi tjetër që ndërton tunelin.

Prandaj kontrolli i parë nuk është «a punon porta», por «a është porta në këtë lidhje». Nënrrjeti i vetë laptopit, hyrja e tij ARP ose e fqinjit dhe ndërfaqja në rrugë duhet të përputhen. Një adresë që ekziston vetëm brenda 10.70.0.0/24 mund të jetë destinacioni i një rruge të dytë, por kurrë via i së parës.

Për çfarë e detyron hapi tjetër portën

Instalimi i rrugës në laptop vendos vetëm dorëzimin e parë. Më pas portës i duhet rruga e vet: përcjellja e aktivizuar, një rrugë tuneli për 10.70.0.0/24 dhe çdo politikë aksesi që përcakton kush mund ta përdorë. Në Linux kjo është net.ipv4.ip_forward=1 plus një rrugë tuneli; një muri zjarri përpara i duhet një rregull që lejon rrjedhën e përcjellë.

Drejtimi i kthimit është pjesa që njerëzit harrojnë. Ana e largët duhet të ketë një rrugë kthimi drejt 192.168.20.0/24, ose dizajni duhet ta përkthejë burimin e laptopit në diçka që ana e largët e njeh. Një ping që funksionon nga porta provon se porta arrin rrjetin e largët; nuk thotë asgjë nëse pakot e laptopit i mbijetojnë udhëtimit të kthimit.

Verifikoni kërkimin nga hosti që dërgon

Pyetni bërthamën cilin hap tjetër do të zgjidhte dhe lexoni ndërfaqen në përgjigje:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Nëse kërkimi raporton portën dhe ndërfaqen LAN, segmenti i parë është konfiguruar siç synohej. Nëse raporton pajisjen e tunelit, diçka më herët në tabelë është më specifike dhe po fiton. Nëse rruga nuk instalohet fare, bërthama po ju thotë se porta nuk është e arritshme, dhe ai mesazh është më i dobishëm se çdo kapje paketash.

Pastaj përsëritni testin nga vendi i duhur. Një kërkesë e krijuar në portë përdor adresën e burimit të vetë portës, gjë që mund të fshehë një rrugë kthimi që mungon ose një politikë që lejon vetëm burime të caktuara. Manuali i ip-route ndan destinacionin, portën dhe anashkalimin onlink, dhe anashkalimi ia vlen të kuptohet përpara se ta përdorni.

Mos përdorni onlink për të falsifikuar arritshmërinë

onlink i thotë bërthamës të kapërcejë kontrollin e arritshmërisë së një porte dhe të dërgojë gjithsesi atje. Nuk krijon një shteg, nuk zgjidh ARP për një adresë që nuk është aty dhe nuk e detyron një ruter të largët të përgjigjet në segmentin tuaj Ethernet. Është legjitim për porta që përgjigjen por nuk ndodhen në një nënrrjet të lidhur, dhe është kurth kur përdoret për të heshtur një gabim që nuk e keni shpjeguar.

Nëse rruga instalohet vetëm me onlink, pyetja tjetër është pse porta nuk është atje ku mendoni. Një VLAN e gabuar, një adresë e dytë në ndërfaqen e gabuar ose një gabim shtypi në oktetin e fundit i prodhojnë të gjitha këto, dhe secila prej tyre gjithashtu prish rrugën e kthimit sapo trafiku fillon të rrjedhë.

Tunelet pikë-për-pikë nuk janë Ethernet

Një pajisje tuneli nuk bën ARP dhe shpesh nuk ka një nënrrjet kuptimplotë fqinjësh. Rrugët e saj shpesh duken si 10.70.0.0/24 dev tun0, pa asnjë via, sepse partneri është i vetmi skaj tjetër. Kopjimi i një via në stil LAN në atë tabelë prodhon një rrugë që bërthama mund ta refuzojë ose, më keq, një që tregon një adresë të cilës partneri nuk i përgjigjet kurrë.

Mbani dy modelet të ndara në manual: një rrugë LAN ka një portë të arritshme, një rrugë tuneli ka një ndërfaqe dhe një partner. WireGuard, OpenVPN dhe IPsec ekspozojnë forma paksa të ndryshme, prandaj shkruani formën që keni përdorur vërtet në vend që të përgjithësoni nga një host.

Shtoni, konfirmoni, kthejeni mbrapsht

I gjithë ndryshimi është tre komanda dhe një kontroll, dhe duhet të shkruhet në atë rend:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Konfirmoni shtegun, konfirmoni një destinacion, pastaj mbajeni rreshtin e fshirjes gati në rast se ndryshimi e bën hostin të paarritshëm në një mënyrë që nuk e parashikuat. Nëse rruga duhet t'i mbijetojë një rindezjeje, vendoseni në konfigurimin e rrjetit të hostit dhe jo në një profil shell, dhe testoni rindezjen përpara se të mbështeteni tek ajo. Një rrugë që ekziston vetëm në shellin që e shtoi është një rrugë që do ta korrigjoni dy herë.