WireGuard-voltonnel: AllowedIPs 0.0.0.0/0 is nie genoeg nie

Om 0.0.0.0/0, ::/0 in 'n peer se AllowedIPs te plaas, is die stap wat almal onthou, en dit bepaal slegs watter verkeer die peer toegelaat word om te dra. Dié voorvoegsels skep geen roetes nie, stuur niks aan die oorkant nie, en laat elke toepassing se resolver presies waar dit was. Vier afsonderlike dinge moet gelyktydig geld vir 'n volle tonnel om 'n volle tonnel te wees, en dit word die beste in die volgorde hieronder nagegaan, want 'n latere kontrole kan nie 'n vroeëre een red nie. Elke kontrole hieronder is 'n feit wat jy van 'n masjien kan aflees, nie 'n instelling wat jy hoop toegepas is nie.

Wat die peer-voorvoegsel kies, en wat nie

AllowedIPs is tegelyk 'n kieser en 'n magtiger. Dit sê vir die plaaslike kant watter bestemmings na dié peer gestuur mag word, en dit sê vir die ontvangende kant watter bronadresse dié peer mag voorhou. Dit is die hele taak. Niks in daardie beskrywing skep 'n roete op die gasheer nie, aktiveer nie aanstuur aan die oorkant nie, of raak aan naamoplossing nie.

Dit is waarom 'n konfigurasie volledig kan lyk en soos 'n gesplete tonnel kan optree. Die voorvoegsel sê die peer sou alles aanvaar; die gasheer se roetetabel besluit wat werklik daar aankom, en die gateway besluit of enigiets vertrek. Nie een van daardie drie besluite woon in die peer-blok nie.

Roeteer die kliënt, nie net die peer-lys nie

Bestuurders soos wg-quick programmeer die gasheer se roetetabel vir jou, en daarom tree twee identiese konfigurasielêers anders op na gelang van hoe die koppelvlak opgekom het. 'n Minimale profiel is kort genoeg om in een slag te lees:

[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

Twee besonderhede dra die werk. Die Address is 'n enkele gasheervoorvoegsel eerder as 'n subnet wat die kliënt glo hy besit, en dit is die bestuurder wat die verstek-AllowedIPs in 'n werklike verstekroete omskakel. Bring dieselfde lêer op met ip link en wg setconf en daar verskyn glad geen roetes nie, wat soos 'n stukkende tonnel lyk en 'n gesonde een is met die roetestap oorgeslaan. Die wg-quick-handleiding dokumenteer die roetering en Table gedrag wat daardie bestuurders byvoeg.

Lees die resultaat eerder as die lêer: ip route get 1.1.1.1 behoort die tonnelkoppelvlak te noem, en wg show behoort 'n onlangse handdruk met 'n oordragteller wat beweeg te rapporteer. 'n Handdruk sonder 'n roete beteken die bestuurder het nooit geloop nie, en die profiel weer wysig sal dit nie regmaak nie. Begin die koppelvlak soos die gebruiker dit sal begin, of die toets meet jou dop eerder as die ontplooiing.

Hou die eindpunt buite die tonnel

'n Volle tonnel vang elke bestemming, insluitend die een waarmee hy moet praat om te bestaan. Bestuurders hanteer dit deur 'n gasheerroete vir die eindpunt via die oorspronklike gateway by te voeg, en daarom bevat 'n korrekte konfigurasie byna altyd een doelbewuste uitsondering. Om die helfte van die konfigurasie met 'n bestuurder en die ander helfte met die hand toe te pas, is die gewone manier waarop hierdie uitsondering wegraak.

As die eindpunt 'n gasheernaam is wat na verskeie adresse oplos, of na 'n familie wat jy nie dra nie, verouder die uitsondering sleg en kan die tonnel faal ná 'n herverbinding wat roetine gelyk het. Pen die eindpunt vas aan 'n adres wat jy beheer, of bevestig dat die bestuurder dit herevalueer, en lees die gasheerroete weer na elke netwerkverandering.

Dieselfde meganisme verduidelik waarom 'n volle tonnel en 'n captive portal stry. Die portaal verwag om die verkeer te onderskep wat jou tonnel nou vang, so op hotel- en lughawenetwerke bring jy die tonnel op ná die portaal-aanmelding, nooit voor dit nie.

Aanstuur en die antwoordpad op die gateway

Op die gateway, aktiveer aanstuur vir die familie wat jy dra, laat die forward-ketting in beide rigtings toe wanneer jy vertaal, en bevestig die terugpad met 'n bron-spesifieke opsoek. Niks daarvan volg uit 'n suksesvolle handdruk nie, want 'n handdruk bewys net dat die twee peers UDP kan uitruil. Dit sê niks oor wat daarna met die gedekapsuleerde pakket gebeur nie.

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

Die opsoek loop op die gateway eerder as op die kliënt, anders lees jy 'n ander roetetabel. As dit die verkeerde koppelvlak noem, of geen roete rapporteer nie, dan sal geen kliëntkant-verandering 'n internetuitgang lewer nie. Wanneer die gateway kliëntadresse op pad uit vertaal, hang die antwoord van daardie vertaalingtoestand af, so die reël moet vir beide rigtings van die vloei bestaan en nie net die uitgaande een nie.

DNS en die fouttoestand, apart getoets

Die protokol self konfigureer geen toepassing se resolver nie. wg-quick pas die DNS reël toe via die distribusie se resolver-integrasie, houers en blaaiers met hul eie stapels mag dit ignoreer, en 'n naam kan dus faal terwyl die tonnel pakkette perfek dra. Toets met 'n gasheernaam eerder as 'n adres, en let op watter bediener geantwoord het in plaas daarvan om te aanvaar dat die een in die profiel dit gedoen het.

Adresfamilies is 'n aparte toets met 'n aparte antwoord. 'n v4-verstek sê niks oor wat 'n toepassing se v6-verbinding gaan doen nie, en 'n tonnel wat die tweede familie stilweg lek, is slegter as een wat hardop faal. Vra 'n naam oor elke familie, lees die koppelvlak wat elke versoek gebruik het, en kontroleer vertaaltellers voor en ná, want 'n reël wat niks pas nie, lyk identies aan 'n reël wat ontbreek.

Toets laastens die toestand wat jy wil hê wanneer die tonnel stop. 'n Volle tonnel behoort geslote te faal vir die verkeer wat hy opeis: as die koppelvlak afgaan en toepassings stilweg oor die fisiese skakel voortgaan, is die ontwerp 'n gesplete tonnel met ekstra stappe. Skryf die bedoelde foutgedrag neer, kontroleer dit doelbewus, en eindig deur die vier antwoorde vas te lê — watter bestuurder bring die koppelvlak op, watter roete dra die verstek, wie stuur aan en vertaal by die gateway, en watter resolver antwoord.