Një peer WireGuard i paarritshëm ndërsa tjetri funksionon: lista e kontrollit

Një peer WireGuard kalon trafikun dhe i dyti përfundon shtrëngimin e duarve por nuk arrin kurrë asgjë pas tunelit. Peer-i që funksionon ju thotë se ndërfaqja, porta UDP dhe çelësi i serverit ndoshta janë në rregull. Ai nuk thotë asgjë për AllowedIPs e peer-it të dytë, adresën e tij burimore të brendshme ose rregullat e përcjelljes ndërmjet tyre. Kaloni listën me radhë dhe ndaloni në hapin e parë, kushti i të cilit dështon.

Hapi 1: Shkruani rrugën që duhet të ndjekë paketa

Dy klientë në të njëjtin hub nuk arrijnë automatikisht te njëri-tjetri. Në një dizajn hub dhe rreze, serveri e merr paketën në wg0 dhe duhet ta përcjellë përsëri jashtë wg0 te peer-i tjetër, gjë që kërkon përcjellje IP dhe një rregull përcjelljeje. Në një dizajn të drejtpërdrejtë peer-me-peer, secila anë ka nevojë për pikën fundore të tjetrës dhe adresën e tunelit të tjetrës brenda AllowedIPs. Vendosni cilin dizajn po korrigjoni përpara se të lexoni çdo konfigurim.

Rruga e pritur ju tregon gjithashtu ku të shikoni. Nëse paketa duhet të kalojë hub-in, kërcimi që dështon është ose AllowedIPs e dërguesit, ose përcjellja në hub, ose AllowedIPs e marrësit. Nëse duhet të shkojë direkt, hub-i nuk ka rëndësi dhe fushat e pikës fundore në të dy peer-at janë ato që kanë rëndësi.

Hapi 2: Krahasoni AllowedIPs në të dyja anët, jo vetëm në njërën

WireGuard përdor AllowedIPs njëkohësisht si tabelë rrugëtimi dhe si listë aksesi. Gjatë dërgimit, adresa e destinacionit kërkohet në AllowedIPs e peer-it për të zgjedhur tunelin; gjatë marrjes, adresa burimore e brendshme duhet të bjerë brenda AllowedIPs e peer-it që dërgon, përndryshe paketa hidhet. Një gamë që mungon në cilëndo anë jep të njëjtin simptom: transporti funksionon, ngarkesa zhduket.

Lexoni gjendjen e gjallë në vend të skedarit, sepse një ringarkim mund të ketë dështuar në heshtje: sudo wg show wg0 allowed-ips. Në server, hyrja e peer-it që dështon duhet të përfshijë adresën e tunelit të tij, për shembull 10.90.0.3/32. Në klient, hyrja e peer-it server duhet të përfshijë destinacionin që po testoni, qoftë adresa e tunelit të hub-it qoftë nënrrjeta e largët. Gammat që mbivendosen e bëjnë kërkimin të paqartë dhe mund të zgjedhin një peer që nuk e kishit ndërmend, prandaj mbajini të ndara.

Hapi 3: Kontrolloni adresën burimore të brendshme

Një klient që rrugëton 10.90.0.3 përmes wg0 por dërgon paketa nga adresa e tij Wi-Fi do të refuzohet nga marrësi, sepse burimi nuk përputhet me AllowedIPs e peer-it. Konfirmoni çfarë zgjedh në të vërtetë kerneli me ip route get 10.90.0.3 from 10.90.0.2, dhe konfirmoni adresën e caktuar për ndërfaqen e tunelit me ip -brief addr show wg0.

Në host-in Linux që merr, filtrimi i rrugës së kthimit është porta e dytë. Një rp_filter i rreptë në ndërfaqen që zotëron rrugën e kthimit mund të hedhë trafikun e tunelit, rruga e kthimit e të cilit nuk përputhet me ndërfaqen nga e cila mbërriti. Kontrolloni vlerën efektive përpara se ta çaktivizoni; në shumë topologji korrigjimi i duhur është një rrugë, jo një filtër i liruar.

Hapi 4: Rishikoni përcjelljen në hub dhe rrugën e kthimit

Nëse hub-i duhet të përcjellë ndërmjet peer-ave, kernelit i nevojitet net.ipv4.ip_forward=1, dhe muri i zjarrit duhet të pranojë rrjedhën e përcjellë: hyrje në wg0, dalje në wg0, nga adresa e tunelit e dërguesit te ajo e marrësit. Një dështim i zakonshëm është një rregull hyrjeje që pranon UDP 51820 por pa rregull përcjelljeje], kështu që shtrëngimi i duarve ka sukses dhe ngarkesa vdes. Listoni rregullat efektive me sudo nft list ruleset ose ekuivalentin për menaxherin tuaj të murit të zjarrit.

Më pas kontrolloni përgjigjen. Host-i i destinacionit duhet të ketë një rrugë kthimi te dërguesi, ose përmes hub-it ose përmes portës së tij. Nëse hub-i bën gjithashtu NAT në nënrrjetën e tunelit, konfirmoni që përkthimi zbatohet për rrjedhën e përcjellë dhe se përgjigja arrin hub-in përpara se gjendja të skadojë. Një dështim njëdrejtimësh që duket si problem çelësi është shpesh vetëm kjo rrugë kthimi.

Së fundi, ndani shtrëngimin e duarve nga të dhënat. Një peer që përfundon shtrëngimin e duarve por ngec në transferime të mëdha zakonisht ka një problem MTU ose MSS në atë rrugë të caktuar, jo një problem AllowedIPs. Testoni fillimisht me një ping të vogël, pastaj me një me madhësi të plotë, dhe krahasoni të dy peer-at.

Hapi 5: Ndryshoni një gjë dhe mbani të paprekur peer-in që funksionon

Bëni një ndryshim të vetëm në rrugën që dështon dhe riprovoni të dy peer-at. Zëvendësimi i AllowedIPs të secilit peer me 0.0.0.0/0 është mënyra më e shpejtë për të thyer peer-in që funksiononte më parë, sepse ndryshon vendimin e rrugëtimit për të gjithë trafikun në atë ndërfaqe. Redaktoni atë një hyrje, ringarkoni dhe lexoni gjendjen e gjallë.

Shënoni cila rrugë pati sukses, cila dështoi dhe daljen e saktë të komandës për secilën. Ai krahasim vlen më shumë se një raport i përgjithshëm që VPN-ja është prishur, dhe është gjëja e parë që do të kërkojë personi tjetër.