WireGuard werk eers nadat die bediener stuur: kennis van die eindpunt

Die tonnel lyk of hy net werk nadat die bediener eerste iets stuur. Begin by die kliënt en niks gebeur nie, wag 'n paar sekondes, probeer weer en dit slaag. Die gewone diagnose is 'n gebreekte NAT, en die gewone diagnose is verkeerd. Wat verander het, is dat een eweknie geleer het waar die ander een woon.

Kennis van die eindpunt, nie bereikbaarheid nie

'n WireGuard-eweknie begin nie 'n handskud voordat hy weet waarheen om dit te stuur nie. Die konfigurasie voorsien dit as 'n eindpunt van adres en poort, en die lopende toestand hou die eindpunt waarvan hy tans oortuig is dop.

wg show druk beide kante van daardie prentjie, en 'n eweknie sonder 'n eindpunt in die uitset kan niks begin nie, hoe korrek sy publieke sleutel en toegelate voorvoegsels ook al is. Vergelyk die kliënt se siening met dié van die bediener voordat jy enige reël verander, want die twee stem dikwels nie saam oor wie wat weet nie.

Hoe 'n eweknie 'n eindpunt leer

WireGuard is doelbewus stil. Wanneer 'n korrek geauthentiseerde pakket van 'n adres arriveer wat die eweknie nie verwag het nie, werk die implementering daardie eweknie se eindpunt op na die nuwe bron, en dit is hoe swerwing werk op 'n skootrekenaar wat netwerke verander. Daardie gedrag verduidelik die rigtingafhanklikheid: as die bediener eerste stuur en sy pakket die kliënt bereik, leer die kliënt die bediener se huidige adres en kan antwoord. Tot dan het hy nêrens omheen om te stuur nie. Die meganisme is geauthentiseerde swerwing eerder as 'n kortpad van vertroue by eerste gebruik, want die pakket moes geldig wees voordat die eindpunt geskuif het.

Die dokumentasie vir wg beskryf daardie opdatering, en dit is die moeite werd om dit een keer te lees as jy rondom dit gaan ontwerp.

Toestandbehoudende vertaling voeg sy eie rigting by

Waar UDP deur 'n vertalende poort gaan, skep die poort toestand vir die eerste pakket wat hy sien. RFC 4787 beskryf daardie gedrag en die tydgrense wat die kaart uiteindelik verwyder. 'n Ledige kaart verval, en 'n inkomende pakket van die ander kant word dan deur die poort laat val voordat dit die gasheer bereik. 'n Tonnel wat die hele oggend gewerk het, hou op antwoord in die middag juis om hierdie rede.

Dit is 'n tweede en onafhanklike meganisme wat dieselfde rigtingsimptoom lewer. Kennis van die eindpunt en vertaaltoestand moet albei reg wees, en om die een reg te maak maak nie die ander reg nie.

Stel die rigting in wat jy werklik wil hê

Vir 'n kliënt wat die verbinding moet begin, sit die bediener se eindpunt in die kliënt se eweknie-afdeling en hou dit daar. Om daarop te staatmaak dat die bediener eerste stuur, is om op 'n toeval in die verkeersorde te staatmaak wat op 'n stil netwerk sal verander. Die konfigurasie behoort die bedoelde rigting te noem, nie dit te ontdek nie.

Vir 'n eweknie agter vertaling wat bereikbaar moet bly, aktiveer 'n aanhoudende keepalive aan daardie kant. 'n Keepalive elke 25 sekondes is die gewone beginwaarde, en die doel daarvan is om die kaart oop te hou eerder as om die tonnel te toets. Kies een kant om dit te dra, want om dit aan albei kante te aktiveer verdubbel die verkeer en die loggeraas sonder om die uitkoms te verbeter.

Vergelyk toestand voor en na die sneller

Neem die twee sienings op die oomblik dat dit misluk, en dan weer nadat die bediener stuur. Die eerste opdrag wys eindpunte en die ouderdom van die handskud. Die tweede wys of daar 'n vertaalinskrywing vir die poort bestaan. Die opname wys watter rigting werklik oor die draad gegaan het, en die roetekontrole bevestig dat die kliënt daardie verkeer nie heeltemal elders heen stuur nie.

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

Teken die eindpuntkolom en die vertaalinskrywing saam aan. 'n Eweknie sonder 'n eindpunt en 'n poort sonder 'n kaart is twee verskillende foute. Net een van hulle word deur 'n keepalive reggemaak.