Klientët VPN lidhen por nuk kanë internet: tre pjesë që mungojnë

Klienti merr një adresë, serveri përgjigjet ndaj ping, dhe megjithatë çdo faqe skadon. Shumica e njerëzve fillojnë ta modifikojnë profilin e klientit në këtë pikë, gjë që zakonisht është mund i humbur: sapo tuneli është lart, serveri duhet të sillet si një router. Tre kushte duhet të plotësohen njëkohësisht përpara se një paketë të dalë dhe të kthehet një përgjigje, dhe simptomi është i njëjtë cilado qoftë ajo që mungon.

Pse një tunel funksional ende nuk ka rrugëdalje

Kerneli duhet të përcjellë paketa midis ndërfaqeve, gjë që është e çaktivizuar si parazgjedhje në shumicën e shpërndarjeve Linux. Trafiku duhet të përkthehet në një adresë të cilës bota e jashtme mund t'i përgjigjet, përveç nëse çdo router në rrjedhën e sipërme e njeh tashmë rrugën e kthimit drejt nënrrjetit të tunelit. Rruga e përcjelljes së firewall-it duhet të lejojë trafikun në të dy drejtimet, përfshirë përgjigjet.

Secili prej tyre mund të rregullohet veçmas, dhe pikërisht këtu është kurthi. Aktivizimi i përcjelljes pa një rregull përkthimi i lë paketat të dalin me një burim privat dhe pa rrugë kthimi. Shtimi i përkthimit pa një rregull përcjelljeje e lë kernelin ta hedhë paketën një hap më vonë.

Prandaj provoni tre shtresat në vend të klientit, dhe ndryshoni një nga një që rezultati të ketë kuptim.

Përcjellja është një çelës i kernelit që duhet ta bëni të përhershëm

Kontrolloni vlerën aktuale përpara se ta ndryshoni, më pas vendoseni dhe konfirmoni se ndryshimi hyri në fuqi.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Komanda e parë raporton vlerën aktuale, e dyta e vendos gjatë punës, dhe e treta vërteton se shkrimi funksionoi. Vlera gjatë punës zhduket në rinisjen tjetër, prandaj një sesion funksional mund të prishet pas mirëmbajtjes pa asnjë ndryshim konfigurimi.

Bëjeni të përhershme në një skedar nën /etc/sysctl.d/, pastaj aplikoni atë skedar në vend që të rinisni për ta zbuluar. Në FreeBSD ekuivalenti është net.inet.ip.forwarding, me gateway_enable=YES në rc.conf për qëndrueshmëri. Një pajisje që raporton përcjelljen e çaktivizuar shpjegon një klasë të tërë raportesh „paketat mbërrijnë dhe asgjë nuk kthehet”. Kontrolloni cilësimin edhe pas çdo përditësimi, sepse një kernel i rindërtuar ose një imazh pajisjeje i zëvendësuar mund ta rivendosë atë pa i thënë askujt.

Zgjidhni masquerade ose një adresë të vetme fikse përkthimi

Me një adresë të jashtme dinamike, masquerading është forma e saktë më e thjeshtë. Emërtoni nënrrjetin e tunelit si burim dhe ndërfaqen e jashtme si dalje.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Me një adresë publike statike, përkthimi i burimit pikërisht në atë adresë është më i parashikueshëm dhe më i lehtë për t'u audituar.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Forma e dytë mbart një kurth mirëmbajtjeje: një adresë e koduar fort që ndryshon më vonë e mban tunelin funksional ndërsa aksesi në internet ndalon në heshtje. Ose përdorni masquerade ose përditësoni rregullin sa herë që ofruesi ju zhvendos. Ndërfaqja ka rëndësi gjithashtu, sepse një router që ndan tunelin e vet të sipërm duhet të përkthejë përmes atij tuneli dhe jo përmes WAN-it fizik.

Tabela e filtrit është porta e tretë

Përcjellja dhe përkthimi mund të jenë të dyja të sakta ndërsa paketa vdes ende në tabelën e filtrit. ufw është një fajtor i shpeshtë: politika e tij e përcjelljes vjen si DROP, dhe pjesa tjetër e konfigurimit mund të duket plotësisht e saktë ndërsa ai cilësim i vetëm vret trafikun. Ngritja e saj është një vendim sigurie i qëllimshëm dhe jo një kuti kontrolli.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Rregulli i parë lejon trafik të ri nga tuneli drejt jashtë, dhe i dyti vetëm përgjigjet mbrapsht. Ngushtoni të dyja në nënrrjetin e tunelit dhe destinacionin e synuar, sepse një leje e përgjithshme në ndërfaqen e tunelit e kthen VPN-në në një pikë daljeje të hapur për këdo që mund të autentifikohet.

Një tunel i urëzuar kërkon një përgjigje tjetër. Adresa i përket urës, jo portës fizike, prandaj skllavërimi i ndërfaqes heq adresën që kishte më parë dhe hosti duket i paarritshëm derisa ura vetë të marrë një, gjë që dhclient br0 mund të sigurojë. Ai dështim duket si problem VPN dhe është problem i shtresës së dytë. Kontrolloni adresën e vetë urës përpara se të prekni firewall-in, sepse një ndryshim filtri nuk mund të rregullojë një host që nuk ka më adresë nga të dërgojë.

Ku të shikoni kur një faqe nuk ngarkohet kurrë

Bëni ping adresës së tunelit të serverit për të provuar se tuneli ekziston. Pastaj ekzekutoni një traceroute nga klienti në një adresë publike dhe lexoni ku ndalon: në server paketa mbërrin por nuk përcillet ose përkthehet; përtej serverit problemi është në rrjedhën e sipërme dhe jashtë duarve tuaja.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Komanda e parë provon se tuneli mbart trafik deri te vetë serveri, dhe e dyta tregon sa larg arrin një paketë drejt jashtë. Një gjurmë që përfundon në adresën e tunelit tregon përcjellje ose përkthim në server, ndërsa një gjurmë që ndalon një kërcim më vonë tregon ofruesin ose rrugën e kthimit të routerit të sipërm.

Në server, vëzhgoni ndërfaqen e jashtme ndërsa një klient ngarkon një faqe. Trafiku që del me një adresë burimi private do të thotë se mungon përkthimi, dhe mungesa e plotë e përgjigjes do të thotë se rruga e përcjelljes ose rruga e kthimit e sipërme po e hedh.

Nëse klientët në distancë duhet të arrijnë edhe hoste në LAN-in e serverit, mbani mend se LAN-i ka nevojë për një rrugë kthimi drejt nënrrjetit të tunelit. Kjo është rrugëzim dhe jo përkthim, dhe është hapi që harrohet më shpesh pasi rruga drejt internetit më në fund funksionon.