Poln tunel WireGuard: AllowedIPs 0.0.0.0/0 ni dovolj

Vpis 0.0.0.0/0, ::/0 v AllowedIPs partnerja je korak, ki se ga vsi spomnijo, in odloča le o tem, kateri promet sme partner prenašati. Te predpone ne ustvarijo nobene poti, na drugi strani ničesar ne posredujejo in pustijo resolver vsake aplikacije točno tam, kjer je bil. Štiri ločene stvari morajo veljati hkrati, da je poln tunel res poln, in najbolje jih je preveriti v spodnjem vrstnem redu, ker poznejše preverjanje ne more rešiti prejšnjega. Vsako preverjanje spodaj je dejstvo, ki ga je mogoče prebrati s stroja, ne nastavitev, za katero upate, da je bila uporabljena.

Kaj izbere predpona partnerja in kaj ne

AllowedIPs je hkrati izbirnik in dovoljenje. Lokalni strani pove, kateri cilji se smejo pošiljati temu partnerju, sprejemni strani pa, katere izvorne naslove sme ta partner predstaviti. To je vse delo. Nič v tem opisu ne ustvari poti na gostitelju, ne vklopi posredovanja na oddaljeni strani in se ne dotakne razreševanja imen.

Zato se konfiguracija lahko zdi popolna in se obnaša kot razdeljen tunel. Predpona pravi, da bi partner sprejel vse; usmerjevalna tabela gostitelja odloči, kaj v resnici prispe tja, prehod pa odloči, ali kaj odide. Nobena od teh treh odločitev ne živi v razdelku partnerja.

Usmerjati odjemalca, ne le seznama partnerjev

Upravitelji, kot je wg-quick programirajo usmerjevalno tabelo gostitelja namesto vas, zato se dve enaki konfiguracijski datoteki obnašata različno glede na to, kako se je vmesnik dvignil. Najmanjši profil je dovolj kratek, da ga preberete na en mah:

[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

Delo nosita dve podrobnosti. Polje Address je ena predpona gostitelja in ne podomrežje, za katero odjemalec misli, da ga ima, in prav upravitelj pretvori privzete AllowedIPs v pravo privzeto pot. Dvignite isto datoteko z ip link in wg setconf in ne bo se pojavila nobena pot, kar je videti kot pokvarjen tunel, v resnici pa je zdrav tunel s preskočenim korakom usmerjanja. Priročnik wg-quick dokumentira usmerjanje in Table vedenje, ki ga dodajo ti upravitelji.

Berite rezultat, ne datoteke: ip route get 1.1.1.1 bi moral navesti vmesnik tunela, in wg show bi moral poročati o nedavnem rokovanju s števcem prenosa, ki se premika. Rokovanje brez poti pomeni, da upravitelj ni nikoli tekel, in ponovno urejanje profila tega ne bo popravilo. Zaženite vmesnik tako, kot ga bo zagnal uporabnik, sicer test meri vašo lupino namesto uvedbe.

Ohraniti končno točko zunaj tunela

Poln tunel ujame vsak cilj, tudi tistega, s katerim mora govoriti, da obstaja. Upravitelji to rešujejo tako, da dodajo pot gostitelja za končno točko skozi prvotni prehod, zato pravilna konfiguracija skoraj vedno vsebuje eno namerno izjemo. Uporaba polovice konfiguracije z upraviteljem in druge polovice ročno je običajen način, da se ta izjema izgubi.

Če je končna točka ime gostitelja, ki se razreši v več naslovov ali v družino, ki je ne prenašate, izjema slabo stara in tunel lahko odpove po ponovni povezavi, ki je bila videti rutinska. Pripnite končno točko na naslov, ki ga nadzorujete, ali potrdite, da jo upravitelj ponovno oceni, in po vsaki spremembi omrežja znova preberite pot gostitelja.

Isti mehanizem pojasnjuje, zakaj se poln tunel in ujetniški portal prepirata. Portal pričakuje, da bo prestregel promet, ki ga vaš tunel zdaj lovi, zato v hotelskih in letaliških omrežjih tunel dvignete po prijavi v portal, nikoli prej.

Posredovanje in povratna pot na prehodu

Na prehodu vklopite posredovanje za družino, ki jo prenašate, dovolite verigo forward v obe smeri, ko prevajate, in potrdite povratno pot s poizvedbo, specifično za vir. Nič od tega ne izhaja iz uspešnega rokovanja, ker rokovanje dokazuje le, da si dva partnerja lahko izmenjujeta UDP. Nič ne pove o tem, kaj se nato zgodi z dekapsuliranim paketom.

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

Poizvedba teče na prehodu in ne na odjemalcu, sicer boste brali drugo usmerjevalno tabelo. Če navede napačen vmesnik ali sporoči, da poti ni, potem nobena sprememba na strani odjemalca ne bo ustvarila izhoda v internet. Ko prehod prevaja naslove odjemalcev na izhodu, je odgovor odvisen od tega stanja prevajanja, zato mora pravilo obstajati za obe smeri toka in ne le za odhodno.

DNS in stanje napake, preverjena ločeno

Protokol sam ne nastavi resolverja nobene aplikacije. wg-quick uporabi vrstico DNS prek integracije resolverja distribucije, vsebniki in brskalniki z lastnimi skladi jo lahko ignorirajo, in zato ime lahko odpove, medtem ko tunel brezhibno prenaša pakete. Testirajte z imenom gostitelja in ne z naslovom, ter zabeležite, kateri strežnik je odgovoril, namesto da bi domnevali, da je to storil tisti iz profila.

Družine naslovov so ločen test z ločenim odgovorom. Privzeta pot v4 ne pove nič o tem, kaj bo storila povezava v6 neke aplikacije, in tunel, ki tiho pušča drugo družino, je slabši od tistega, ki glasno odpove. Vprašajte za ime po vsaki družini, preberite vmesnik, ki ga je uporabila vsaka zahteva, in preverite števce prevajanja pred in po, ker je pravilo, ki se ne ujema z ničimer, videti enako kot manjkajoče pravilo.

Nazadnje preizkusite stanje, ki ga želite, ko se tunel ustavi. Poln tunel bi moral odpovedati zaprto za promet, ki ga zahteva: če vmesnik pade in aplikacije tiho nadaljujejo po fizični povezavi, je zasnova razdeljen tunel z dodatnimi koraki. Zapišite predvideno vedenje ob napaki, preverite ga namerno in končajte z zapisom štirih odgovorov — kateri upravitelj dvigne vmesnik, katera pot nosi privzeto, kdo posreduje in prevaja na prehodu ter kateri resolver odgovarja.