WireGuard punon vetëm pasi serveri dërgon: njohja e pikës fundore

Tuneli duket se punon vetëm pasi serveri dërgon diçka së pari. Filloni nga klienti dhe asgjë nuk ndodh, prisni disa sekonda, provoni përsëri dhe funksionon. Diagnoza e zakonshme është një NAT i prishur, dhe diagnoza e zakonshme është e gabuar. Ajo që ndryshoi është se njëra palë mësoi ku banon tjetra.

Njohja e pikës fundore, jo arritshmëria

Një palë e WireGuard nuk do të fillojë një shtrëngim duarsh derisa të dijë ku ta dërgojë. Konfigurimi e jep atë si pikë fundore të adresës dhe portit, dhe gjendja në punë ndjek pikën fundore që beson aktualisht.

wg show printon të dy anët e asaj pamjeje, dhe një palë pa pikë fundore në dalje nuk mund të fillojë asgjë, sado të sakta qofshin çelësi publik dhe prefikset e lejuara. Krahasoni pamjen e klientit me atë të serverit përpara se të ndryshoni çdo rregull, sepse të dy shpesh nuk bien dakord se kush di çfarë.

Si një palë mëson një pikë fundore

WireGuard është qëllimisht i qetë. Kur një paketë e vërtetuar saktë mbërrin nga një adresë që pala nuk e priste, implementimi përditëson pikën fundore të asaj pale në burimin e ri, dhe kështu funksionon roaming në një laptop që ndryshon rrjete. Ajo sjellje shpjegon varësinë nga drejtimi: nëse serveri dërgon i pari dhe paketa e tij arrin klientin, klienti mëson adresën aktuale të serverit dhe mund të përgjigjet. Deri atëherë nuk ka ku të dërgojë. Mekanizmi është roaming i vërtetuar dhe jo një shkurtore besimi në përdorimin e parë, sepse paketa duhej të ishte e vlefshme përpara se pika fundore të lëvizte.

Dokumentacioni i mjeteve për wg përshkruan atë përditësim, dhe ia vlen të lexohet një herë nëse do të projektoni rreth tij.

Përkthimi me gjendje shton drejtimin e vet

Aty ku UDP kalon nëpër një portë që përkthen, porta krijon gjendje për paketën e parë që sheh. RFC 4787 përshkruan atë sjellje dhe afatet që përfundimisht heqin hartën. Një hartë e papunë skadon, dhe një paketë hyrëse nga ana e largët hidhet atëherë nga porta përpara se të arrijë te hosti. Një tunel që punonte gjithë mëngjesin ndalon së përgjigjuri pasdite pikërisht për këtë arsye.

Ky është mekanizmi i dytë dhe i pavarur që prodhon të njëjtin simptomë drejtimore. Si njohja e pikës fundore ashtu edhe gjendja e përkthimit duhet të jenë të sakta, dhe rregullimi i njërës nuk rregullon tjetrën.

Konfiguroni drejtimin që vërtet dëshironi

Për një klient që duhet të fillojë lidhjen, vendosni pikën fundore të serverit në seksionin e palëve të klientit dhe lëreni atje. Të mbështetesh në faktin që serveri dërgon i pari do të thotë të mbështetesh në një rastësi të rendit të trafikut që do të ndryshojë në një rrjet të qetë. Konfigurimi duhet të deklarojë drejtimin e synuar, jo ta zbulojë atë.

Për një palë pas një përkthimi që duhet të mbetet e arritshme, aktivizoni një keepalive të vazhdueshëm në atë anë. Një keepalive çdo 25 sekonda është vlera fillestare e zakonshme, dhe qëllimi i tij është të mbajë hartën të hapur, jo të testojë tunelin. Zgjidhni një anë që ta mbajë, sepse aktivizimi në të dyja anët dyfishon trafikun dhe zhurmën e regjistrit pa përmirësuar rezultatin.

Krahasoni gjendjen përpara dhe pas shkaktarit

Kapni dy pamjet në momentin kur dështon, dhe më pas përsëri pasi serveri dërgon. Komanda e parë tregon pikat fundore dhe moshën e shtrëngimit të duarsh. E dyta tregon nëse ekziston një zë përkthimi për portin. Kapja tregon cili drejtim e kaloi vërtet telin, dhe kontrolli i rrugës konfirmon që klienti nuk po e dërgon atë trafik diku tjetër krejt.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Shënoni kolonën e pikës fundore dhe zërin e përkthimit bashkë. Një palë pa pikë fundore dhe një portë pa hartë janë dy defekte të ndryshme. Vetëm njëri prej tyre rregullohet nga një keepalive.