WireGuard-peer net berikber wylst in oar wurket: kontrolelist

Ien WireGuard-peer jout ferkear troch en in twadde docht de hânskutting mar berikt nea eat efter de tunnel. De wurkjende peer fertelt jo dat de ynterface, de UDP-poarte en de kaai fan de server wierskynlik yn oarder binne. Hy fertelt neat oer de AllowedIPs fan de twadde peer, syn ynderlike boarneadres of de trochstjoerregels dertusken. Wurkje de list yn folchoarder ôf en stop by de earste stap waans betingst net foldocht.

Stap 1: Skriuw it paad op dat it pakket folgje moat

Twa kliïnten op deselde hub berikke inoar net automatysk. Yn in hub-en-spaak-ûntwerp ûntfangt de server it pakket op wg0 en moat it wer út wg0 trochstjoere nei de oare peer, wat IP-trochstjoering en in trochstjoerregel freget. Yn in direkt peer-oant-peer-ûntwerp hat elke kant it einpunt fan de oare en it tunneladres fan de oare yn AllowedIPs nedich. Beslis hokker ûntwerp jo debugge ear't jo hokker konfiguraasje dan ek lêze.

It ferwachte paad fertelt jo ek wêr't jo sjen moatte. As it pakket oer de hub moat, is de mislearre hop óf de AllowedIPs fan de stjoerder, óf de trochstjoering fan de hub, óf de AllowedIPs fan de ûntfanger. As it direkt gean moat, is de hub net relevant en binne de einpuntfjilden op beide peers fan belang.

Stap 2: Fergelykje AllowedIPs oan beide kanten, net mar ien

WireGuard brûkt AllowedIPs as sawol in rûtetabel as in tagongslist. By it stjoeren wurdt it bestimmingsadres yn ’e AllowedIPs fan de peer socht om de tunnel te kiezen; by it ûntfangen moat it ynderlike boarneadres binnen de AllowedIPs fan de stjoerende peer falle, oars wurdt it pakket weilitten. In ûntbrekkend berik oan ien fan beide kanten jout itselde symptoom: transporter wurket, de lading ferdwynt.

Lês de libbene steat yn stee fan it bestân, want in werladen koe stil mislearre wêze: sudo wg show wg0 allowed-ips. Op de server moat de yngong fan de mislearre peer syn tunneladres befetsje, bygelyks 10.90.0.3/32. Op de kliïnt moat de yngong fan de serverpeer it bestimming befetsje dat jo testen, itsij dat it tunneladres fan de hub is, itsij it fiere subnet. Oerlaapjende berikken meitsje it sykjen dûbelsinnich en kinne in peer kieze dy't jo net bedoelden, hâld se dêrom skieden.

Stap 3: Kontrolearje it ynderlike boarneadres

In kliïnt dy't 10.90.0.3 fia wg0 rûtet, mar pakketten fan syn Wi-Fi-adres stjoert, sil troch de ûntfanger wegere wurde, want de boarne komt net oerien mei de AllowedIPs fan de peer. Befêstigje wat de kernel eins kiest mei ip route get 10.90.0.3 from 10.90.0.2, en befêstigje it adres dat oan ’e tunnelinterface tawiisd is mei ip -brief addr show wg0.

Op de ûntfangende Linux-host is omkeare-paadfiltering in twadde poarte. In strang rp_filter op ’e interface dy't de weromrûte hat, kin tunnelferkear weilitte wêrfan it werompaad net oerienkomt mei de interface dêr't it op oankaam. Kontrolearje de effektive wearde ear't jo it útskeakelje; yn in soad topologyen is de juste repaasje in rûte, net in fersloppe filter.

Stap 4: Besjoch de trochstjoering fan de hub en it werompaad

As de hub tusken peers trochstjoere moat, hat de kernel net.ipv4.ip_forward=1 nedich, en de firewall moat de trochstjoerde stream akseptearje: yn op wg0, út op wg0, fan it tunneladres fan de stjoerder nei dat fan de ûntfanger. In faak foarkommende flater is in ynfierregel dy't UDP 51820 akseptearret mar gjin trochstjoerregel], sadat de hânskutting slagget en de lading stjert. List de jildende regels mei sudo nft list ruleset of it ekwivalint foar jo firewallbehearder.

Kontrolearje dan it antwurd. De bestimmingshost moat in rûte werom nei de stjoerder hawwe, itsij fia de hub, itsij fia syn eigen gateway. As de hub ek de tunnelsubnet NAT, befêstigje dat de oersetting jildt foar de trochstjoerde stream en dat it antwurd de hub berikt ear't de steat ferrint. In ienrjochtingsflater dy't op in kaaiprobleem liket, is faak krekt dizze weromrûte.

Skied úteinlik de hânskutting fan de gegevens. In peer dy't de hânskutting foltôget mar by grutte oerdrachten fêstrint, hat meastentiids in MTU- of MSS-probleem op krekt dat paad, net in AllowedIPs-probleem. Testearje earst mei in lytse ping, dêrnei mei ien fan folsleine grutte, en fergelykje de twa peers.

Stap 5: Feroarje ien ding en hâld de wurkjende peer yntakt

Meitsje ien inkelde feroaring oan it mislearre paad en testearje beide peers opnij. It ferfangen fan de AllowedIPs fan elke peer troch 0.0.0.0/0 is de fluchste manier om de peer te brekken dy't al wurke, want it feroaret de rûtebeslissing foar al it ferkear op dy interface. Bewurkje de iene yngong, werlaad, en lês de libbene steat werom.

Skriuw op hokker paad slagge, hokker mislearre, en de krekte opdrachttútfier foar elk. Dy fergeliking is mear wurdich as in algemien ferhaal dat it VPN stikken is, en it is it earste ding dêr't de folgjende persoan om freegje sil.