AllowedIPs este o listă de rutare, nu o regulă de firewall

Majoritatea oamenilor citesc AllowedIPs ca pe o listă de permisiuni, mulțimea adreselor care se pot conecta la un peer, cam ca o regulă de firewall scrisă pentru un tunel. Nu este așa. Câmpul este un tabel de rutare care lucrează în ambele direcții: alege un peer pentru un pachet de ieșire și validează sursa unui pachet de intrare. Citirea lui ca listă de acces produce configurații care rutează trafic pe care nimeni nu l-a cerut.

Un câmp, doi cititori: alegerea ieșirii și verificarea sursei

La client, prefixele decid ce destinații merg la acel peer și care rămân în rețeaua obișnuită. De aceea o intrare pentru 0.0.0.0/0 prinde fiecare destinație IPv4, și de aceea importul unui profil de tunel complet trimite navigarea obișnuită prin mașina aflată la distanță. Intrările înguste fac invers: rutează doar rețelele pe care le-ați listat și lasă tot restul unde era. Secțiunea despre rutarea cheilor criptografice din documentația WireGuard prezintă ambele sarcini într-un singur loc: alegerea peer-ului de ieșire și validarea sursei de intrare.

Pe server, același câmp descrie ce adrese sursă poate folosi fiecare peer. Este o verificare criptografică, nu un filtru de pachete: un pachet a cărui sursă internă nu se potrivește cu lista peer-ului este aruncat în interiorul WireGuard înainte ca vreun firewall al gazdei să-l vadă. Ambele sarcini împart o singură listă, și exact de aceea o listă copiată de altundeva se comportă greșit într-un loc la care nu v-ați gândit.

Blocul clientului este locul unde începe cea mai mare parte a acestei confuzii. Un tunel divizat numește rețelele la distanță, iar un tunel complet este același câmp cu un prefix implicit:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Ambele forme sunt complete în sine și sunt alternative, nu pași. Prima trimite prin tunel doar acele două rețele; a doua trimite fiecare destinație, iar intrarea ::/0 adaugă IPv6 la valoarea implicită IPv4. Orice ați alege, acele prefixe sunt întreaga decizie de rutare pentru acel peer odată ce wg-quick începe să instaleze rute.

Hubul are nevoie de o altă listă

Un hub listează adresa de tunel a fiecărui client ca prefix de gazdă, plus orice rețea care se află cu adevărat în spatele acelui client. Copierea listei largi a unui client pe fiecare peer al hubului îi spune hubului că mulți peers pot folosi aceleași adrese ca sursă, iar asta nu este un plan de adresare. Câmpul Endpoint aparține unei cu totul alte straturi: numește adresa și portul exterioare ale peer-ului, niciodată o destinație din interiorul tunelului.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

Prefixul de gazdă poartă adresa tunelului, iar prefixul de rețea poartă ce se află în spatele clientului, și ambele sunt necesare. Fără prefixul de gazdă hubul nu poate returna traficul propriu al clientului, iar fără prefixul de rețea LAN-ul din spate rămâne inaccesibil; un peer fără nimic în spate primește doar prefixul de gazdă.

Omiterea instalării rutelor lasă o lacună

wg-quick, ajutorul care ridică o interfață dintr-un fișier de configurare, instalează adrese de interfață și rute ca parte a acelei lucrări. Setarea Table = off îi spune ajutorului să omită lucrul cu rutele, ceea ce nu instalează înlocuitori și nu face rețeaua privată accesibilă. Când rutele automate fac deja treaba, numirea prefixelor de care aveți nevoie este configurația mai clară. Dezactivarea gestionării rutelor și lăsarea înlocuitorului nescris nu este un design, ci o omisiune.

Instrumentul de bază wg se comportă diferit: configurează interfața și nu atinge niciodată rutele, așa că o instalare construită direct pe el are nevoie de propriile comenzi de rută. Instrucțiunile scrise pentru un instrument pot părea greșite când sunt urmate cu celălalt. Un ping reușit este și o dovadă slabă, pentru că testează o singură cale, nu fiecare cale de aplicație de care aveți nevoie.

DNS și IPv6 se decid separat

Verificați adresa serverului DNS anunțată de tunel și confirmați că există o rută către acea adresă prin prefixele alese. O setare a resolverului nu face resolverul accesibil, iar îngustarea unui tunel poate elimina în liniște ruta care ducea acolo. Inspectați IPv6 și separat, pentru că o împărțire IPv4 corectă nu spune nimic despre o rută implicită IPv6 care încă indică legătura fizică. Trei decizii separate se pot schimba deodată când editați un singur bloc de peer.

Apoi deschideți o resursă privată și un site obișnuit dintr-o configurație inițială cunoscută. Dacă resursa răspunde și navigarea iese în continuare prin conexiunea locală, împărțirea face ceea ce ați cerut. Dacă navigarea se rupe în același moment, tunelul a luat ruta implicită, iar lista de prefixe este locul unde trebuie să priviți.