Handshake-u i WireGuard funksionon, por nuk ka internet: ndiq paketën

Tuneli është aktiv, wg show raporton një handshake të fundit, mund të pingosh adresën e tunelit të serverit, dhe asgjë përtej saj nuk përgjigjet. Instinkti i parë është të rigjenerosh çelësat ose të ndash përsëri konfigurimin. Kjo ndryshon pikërisht pjesën e rrugës që është provuar tashmë se funksionon.

Një handshake i përfunduar thotë se dy palët bien dakord për çelësat, se UDP arrin pikën fundore dhe se rrugëtimi kriptografik e pranon paketën. Nuk thotë asgjë për atë nëse paketa mund të largohet nga serveri pas kësaj.

Prandaj ndiq një paketë në vend të hamendësimit. Ka katër vende ku ajo mund të vdesë, dhe secili lë një gjurmë tjetër.

Çfarë vërteton në të vërtetë handshake-u

WireGuard është një protokoll UDP që vendos një sesion me një handshake Noise dhe më pas kripton paketat për një palë. Kur wg show shfaq një handshake disa sekonda të vjetër dhe një numërues transferimi në rritje, pika fundore, çelësat dhe çelësi publik i palës janë të gjithë të saktë.

Ajo që nuk vërteton është se klienti yt dërgon trafik drejt internetit në ndërfaqe, se serveri është i gatshëm ta përcjellë ose se një përgjigje mund të gjejë rrugën e kthimit. Këto janë vendime të rrugëtimit të kernelit dhe të firewall-it, dhe merren jashtë tunelit.

Kjo është arsyeja pse ping-u drejt adresës së tunelit të serverit është një test kaq mashtrues. Ajo paketë është drejtuar vetë serverit, pra përfundon lokalisht. Nuk ka kurrë nevojë për përcjellje, kurrë për përkthim dhe kurrë për një rrugë kthimi nga interneti.

AllowedIPs është një vendim rrugëtimi

Në klient, AllowedIPs bën dy punë. Është tabela e rrugëtimit me çelës kriptografik që vendos cilat adresa destinacioni shkojnë në tunelin e kësaj pale, dhe është lista e adresave burimore që pala do të pranojë prej teje. Nëse konfigurimi i klientit liston vetëm 10.8.0.0/24, destinacionet publike nuk hyjnë kurrë në ndërfaqe dhe rruga normale e paracaktuar i çon jashtë tunelit. Atëherë tuneli funksionon përsosurisht dhe nuk bën asgjë nga ajo që doje.

Shiko çfarë instaloi vërtet klienti, jo çfarë thotë skedari i konfigurimit:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Komanda e dytë është vendimtarja. Nëse përgjigja përmend ndërfaqen tënde fizike dhe gateway-in e zakonshëm, paketa nuk po tunelohet dhe asnjë ndryshim në anën e serverit nuk do ta rregullojë. Shto 0.0.0.0/0 për IPv4 dhe ::/0 për IPv6 veçmas; një rregull që kap gjithçka për një familje e lë tjetrën në rrugën e saj origjinale, dhe kjo është një shkak i zakonshëm i një tuneli IPv4 që funksionon dhe i një kërkese IPv6 të bllokuar.

Ku vdes paketa në gateway

Nëse rruga është e saktë dhe paketa ende nuk shkon askund, ajo arrin në server dhe ndalon atje. Katër kontrolle mbulojnë shumicën e gateway-ve.

Përcjellja. sysctl net.ipv4.ip_forward që kthen 0 është përgjigjja klasike, dhe shumë shpërndarje janë ende 0 si parazgjedhje. Duhet të jetë 1, dhe të vendoset përgjithmonë në një skedar sysctl, jo me një komandë që zhduket në rinisje. Përcjellja e IPv6 është një çelës i veçantë.

Politika e filtrimit. Një zinxhir FORWARD me politikë parazgjedhëse hedhjeje do të hedhë trafikun e tunelit ndërsa lejon trafikun drejt vetë hostit, që përputhet saktësisht me simptomën. Lexo grupin e rregullave të gjallë, jo një skedar të ruajtur: nft list ruleset ose iptables -S.

Përkthim ose rrugëtim. Klientët me adresa private tuneli kanë nevojë ose për NAT burimi në ndërfaqen e daljes së serverit, ose për një prefiks të rrugëtuar që rrjeti i sipërm di ta kthejë. Zgjedhja mes tyre ndjek planin e adresave. Shtimi i MASQUERADE në një rrjet që tashmë e rrugëton prefiksin tënd mbrapsht është i padëmshëm por i kotë, dhe heqja e tij atje ku nuk ekziston rrugë i lë përgjigjet të drejtuara drejt një diapazoni privat të parrugëtueshëm.

Rruga e kthimit. Në modelet e rrugëtuara, router-i i sipërm ka nevojë për një rrugë që tregon drejt serverit tënd. Edhe rrjeti i ofruesit mund ta bllokojë: disa cloud aktivizojnë një kontroll burimi dhe destinacioni në instancë, që i hedh në heshtje paketat burimi i të cilave nuk është adresa e vetë instancës, derisa ai kontroll të çaktivizohet.

DNS dështon ndryshe nga rrugëtimi

Një paketë drejt një adrese të njohur dhe një kërkim emri janë dy dështime të veçanta, dhe mesazhet e gabimit mashtrojnë në drejtime të kundërta. Nëse ping 1.1.1.1 funksionon dhe shfletuesi nuk ngarkon asgjë, rruga është në rregull dhe zgjidhja e emrave nuk është. Nëse ping-u vetë dështon, DNS është i parëndësishëm dhe je kthyer në seksionin e mëparshëm.

wg-quick mund të vendosë një resolver nga rreshti DNS = në konfigurim, dhe systemd-resolved ka sjelljen e vet për çdo lidhje. Një VPN që mbishkruan resolver-in me një adresë të arritshme vetëm brenda tunelit do të dështojë në çdo kërkim në momentin kur tuneli bie, që duket sikur tuneli po prish internetin.

Një rend që prodhon provë

Ekzekuto më parë kontrollin në anën e klientit, sepse është një komandë e vetme dhe eliminon gjysmën e mundësive. Pastaj konfirmo nëse serveri është menduar si dalje në internet; një gateway i ndërtuar për akses privat nuk është i prishur kur destinacionet publike dështojnë.

Në server, vëzhgo ndërfaqen ndërsa dërgon një ping nga klienti: tcpdump -ni wg0 icmp duhet të tregojë kërkesën, dhe tcpdump -ni eth0 icmp duhet të tregojë se ajo po del, e përkthyer ose jo. Nëse shfaqet në të parën dhe kurrë në të dytën, ndalimi është lokal në server. Nëse del dhe nuk kthehet asnjë përgjigje, problemi është më lart, dhe ajo është një bisedë tjetër.

Më në fund, bëj që rregullimi t'i mbijetojë një rinisjeje. Përcjellja i takon një skedari sysctl, rregullat e firewall-it i takojnë shërbimit që i ngarkon, dhe rrugët e klientit i takojnë konfigurimit që ngre ndërfaqen, jo një shell-i që do ta harrosh. Rilidhu, përsërit të njëjtat dy teste dhe konfirmo që numëruesit lëvizin.