WireGuard töötab alles pärast seda, kui server saadab: lõpp-punkti teadmine

Tunnel näib töötavat alles pärast seda, kui server kõigepealt midagi saadab. Alustage kliendist ja midagi ei juhtu, oodake paar sekundit, proovige uuesti ja see õnnestub. Tavaline diagnoos on katkine NAT, ja tavaline diagnoos on vale. Muutus see, et üks pool õppis, kus teine asub.

Lõpp-punkti teadmine, mitte kättesaadavus

WireGuardi pool ei alusta käepigistust enne, kui teab, kuhu see saata. Konfiguratsioon annab selle aadressi ja pordi lõpp-punktina ning töötav olek jälgib lõpp-punkti, mida see praegu usub.

wg show näitab selle pildi mõlemat poolt ja väljundis lõpp-punktita pool ei saa midagi alustada, ükskõik kui õige on tema avalik võti ja lubatud prefiksid. Võrrelge kliendi vaadet serveri omaga enne mis tahes reegli muutmist, sest need kaks ei nõustu sageli selles, kes mida teab.

Kuidas pool lõpp-punkti õpib

WireGuard on meelega vaikne. Kui õigesti autenditud pakett saabub aadressilt, mida pool ei oodanud, uuendab teostus selle poole lõpp-punkti uueks allikaks, ja nii töötab rändlus sülearvutis, mis vahetab võrke. See käitumine selgitab suunasõltuvust: kui server saadab esimesena ja tema pakett jõuab kliendini, õpib klient serveri praeguse aadressi ja saab vastata. Seni pole tal kuhugi saata. Mehhanism on autenditud rändlus, mitte esmakasutuse usalduse otsetee, sest pakett pidi olema kehtiv enne, kui lõpp-punkt liikus.

wg tööriistadokumentatsioon kirjeldab seda uuendust ja seda tasub üks kord lugeda, kui kavatsete selle ümber projekteerida.

Olekupõhine tõlge lisab oma suuna

Kui UDP läbib tõlkivat lüüsi, loob lüüs oleku esimese nähtud paketi jaoks. RFC 4787 kirjeldab seda käitumist ja ajalimiite, mis lõpuks kaardistuse eemaldavad. Tühikäiguline kaardistus aegub ja siis lüüs viskab kaugemalt tuleva sissetuleva paketi ära enne, kui see jõuab hostini. Tunnel, mis töötas kogu hommiku, lakkab täpselt sel põhjusel pärastlõunal vastamast.

See on teine ja sõltumatu mehhanism, mis tekitab sama suunalise sümptomi. Nii lõpp-punkti teadmine kui ka tõlkeolek peavad olema õiged, ja ühe parandamine ei paranda teist.

Seadistage suund, mida te tegelikult soovite

Kliendi jaoks, kes peab ühenduse alustama, pange serveri lõpp-punkt kliendi poolte sektsiooni ja jätke see sinna. Lootmine sellele, et server saadab esimesena, on lootmine liikluse järjekorra juhusele, mis muutub vaikses võrgus. Konfiguratsioon peaks kavatsetud suuna deklareerima, mitte seda avastama.

Tõlke taga oleva poole jaoks, mis peab jääma kättesaadavaks, lubage sellel poolel püsiv keepalive. Keepalive iga 25 sekundi järel on tavaline algväärtus ja selle eesmärk on hoida kaardistus avatud, mitte tunnelit testida. Valige üks pool, mis seda kannab, sest mõlemal poolel lubamine kahekordistab liikluse ja logimüra tulemust parandamata.

Võrrelge olekut enne ja pärast vallandajat

Salvestage kaks vaadet hetkel, mil see ebaõnnestub, ja siis uuesti pärast seda, kui server saadab. Esimene käsk näitab lõpp-punkte ja käepigistuse vanust. Teine näitab, kas pordi jaoks on tõlkekirje. Salvestus näitab, milline suund tegelikult juhtmest üle läks, ja marsruudikontroll kinnitab, et klient ei saada seda liiklust hoopis mujale.

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

Märkige lõpp-punkti veerg ja tõlkekirje koos üles. Pool ilma lõpp-punktita ja lüüs ilma kaardistuseta on kaks erinevat riket. Ainult ühte neist parandab keepalive.