WireGuard AllowedIPs: ruta pe care NetworkManager nu a adăugat-o niciodată

Contorul strângerilor de mână se actualizează, interfața își păstrează adresa, iar un ping către cealaltă parte nu ajunge nicăieri. Această combinație încurcă oamenii, pentru că o strângere de mână funcțională pare dovada că tunelul este gata. Nu este: un tunel poate fi complet negociat și totuși să nu aibă nicio rută care să direcționeze traficul în el, iar acestea sunt două sarcini separate executate de două bucăți separate de stare. Remedierea depinde în întregime de care dintre cele două lipsește, așa că primul pas este să aflăm acest lucru.

wg-quick le face pe amândouă fără să fie rugat. Suportul WireGuard integrat în NetworkManager instalează de asemenea rute către peeri în mod implicit, ceea ce restrânge suspecții la o opțiune dezactivată, la un alt tabel de rutare sau la o configurație importată prin altceva.

Confirmați tunelul înainte de a urmări ruta

wg show afișează interfața, peerul, punctul final și vechimea ultimei strângeri de mână, iar ip addr show confirmă că adresa este prezentă. O strângere de mână recentă înseamnă că cheile, punctul final și calea UDP funcționează. Tot ce este stricat se află în aval de ele: rutare, filtrare sau rezolvare de nume.

Apoi întrebați nucleul ce ar face cu o destinație reală în locul uneia ipotetice: ip route get 10.42.7.9. Răspunsul numește interfața de ieșire și adresa sursă pe care pachetul ar purta-o. Când numește adaptorul fizic, pachetul nu intră niciodată în tunel, oricât de sănătoasă ar părea strângerea de mână.

AllowedIPs este un filtru și o listă de rute

Prefixele din AllowedIPs fac două lucruri. Aleg care peer transportă o destinație de ieșire și validează adresa sursă a pachetelor primite, care este limita rutării pe cheie criptografică. În wg-quick ele guvernează și instalarea automată a rutelor, iar exact acest comportament suplimentar explică de ce aceeași configurație funcționează din terminal și nu dintr-un client desktop.

În cazul din spatele acestui articol, profilul a fost importat printr-un plugin terț și nu prin suportul integrat, iar interfața a pornit fără ruta prefixului. Listarea tabelului arată asta imediat: ip route show conține doar ruta conectată pentru adresa interfeței și nimic pentru intervalul îndepărtat.

Întrebați dacă rutele către peeri sunt activate măcar

Citiți setarea înainte de a modifica ceva: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Când peer-routes arată no, reparația acceptată este nmcli connection modify work-wg wireguard.peer-routes yes, urmată de o reconectare. Adăugarea în schimb a unei rute statice funcționează până la următoarea activare și apoi dispare în tăcere. Acea dispariție este indiciul: o rută care se întoarce ca un mister în fiecare dimineață nu este instalată de profil.

Dacă opțiunea este deja activată, verificați dacă prefixul trăiește într-un alt tabel cu ip route show table all | grep 10. O rută într-un tabel care nu este cel principal nu lipsește, este pur și simplu invizibilă pentru o căutare care consultă doar tabelul principal. Reparați rutarea politicii în loc să stivuiți o intrare duplicată deasupra.

Adăugați prefixul la conexiune, nu la sistemul care rulează

În editorul de conexiuni, pagina WireGuard ține peerul și AllowedIPs-urile sale, iar pagina IPv4 ține rute suplimentare. O rută adăugată acolo supraviețuiește reconectărilor pentru că aparține profilului. Pe linia de comandă echivalentul este să atașați o rută la conexiune în forma cu poartă goală, apoi să coborâți și să ridicați conexiunea astfel încât modificarea să fie aplicată.

Alegeți cel mai îngust prefix care acoperă gazdele de care aveți nevoie. Copierea exemplului /8 al furnizorului poate înghiți intervale locale care se întâmplă să fie în interiorul lui, iar defecțiunile rezultate arată ca un tunel stricat, nu ca o rută prea largă.

Tunelul divizat este decis de lista de prefixe

Nu există niciun comutator pentru tunelul divizat; lista de prefixe este decizia. Un peer cu un interval pentru LAN-ul biroului și unul pentru o rețea de laborator trimite exact acele destinații prin tunel și lasă tot restul în pace. O singură gazdă are nevoie de un /32, iar intervalele care se suprapun în două locuri au nevoie de prefixe de gazdă până când cineva renumerotează o subrețea.

Alegerea de a nu trimite nimic prin tunel duce aceeași decizie la limita ei: o listă minimă ține legătura sus în timp ce traficul obișnuit își urmează calea obișnuită. Notați intenția, altfel următorul cititor va lua lista scurtă drept o scăpare și o va extinde cu bunăvoință.

Un singur proprietar pentru tabelul de rutare

wg-quick și NetworkManager cred amândouă că dețin rutele interfeței. Importați o configurație scrisă pentru wg-quick și apoi porniți și serviciul wg-quick, iar veți obține intrări duplicate sau contradictorii al căror comportament depinde de care a rulat ultima. Alegeți un singur proprietar și eliminați-l pe celălalt: dacă NetworkManager administrează conexiunea, dezactivați unitatea wg-quick pentru acea interfață și nu adăugați niciodată un al doilea profil pentru același dispozitiv.

Când divizarea trebuie să urmeze un adaptor fizic în locul unei destinații, ați trecut la rutarea politicii, iar rutarea politicii are nevoie și ea de un singur autor. Verificați repetând ip route get, apoi ajungând la o gazdă din interiorul prefixului îndepărtat cu ceva care tipărește adresa sursă pe care a ales-o. Verificați IPv6 și DNS separat dacă profilul poartă vreunul dintre ele.