Tunel complet WireGuard: AllowedIPs 0.0.0.0/0 nu este suficient

A pune 0.0.0.0/0, ::/0 în AllowedIPs unui partener este pasul pe care toată lumea îl ține minte, și el decide doar ce trafic are voie partenerul să transporte. Aceste prefixe nu creează rute, nu redirecționează nimic pe cealaltă parte și lasă resolverul fiecărei aplicații exact acolo unde era. Patru lucruri separate trebuie să fie adevărate simultan pentru ca un tunel complet să fie complet, și cel mai bine este să le verificați în ordinea de mai jos, pentru că o verificare ulterioară nu poate salva una anterioară. Fiecare verificare de mai jos este un fapt care poate fi citit de pe o mașină, nu o setare despre care sperați că a fost aplicată.

Ce selectează prefixul partenerului și ce nu

AllowedIPs este simultan un selector și o autorizare. Spune părții locale ce destinații pot fi trimise acestui partener și spune părții receptoare ce adrese sursă poate prezenta acest partener. Aceasta este toată munca. Nimic din acea descriere nu creează o rută pe gazdă, nu activează redirecționarea pe partea îndepărtată și nu atinge rezolvarea numelor.

De aceea o configurație poate părea completă și se poate comporta ca un tunel divizat. Prefixul spune că partenerul ar accepta tot; tabela de rutare a gazdei decide ce ajunge de fapt acolo, iar gateway-ul decide dacă ceva iese. Niciuna dintre aceste trei decizii nu locuiește în secțiunea partenerului.

Rutarea clientului, nu doar lista de parteneri

Manageri precum wg-quick programează tabela de rutare a gazdei în locul dumneavoastră, de aceea două fișiere de configurare identice se comportă diferit în funcție de modul în care a urcat interfața. Un profil minim este suficient de scurt pentru a fi citit dintr-o dată:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Două detalii duc munca. Câmpul Address este un singur prefix de gazdă, nu o subrețea pe care clientul crede că o deține, iar managerul este cel care transformă AllowedIPs implicit într-o rută implicită reală. Ridicați același fișier cu ip link și wg setconf și nu va apărea nicio rută, ceea ce arată ca un tunel stricat și este de fapt un tunel sănătos cu pasul de rutare sărit. Manualul wg-quick documentează rutarea și Table comportamentul pe care îl adaugă acești manageri.

Citiți rezultatul, nu fișierul: ip route get 1.1.1.1 ar trebui să numească interfața tunelului, iar wg show ar trebui să raporteze un handshake recent cu un contor de transfer care se mișcă. Un handshake fără rută înseamnă că managerul nu a rulat niciodată, iar editarea din nou a profilului nu va repara asta. Porniți interfața așa cum o va porni utilizatorul, altfel testul măsoară shell-ul dumneavoastră în locul implementării.

Păstrarea punctului final în afara tunelului

Un tunel complet captează fiecare destinație, inclusiv pe cea cu care trebuie să vorbească pentru a exista. Managerii rezolvă asta adăugând o rută de gazdă pentru punctul final prin gateway-ul original, de aceea o configurație corectă conține aproape întotdeauna o excepție deliberată. Aplicarea jumătății configurației cu un manager și a celeilalte jumătăți manual este modul obișnuit în care această excepție se pierde.

Dacă punctul final este un nume de gazdă care se rezolvă la mai multe adrese, sau la o familie pe care nu o transportați, excepția îmbătrânește prost și tunelul poate eșua după o reconectare care părea de rutină. Fixați punctul final la o adresă pe care o controlați, sau confirmați că managerul o reevaluează, și recitiți ruta de gazdă după fiecare schimbare de rețea.

Același mecanism explică de ce un tunel complet și un portal captiv se ceartă. Portalul se așteaptă să intercepteze traficul pe care tunelul dumneavoastră îl captează acum, așa că în rețelele de hotel și aeroport ridicați tunelul după autentificarea în portal, niciodată înainte.

Redirecționare și calea de întoarcere pe gateway

Pe gateway, activați redirecționarea pentru familia pe care o transportați, permiteți lanțul forward în ambele direcții când traduceți, și confirmați calea de întoarcere cu o căutare specifică sursei. Nimic din toate acestea nu decurge dintr-un handshake reușit, pentru că un handshake dovedește doar că cei doi parteneri pot schimba UDP. Nu spune nimic despre ce se întâmplă după aceea cu pachetul decapsulat.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Căutarea rulează pe gateway și nu pe client, altfel veți citi altă tabelă de rutare. Dacă numește interfața greșită, sau raportează că nu există rută, atunci nicio schimbare pe partea clientului nu va produce o ieșire spre internet. Când gateway-ul traduce adresele clienților la ieșire, răspunsul depinde de acea stare de traducere, așa că regula trebuie să existe pentru ambele sensuri ale fluxului și nu doar pentru cel de ieșire.

DNS și starea de eșec, testate separat

Protocolul în sine nu configurează resolverul niciunei aplicații. wg-quick aplică linia DNS prin integrarea resolverului distribuției, containerele și browserele cu stive proprii o pot ignora, și de aceea un nume poate eșua în timp ce tunelul transportă pachete perfect. Testați cu un nume de gazdă în loc de o adresă, și notați care server a răspuns în loc să presupuneți că a fost cel din profil.

Familiile de adrese sunt un test separat cu un răspuns separat. O rută implicită v4 nu spune nimic despre ce va face conexiunea v6 a unei aplicații, iar un tunel care scurge în tăcere a doua familie este mai rău decât unul care eșuează zgomotos. Întrebați un nume prin fiecare familie, citiți interfața folosită de fiecare cerere, și verificați contoarele de traducere înainte și după, pentru că o regulă care nu se potrivește cu nimic arată identic cu o regulă lipsă.

În final, testați starea pe care o doriți când tunelul se oprește. Un tunel complet ar trebui să eșueze închis pentru traficul pe care îl revendică: dacă interfața cade și aplicațiile continuă în liniște pe legătura fizică, designul este un tunel divizat cu pași în plus. Scrieți comportamentul de eșec dorit, verificați-l deliberat, și încheiați înregistrând cele patru răspunsuri — care manager ridică interfața, care rută poartă cea implicită, cine redirecționează și traduce pe gateway, și care resolver răspunde.