WireGuard virker først, når serveren sender: kendskab til slutpunktet

Tunnelen ser ud til kun at virke, når serveren først sender noget. Start fra klienten, og der sker intet, vent et par sekunder, prøv igen, og det lykkes. Den sædvanlige diagnose er en brudt NAT, og den sædvanlige diagnose er forkert. Det, der ændrede sig, er, at den ene part lærte, hvor den anden bor.

Kendskab til slutpunktet, ikke tilgængelighed

En WireGuard-part starter ikke et håndtryk, før den ved, hvor den skal sende det hen. Konfigurationen leverer det som et slutpunkt af adresse og port, og den kørende tilstand følger det slutpunkt, den i øjeblikket tror på.

wg show viser begge sider af det billede, og en part uden slutpunkt i outputtet kan ikke starte noget, uanset hvor korrekt dens offentlige nøgle og tilladte præfikser er. Sammenlign klientens syn med serverens, før du ændrer nogen regel, for de to er ofte uenige om, hvem der ved hvad.

Sådan lærer en part et slutpunkt

WireGuard er med vilje tavs. Når en korrekt godkendt pakke ankommer fra en adresse, som parten ikke forventede, opdaterer implementeringen den parts slutpunkt til den nye kilde, og det er sådan roaming virker på en bærbar computer, der skifter netværk. Den adfærd forklarer retningsafhængigheden: hvis serveren sender først, og dens pakke når klienten, lærer klienten serverens aktuelle adresse og kan svare. Indtil da har den ingen steder at sende hen. Mekanismen er godkendt roaming og ikke en genvej med tillid ved første brug, fordi pakken skulle være gyldig, før slutpunktet flyttede sig.

Værktøjsdokumentationen for wg beskriver den opdatering, og den er værd at læse én gang, hvis du vil designe omkring det.

Tilstandsfuld oversættelse tilføjer sin egen retning

Hvor UDP passerer en oversættende gateway, opretter gatewayen tilstand for den første pakke, den ser. RFC 4787 beskriver den adfærd og de timeouts, der til sidst fjerner posten. En inaktiv post udløber, og en indgående pakke fra den fjerne side bliver derefter kasseret af gatewayen, før den når værten. En tunnel, der virkede hele formiddagen, holder op med at svare om eftermiddagen netop af denne grund.

Dette er en anden og uafhængig mekanisme, der giver det samme retningsbestemte symptom. Både kendskabet til slutpunktet og oversættelsestilstanden skal være rigtige, og at rette den ene retter ikke den anden.

Konfigurer den retning, du faktisk ønsker

For en klient, der skal starte forbindelsen, skal du sætte serverens slutpunkt i klientens part-afsnit og lade det blive der. At stole på, at serveren sender først, er at stole på et tilfælde i trafikrækkefølgen, som vil ændre sig på et stille netværk. Konfigurationen bør angive den tilsigtede retning, ikke opdage den.

For en part bag oversættelse, der skal forblive tilgængelig, skal du aktivere en vedvarende keepalive på den side. En keepalive for hver 25 sekunder er den sædvanlige startværdi, og dens formål er at holde posten åben frem for at teste tunnelen. Vælg én side til at bære den, for aktivering på begge sider fordobler trafikken og logstøjen uden at forbedre resultatet.

Sammenlign tilstand før og efter udløseren

Tag de to visninger i det øjeblik, det fejler, og derefter igen, når serveren har sendt. Den første kommando viser slutpunkter og håndtrykkets alder. Den anden viser, om der findes en oversættelsespost for porten. Optagelsen viser, hvilken retning der faktisk gik over ledningen, og rutechecken bekræfter, at klienten ikke sender den trafik et helt andet sted hen.

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

Noter slutpunktkolonnen og oversættelsesposten sammen. En part uden slutpunkt og en gateway uden post er to forskellige fejl. Kun den ene af dem rettes af en keepalive.