WireGuard-eweknie onbereikbaar terwyl ’n ander werk: kontrolelys

Een WireGuard-eweknie dra verkeer en ’n tweede een handdruk, maar bereik nooit iets agter die tonnel nie. Die werkende eweknie sê vir jou dat die koppelvlak, die UDP-poort en die bediener se sleutel waarskynlik reg is. Dit sê niks oor die tweede eweknie se AllowedIPs, sy binneste bronadres of die deurstuurreëls tussenin nie. Werk die lys in volgorde deur en stop by die eerste stap waarvan die voorwaarde misluk.

Stap 1: Skryf neer watter pad die pakket behoort te volg

Twee kliënte op dieselfde hub bereik mekaar nie outomaties nie. In ’n hub-en-spaak-ontwerp ontvang die bediener die pakket op wg0 en moet dit weer uit wg0 na die ander eweknie deurstuur, wat IP-deursturing en ’n deurstuurreël vereis. In ’n direkte eweknie-tot-eweknie-ontwerp het elke kant die ander se eindpunt en die ander se tonneladres binne AllowedIPs nodig. Besluit watter ontwerp jy ontfout voordat jy enige konfigurasie lees.

Die verwagte pad sê ook vir jou waar om te kyk. As die pakket oor die hub moet gaan, is die mislukte hop óf die sender se AllowedIPs, óf die hub se deursturing, óf die ontvanger se AllowedIPs. As dit reguit moet gaan, is die hub irrelevant en maak die eindpuntvelde op beide eweknieë saak.

Stap 2: Vergelyk AllowedIPs aan beide kante, nie net een nie

WireGuard gebruik AllowedIPs as beide ’n roetetabel en ’n toegangslys. By versending word die bestemmingsadres in die eweknie se AllowedIPs nageslaan om die tonnel te kies; by ontvangs moet die binneste bronadres binne die sturende eweknie se AllowedIPs val, anders word die pakket laat val. ’n Ontbrekende reeks aan enige kant lewer dieselfde simptoom: vervoer werk, die vrag verdwyn.

Lees die lewende toestand eerder as die lêer, want ’n herlaai kon stilweg misluk het: sudo wg show wg0 allowed-ips. Op die bediener moet die mislukte eweknie se inskrywing sy tonneladres insluit, byvoorbeeld 10.90.0.3/32. Op die kliënt moet die bediener-eweknie se inskrywing die bestemming insluit wat jy toets, of dit nou die hub se tonneladres of die afgeleë subnet is. Oorvleuelende reekse maak die naslaan dubbelsinnig en kan ’n eweknie kies wat jy nie bedoel het nie, so hou hulle geskei.

Stap 3: Kontroleer die binneste bronadres

’n Kliënt wat 10.90.0.3 deur wg0 roet, maar pakkette vanaf sy Wi-Fi-adres stuur, sal deur die ontvanger verwerp word, want die bron stem nie ooreen met die eweknie se AllowedIPs nie. Bevestig wat die kern werklik kies met ip route get 10.90.0.3 from 10.90.0.2, en bevestig die adres wat aan die tonnelkoppelvlak toegewys is met ip -brief addr show wg0.

Op die ontvangende Linux-gasheer is tru-pad-filtering ’n tweede hek. ’n Streng rp_filter op die koppelvlak wat die terugroete besit, kan tonnelverkeer laat val waarvan die terugpad nie ooreenstem met die koppelvlak waarop dit aangekom het nie. Kontroleer die effektiewe waarde voordat jy dit deaktiveer; in baie topologieë is die regte oplossing ’n roete, nie ’n verswakte filter nie.

Stap 4: Hersien die hub se deursturing en die terugpad

As die hub tussen eweknieë moet deurstuur, het die kern net.ipv4.ip_forward=1 nodig, en die vuurmuur moet die deurgestuurde vloei aanvaar: in op wg0, uit op wg0, van die sender se tonneladres na die ontvanger s’n. ’n Algemene fout is ’n invoerreël wat UDP 51820 aanvaar maar geen deurstuurreël nie], so die handdruk slaag en die vrag sterf. Lys die effektiewe reëls met sudo nft list ruleset of die ekwivalent vir jou vuurmuurhanteerder.

Kontroleer dan die antwoord. Die bestemmingsgasheer moet ’n roete terug na die sender hê, hetsy deur die hub of deur sy eie poort. As die hub ook die tonnelsubnet NAT, bevestig dat die vertaling op die deurgestuurde vloei van toepassing is en dat die antwoord die hub bereik voordat die toestand verval. ’n Eenrigtingfout wat soos ’n sleutelprobleem lyk, is dikwels net hierdie terugroete.

Skei laastens die handdruk van die data. ’n Eweknie wat ’n handdruk voltooi maar by groot oordragte vasval, het gewoonlik ’n MTU- of MSS-probleem op daardie spesifieke pad, nie ’n AllowedIPs-probleem nie. Toets eers met ’n klein ping, dan met een van volle grootte, en vergelyk die twee eweknieë.

Stap 5: Verander een ding en hou die werkende eweknie ongeskonde

Maak ’n enkele verandering aan die mislukte pad en toets beide eweknieë weer. Om elke eweknie se AllowedIPs met 0.0.0.0/0 te vervang is die vinnigste manier om die eweknie te breek wat reeds gewerk het, want dit verander die roetebesluit vir alle verkeer op daardie koppelvlak. Wysig die een eweknie, herlaai, en lees die lewende toestand terug.

Teken aan watter pad geslaag het, watter een misluk het, en die presiese opdraguitvoer vir elkeen. Daardie vergelyking is meer werd as ’n algemene verslag dat die VPN stukkend is, en dit is die eerste ding wat die volgende persoon sal vra.