WireGuard täistunnel: AllowedIPs 0.0.0.0/0 ei ole piisav

Panna 0.0.0.0/0, ::/0 peeri AllowedIPs-i on samm, mille kõik jätavad meelde, ja see otsustab ainult, millist liiklust peeril on lubatud kanda. Need eesliited ei loo ühtegi marsruuti, ei edasta midagi teisel pool ega puuduta rakenduste nimeresolverit. Neli eraldi asja peavad kehtima korraga, et täistunnel oleks täistunnel, ja neid on kõige parem kontrollida allolevas järjekorras, sest hilisem kontroll ei päästa varasemat. Iga allolev kontroll on fakt, mille saab masinast välja lugeda, mitte säte, mille rakendamist sa loodad.

Mida peeri eesliide valib ja mida mitte

AllowedIPs on korraga valija ja volitaja. See ütleb kohalikule poolele, milliseid sihtkohti tohib sellele peerile saata, ja vastuvõtvale poolele, milliseid lähteaadresse tohib see peer esitada. See ongi kogu töö. Miski selles kirjelduses ei loo hostis marsruuti, ei luba edastamist kaugemal poolel ega puuduta nimede lahendamist.

Seepärast võib konfiguratsioon tunduda täielik ja käituda nagu split-tunnel. Eesliide ütleb, et peer võtaks vastu kõik; hosti marsruutimistabel otsustab, mis sinna tegelikult jõuab, ja lüüs otsustab, kas midagi välja läheb. Ükski neist kolmest otsusest ei ela peeri plokis.

Marsruutida klienti, mitte ainult peeride nimekirja

Haldurid nagu wg-quick programmeerivad hosti marsruutimistabeli sinu eest, mistõttu kaks identset konfiguratsioonifaili käituvad erinevalt sõltuvalt sellest, kuidas liides üles tuli. Minimaalne profiil on piisavalt lühike, et ühe hooga läbi lugeda:

[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

Tööd kannavad kaks detaili. Väli Address on üks hosti eesliide, mitte alamvõrk, mille klient arvab endale kuuluvat, ja just haldur muudab vaikimisi AllowedIPs-i tõeliseks vaikimisi marsruudiks. Too sama fail üles käsuga ip link ja wg setconf ning ükski marsruut ei ilmugi, mis näeb välja nagu katkine tunnel ja on tegelikult terve tunnel, mille marsruudisamm on vahele jäetud. wg-quick käsiraamat dokumenteerib marsruutimise ja Table käitumise, mille need haldurid lisavad.

Loe tulemust, mitte faili: ip route get 1.1.1.1 peaks nimetama tunneli liidese ja wg show peaks näitama hiljutist handshake’i liikuva ülekandeloenduriga. Handshake ilma marsruudita tähendab, et haldur ei jooksnud kunagi, ja profiili uuesti muutmine ei paranda seda. Käivita liides nii, nagu kasutaja selle käivitab, muidu mõõdab test sinu shelli, mitte juurutust.

Hoida otspunkt tunnelist väljas

Täistunnel püüab iga sihtkoha, sealhulgas selle, millega ta peab rääkima, et eksisteerida. Haldurid lahendavad selle, lisades otspunktile hosti marsruudi algse lüüsi kaudu, mistõttu õige konfiguratsioon sisaldab peaaegu alati ühte teadlikku erandit. Konfiguratsiooni poole rakendamine halduriga ja teise poole käsitsi on tavaline viis, kuidas see erand kaob.

Kui otspunkt on hostinimi, mis lahendub mitmeks aadressiks või perekonnaks, mida sa ei kanna, vananeb erand halvasti ja tunnel võib pärast rutiinsena näinud taasühendust ebaõnnestuda. Kinnita otspunkt aadressile, mida kontrollid, või kinnita, et haldur hindab selle uuesti üle, ja loe hosti marsruut uuesti pärast iga võrgu muutust.

Sama mehhanism selgitab, miks täistunnel ja captive portal kaklevad. Portal ootab sinu tunneli nüüd püütava liikluse püüdmist, seega hotelli- ja lennujaamavõrkudes tõstad tunneli üles pärast portaali sisselogimist, mitte kunagi enne.

Edastamine ja tagasitee lüüsil

Lüüsil luba edastamine perekonnale, mida kannad, luba forward-ahel mõlemas suunas, kui tõlgid, ja kinnita tagasitee allikapõhise otsinguga. Miski sellest ei tulene õnnestunud handshake’ist, sest handshake tõestab ainult, et kaks peeri saavad UDP-d vahetada. See ei ütle midagi selle kohta, mis juhtub dekapsuleeritud paketiga hiljem.

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

Otsing jookseb lüüsil, mitte kliendil, muidu loed teist marsruutimistabelit. Kui see nimetab vale liidese või teatab, et marsruuti pole, siis ei anna ükski kliendipoolne muudatus interneti väljapääsu. Kui lüüs tõlgib kliendi aadresse väljumisel, sõltub vastus sellest tõlkeolekust, seega peab reegel eksisteerima mõlemas voolu suunas, mitte ainult väljuvas.

DNS ja tõrkeolek, eraldi testituna

Protokoll ise ei seadista ühegi rakenduse resolverit. wg-quick rakendab rea DNS distributsiooni resolveri integratsiooni kaudu, konteinerid ja brauserid oma virnadega võivad selle ignoreerida, ja seetõttu võib nimi ebaõnnestuda, samal ajal kui tunnel kannab pakette ideaalselt. Testi hostinimega, mitte aadressiga, ja pane kirja, milline server vastas, selle asemel et eeldada, et seda tegi profiilis olev.

Aadressiperekonnad on eraldi test eraldi vastusega. v4 vaikimisi marsruut ei ütle midagi selle kohta, mida rakenduse v6 ühendus teeb, ja tunnel, mis teist perekonda vaikselt lekitab, on hullem kui see, mis lärmakalt ebaõnnestub. Küsi nime iga perekonna kaudu, loe liides, mida iga päring kasutas, ja kontrolli tõlkeloendureid enne ja pärast, sest reegel, mis millegagi ei sobitu, näeb välja täpselt nagu puuduv reegel.

Lõpuks testi olekut, mida soovid, kui tunnel peatub. Täistunnel peaks oma väidetud liikluse jaoks ebaõnnestuma suletult: kui liides langeb ja rakendused jätkavad vaikselt füüsilise lingi kaudu, on disain split-tunnel lisasammudega. Kirjuta kavatsetud tõrkekäitumine üles, kontrolli seda meelega ja lõpeta nelja vastuse kirjapanemisega — milline haldur liidese üles toob, milline marsruut kannab vaikimisi, kes edastab ja tõlgib lüüsil, ja milline resolver vastab.