Të lidhur me OpenVPN por asgjë nuk ngarkohet: një ecje nga klienti jashtë

Dritarja e klientit thotë Connected, adresa e tunelit është aty, dhe shfletuesi vazhdon të rrotullohet. Ky kombinim është normal, sepse një shtrëngim duarsh i suksesshëm dëshmon vetëm se tuneli u ndërtua; ai nuk thotë asgjë nëse serveri do t'i përcjellë paketat tuaja, do të rishkruajë burimin e tyre apo do t'u përgjigjet pyetjeve tuaja DNS. Gabimi që bëjnë shumica është të hapin së pari konfigurimin e serverit. Në vend të kësaj punoni nga klienti jashtë, sepse çdo hap më poshtë ju thotë nëse i radhës ia vlen të kontrollohet.

Filloni te klienti dhe ecni jashtë

Bëni tre prova në këtë rend dhe shkruani ku dështon e para. Bëni ping adresës së tunelit të serverit, çka dëshmon se vetë tuneli mbart trafik. Bëni ping një adrese publike sipas numrit, çka dëshmon përcjelljen dhe përkthimin pa përfshirë zgjidhjen e emrave. Pastaj provoni të zgjidhni një emër hosti, që është prova e vetme që përdor DNS. Çdo rezultat heq një shtresë të tërë nga dyshimi.

Mos hidhuni te prova e tretë sepse shfletuesi duket më i shpejtë. Një ngarkim faqeje i dështuar mbulon të tre shtresat njëherësh, dhe pikërisht nga aty njerëzit fillojnë dhe pastaj rindërtojnë një tunel që funksiononte. Faqja që dështon nuk ju thotë cila nga të tre u thye.

Dy kapje tregojnë ku ndalen paketat

Ndërsa një ping drejt një adrese publike ecën nga klienti, bëni një kapje në ndërfaqen e tunelit dhe një në lidhjen sipërme që supozohet se arrin internetin. Ekzekutoni të dyja njëkohësisht që vulat kohore të përputhen.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Nëse kërkesat shfaqen në tunel dhe kurrë në lidhjen sipërme, serveri i hodhi ato midis tunelit dhe kabllos, dhe shkaku është përcjellja ose politika e mureve të zjarrit për përcjellje, jo NAT. Nëse shfaqen në të dyja, serveri bëri pjesën e vet dhe përgjigjja mungon më tej, çka të çon te përkthimi, një filtër sipër ose një kufizim nga ofruesi.

Merrni emrin e lidhjes sipërme nga tabela e rrugëtimit, jo nga një tutorial. Imazhet e resë dhe përshtatësit e riemërtuar rrallë përputhen me ndërfaqen shembull të një udhëzuesi, dhe një kapje e bërë në pajisjen e gabuar duket saktësisht si një server që nuk përcjell:

ip -4 route get 9.9.9.9

Fusha dev në atë dalje është emri që rregulli NAT do t'i duhet më vonë, ndaj mbajeni.

Përcjellja është një çelës në kernel dhe një politikë muri zjarri

Kerneli duhet të pajtohet të përcjellë që në fillim. Lexoni vlerën aktuale, pastaj bëjeni cilësimin të përhershëm në vend që ta shkruani vetëm në kernelin që po punon:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Përcjellja është vetëm gjysma. Në një host me UFW politika e përcjelljes vendoset në /etc/default/ufw dhe duhet të jetë ACCEPT përpara se një ringarkim të hyjë në fuqi. Një hedhje e parazgjedhur në rrugën e përcjelljes e lë shtrëngimin e duarve plotësisht të shëndoshë duke hedhur në heshtje çdo paketë që përpiqet të dalë përmes tunelit, dhe ky është saktësisht simptomi me të cilin filluat.

Hostet që administrojnë nftables drejtpërdrejt e kanë të njëjtën pyetje në një sintaksë tjetër. Shikoni numëruesit në zinxhirin e përcjelljes ndërsa ecën një provë nga klienti, sepse zinxhiri që konsultohet dhe zinxhiri që hedh duken njësoj në një skedar konfigurimi.

Emërtoni ndërfaqen reale të daljes në rregullin NAT

Përkthimi i burimit i takon ndërfaqes që vërtet largohet nga hosti, bashkë me grupin që serveri shpërndan. Të dyja gjysmat e atij rregulli duhet të përshkruajnë realitetin, dhe asnjëra nuk është opsionale.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Dështimi klasik është një rregull i kopjuar nga një udhëzues që thotë -o eth0 në një makinë përshtatësi i së cilës quhet ndryshe. Rregulli instalohet pa paralajmërim, nuk përputhet me asgjë, dhe klienti vazhdon pa internet. Grupi është gjysma tjetër e të njëjtit gabim: nëse serveri shpërndan 10.44.0.0/24 dhe rregulli mbulon 10.8.0.0/24, asgjë nuk do të përputhet kurrë.

Shikoni numëruesit në vend që t'i besoni tekstit të rregullit. Lista raporton paketa për rregull, dhe një rregull që nuk përputhet kurrë mbetet në zero sado i saktë që duket. Jepini një minutë trafik real të klientit përpara se të lexoni gjë në atë numër:

iptables -t nat -L POSTROUTING -v -n

Një numërim paketash zero pas një prove reale të klientit do të thotë që përputhja është e gabuar, jo se tuneli është prishur. Sapo të përputhet, ruani grupin e rregullave që t'i mbijetojë një rindezjeje; një rregullim që jeton vetëm në historikun e shell-it tuaj zhduket në rindezjen e parë.

Nëse serveri është gjithashtu një instancë NAT në re, edhe platforma ka fjalë. Një instancë që përkthen adresa zakonisht kërkon kontrollin e burimit dhe destinacionit të çaktivizuar aty ku ofruesi e ofron atë cilësim, dhe vetë porta VPN duhet të jetë e arritshme nga jashtë.

DNS është dështimi i dytë pas të parit

Ping sipas adresës që funksionon ndërsa emrat dështojnë është problem i zgjidhësit, dhe ka shkakun e vet. Një klient që mban zgjidhësin e vet lokal i dërgon ato pyetje në një tunel të plotë dhe pret një përgjigje që nuk vjen kurrë, sepse zgjidhësi lokal tani është në anën e gabuar të rrugës.

Shtyni një zgjidhës nga serveri që klienti të dijë ku të pyesë. Dy zëra i japin klientit një alternativë nëse i pari nuk arrihet, dhe të dy duhet të jenë zgjidhës që tuneli vërtet i lejon.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Klientët Windows pastaj mund të kthehen gjithsesi te zgjidhësi lokal, dhe pikërisht këtë block-outside-dns ekziston për të parandaluar, me koston e humbjes së emrave që vetëm rrjeti lokal mund t'i zgjidhë. Klientët Linux me systemd-resolved shpesh e injorojnë një zgjidhës të shtyrë nëse një skript nuk e instalon, ndaj kontrolloni resolvectl status për pajisjen e tunelit përpara se të përfundoni që shtytja u injorua.

Përfundoni ecjen ashtu siç e përjeton një përdorues. Ngarkoni një faqe reale nga klienti, konfirmoni adresën nga e cila del, rindizni serverin, rilidhuni dhe përsëritni tre provat. Vetëm ai raund i dytë dëshmon se rregullat e ruajtura, politika e mureve të zjarrit dhe zgjidhësi i shtyrë i mbijetuan të gjithë së bashku.