WireGuard puni tunel: AllowedIPs 0.0.0.0/0 nije dovoljno

Stavljanje 0.0.0.0/0, ::/0 u AllowedIPs peera je korak kojeg se svi sjećaju, a on samo odlučuje koji saobraćaj peer smije nositi. Ti prefiksi ne stvaraju rute, ne prosljeđuju ništa na drugoj strani i ostavljaju resolver svake aplikacije tačno tamo gdje je bio. Četiri odvojene stvari moraju vrijediti istovremeno da bi puni tunel bio puni tunel, a najbolje ih je provjeravati redom ispod, jer kasnija provjera ne može spasiti raniju. Svaka provjera ispod je činjenica koju možete pročitati s mašine, a ne postavka za koju se nadate da je primijenjena.

Šta prefiks peera bira, a šta ne

AllowedIPs je istovremeno selektor i odobrenje. Govori lokalnoj strani koja odredišta smiju ići ovom peeru, a prijemnoj strani govori koje izvorne adrese ovaj peer smije predstavljati. To je cijeli posao. Ništa u tom opisu ne stvara rutu na hostu, ne uključuje prosljeđivanje na udaljenoj strani i ne dira razrješavanje imena.

Zato konfiguracija može izgledati potpuna i ponašati se kao split tunel. Prefiks kaže da bi peer prihvatio sve; tabela rutiranja hosta odlučuje šta stvarno stigne tamo, a gateway odlučuje da li nešto izlazi. Nijedna od te tri odluke ne živi u peer sekciji.

Rutirati klijenta, ne samo listu peera

Menadžeri kao što je wg-quick programiraju tabelu rutiranja hosta umjesto vas, zato se dvije identične konfiguracijske datoteke ponašaju različito ovisno o tome kako je interfejs podignut. Minimalni profil je dovoljno kratak da se pročita u jednom dahu:

[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

Dva detalja nose posao. Polje Address je jedan prefiks hosta, a ne podmreža za koju klijent misli da je posjeduje, i upravo menadžer pretvara zadani AllowedIPs u stvarnu zadanu rutu. Podignite istu datoteku pomoću ip link i wg setconf i nikakve rute se neće pojaviti, što izgleda kao pokvaren tunel, a zapravo je zdrav tunel s preskočenim korakom rutiranja. Priručnik wg-quick dokumentira rutiranje i Table ponašanje koje ti menadžeri dodaju.

Čitajte rezultat, a ne datoteku: ip route get 1.1.1.1 treba imenovati interfejs tunela, a wg show treba prikazati nedavni handshake s brojačem prijenosa koji se kreće. Handshake bez rute znači da menadžer nikada nije pokrenut, i ponovno uređivanje profila to neće popraviti. Pokrenite interfejs onako kako će ga korisnik pokrenuti, inače test mjeri vaš shell umjesto implementacije.

Držati endpoint izvan tunela

Puni tunel hvata svako odredište, uključujući ono s kojim mora razgovarati da bi postojalo. Menadžeri to rješavaju dodavanjem host rute za endpoint kroz originalni gateway, zato ispravna konfiguracija gotovo uvijek sadrži jedan namjerni izuzetak. Primjena polovine konfiguracije menadžerom, a druge polovine ručno, uobičajen je način da taj izuzetak nestane.

Ako je endpoint ime hosta koje se razrješava na nekoliko adresa, ili na porodicu koju ne nosite, izuzetak loše stari i tunel može pasti nakon ponovnog povezivanja koje je izgledalo rutinski. Prikujte endpoint na adresu koju kontrolišete, ili potvrdite da ga menadžer ponovo procjenjuje, i ponovo pročitajte host rutu nakon svake promjene mreže.

Isti mehanizam objašnjava zašto se puni tunel i captive portal bore. Portal očekuje da presretne saobraćaj koji vaš tunel sada hvata, pa na hotelskim i aerodromskim mrežama tunel dižete nakon prijave na portal, nikada prije.

Prosljeđivanje i povratni put na gatewayu

Na gatewayu uključite prosljeđivanje za porodicu koju nosite, dozvolite forward lanac u oba smjera kada prevodite, i potvrdite povratni put pretragom specifičnom za izvor. Ništa od toga ne slijedi iz uspješnog handshakea, jer handshake samo dokazuje da dva peera mogu razmijeniti UDP. Ne govori ništa o tome šta se poslije dešava s dekapsuliranim paketom.

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

Pretraga se izvodi na gatewayu, a ne na klijentu, inače ćete čitati drugu tabelu rutiranja. Ako imenuje pogrešan interfejs ili prijavi da nema rute, tada nijedna promjena na strani klijenta neće proizvesti izlaz na internet. Kada gateway prevodi adrese klijenata na izlazu, odgovor zavisi od tog stanja prevođenja, pa pravilo mora postojati za oba smjera toka, a ne samo za odlazni.

DNS i stanje kvara, testirani odvojeno

Sam protokol ne konfiguriše resolver nijedne aplikacije. wg-quick primjenjuje liniju DNS kroz integraciju resolvera distribucije, kontejneri i preglednici s vlastitim stekovima to mogu ignorisati, i ime zato može pasti dok tunel savršeno nosi pakete. Testirajte imenom hosta, a ne adresom, i zabilježite koji je server odgovorio umjesto da pretpostavite da je to onaj iz profila.

Porodice adresa su odvojen test s odvojenim odgovorom. Zadana ruta v4 ne govori ništa o tome šta će uraditi v6 veza neke aplikacije, a tunel koji tiho propušta drugu porodicu gori je od onog koji glasno pada. Pitajte ime preko svake porodice, pročitajte interfejs koji je svaki zahtjev koristio, i provjerite brojače prevođenja prije i poslije, jer pravilo koje se ni s čim ne poklapa izgleda isto kao pravilo koje nedostaje.

Konačno, testirajte stanje koje želite kada se tunel zaustavi. Puni tunel treba pasti zatvoreno za saobraćaj koji tvrdi: ako interfejs padne, a aplikacije tiho nastave preko fizičke veze, dizajn je split tunel s dodatnim koracima. Zapišite predviđeno ponašanje pri kvaru, provjerite ga namjerno, i završite tako što ćete zabilježiti četiri odgovora — koji menadžer podiže interfejs, koja ruta nosi zadanu, ko prosljeđuje i prevodi na gatewayu, i koji resolver odgovara.