Peerul WireGuard iese prin WAN-ul greșit: cinci verificări în ordine

Pe un gateway cu mai multe uplinkuri, handshake-ul și fluxul redirecționat pot lua căi diferite. Parcurgeți regula, marcajul, traducerea și răspunsul în această ordine.

Două uplinkuri, un gateway și un peer WireGuard al cărui trafic apare mereu pe linia de rezervă. Handshake-ul rămâne sănătos tot timpul. De aceea simptomul este ușor de citit greșit ca defect WireGuard în loc de defect de rutare.

Efectuați verificările de mai jos în ordine. Fiecare are o condiție de oprire, iar sărirea înainte produce de obicei un răspuns greșit și încrezător.

Separați handshake-ul de fluxul redirecționat

Schimbul criptat cu peerul are o rută de punct final către adresa publică a serverului. Traficul de client redirecționat are o altă destinație și poate fi selectat de marcaje sau reguli de politică. Sunt două decizii de rutare care împart o interfață. Tratarea uneia ca dovadă despre cealaltă este prima greșeală.

Opriți-vă imediat ce vă prindeți raționând pornind de la handshake. Este dovadă doar despre calea către punctul final.

Citiți regula de politică, nu tabelul implicit

Un tabel implicit arată ce se întâmplă când nicio regulă de politică nu se potrivește. Pe un gateway care rutează după sursă, marcaj sau destinație, regula decisivă trăiește altundeva. Tabelul simplu poate părea perfect rezonabil în timp ce alegerea reală se face deasupra lui.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Citiți regulile de politică și tabelele către care indică. Apoi confirmați care regulă se potrivește fluxului vostru de test. O regulă care face referire la o interfață ce nu mai poartă uplink-ul dorit este o constatare, nu un detaliu. Căutarea rutei la final arată răspunsul mult mai repede decât citirea unui tabel și ghicirea.

Verificați marcajul și traducerea împreună

Rutarea pe politică se bazează pe un marcaj de pachet setat mai devreme în lanț. Dacă regula de marcare ratează traficul vostru, fluxul cade în tabelul principal și iese prin ce este implicit acolo. Pachetele redirecționate sar adesea peste lanțuri scrise pentru trafic generat local.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

Traducerea trebuie să fie de acord cu uplink-ul care poartă fluxul. O regulă care traduce către adresa primară în timp ce pachetul iese prin linia de rezervă produce răspunsuri adresate unei interfețe pe care fluxul nu a folosit-o niciodată. Verificați condiția de interfață a regulii de traducere. O regulă necondiționată funcționează până când este folosit al doilea uplink, apoi eșuează într-un mod care pare intermitent.

Urmăriți ce interfață poartă răspunsul

Capturați pe ambele uplinkuri în timp ce rulează o cerere. Notați ce interfață poartă cererea și care poartă răspunsul. Căile asimetrice sunt mult mai ușor de văzut decât de prezis.

Dacă răspunsul sosește prin uplink-ul greșit, problema s-a mutat de la WireGuard la urmărirea conexiunilor sau la traducere. Nicio modificare a configurației peerului nu o va remedia.

Schimbați un singur lucru cu o cale de întoarcere

Păstrați acces prin consolă sau în afara benzii înainte de a edita reguli de politică pe un gateway. Faceți o singură modificare, testați aceeași destinație autorizată, apoi reconectați-vă și confirmați că handshake-ul folosește în continuare calea dorită către punctul final. Adăugați un test numeric pe a doua familie de adrese, deoarece o politică doar pentru v4 lasă aceeași greșeală disponibilă.

Notați ce uplink a folosit fiecare flux. Acea evidență transformă următorul raport într-o verificare de două minute în loc de o după-amiază întreagă. notele WireGuard despre spații de nume și rutare descriu cum să separați deliberat calea către punctul final de traficul tunelat, ceea ce este de obicei mai curat decât copierea unei soluții ocolitoare cu rută implicită.

Articole similare