UFW slepp DNS-tenaren til VPN-en når tunnelen er oppe

Namn sluttar å løysast i det augneblinken VPN-en koplar til, medan ein ping til ein offentleg adresse framleis svarar og brannmurstatusen ikkje viser noko som ser gale ut. Ingenting er endra i policyen; det som er endra, er at eit nytt grensesnitt har dukka opp, og standardavvisinga dekkjer det frå første pakke. UFW avgjer etter retning og grensesnitt, så ein regel skriven for den trådlause sambandet seier ingenting om trafikk som forlèt tunnelen. Reparasjonen er ei handfull smale reglar brukte i ein bestemt rekkjefølgje.

Symptomet viser seg først når tunnelen er oppe

Ein standardavvisingspolicy gjer nøyaktig det han er bedd om: alt utan ein samsvarande regel blir avvist, på kvart grensesnitt som finst. Tunnelen fanst ikkje då reglane vart skrivne, så ingen av dei kan treffa han, og avvisinga som alltid var der, gjeld no for namneoppslag. Direkte trafikk til ei bokstaveleg adresse kan framleis verka når ei breiare løyve dekkjer henne, og difor lykkast ein ping til ein offentleg resolver medan eit namneoppslag feilar. Holet er ein regel for eit grensesnitt som policyen aldri har sett.

Det forklarar òg kvifor feilen snur reint tilbake: fjern tunnelen, og namn løysast igjen, fordi spørjinga går tilbake til eit grensesnitt som har reglar. Ein policy som berre feilar medan tunnelen er oppe, er ikkje eit DNS-problem, og å justera resolveren sjølv kastar bort mest tid her. Les grensesnittlista før du les resolver-konfigurasjonen.

Tre retningar, tre ulike regelsett

Éi økt rører reglar i meir enn éi retning, og ein tunnel legg til eit andre grensesnitt på nesten alle av dei. Å sortera trafikken etter retning og grensesnitt først gjer resten mekanisk, fordi kvar rad nedanfor treng si eiga regel på sin eigen plass. Døma brukar tun0 og ein pool på 10.8.0.0/24, så byt ut namna og områda med dei frå klienten si eiga utskrift.

To rader blir ofte forveksla fordi begge nemner tunnelen. Ein regel for resolveren lèt gjennom trafikk klienten sender inn i tunnelen, medan ein regel for SSH lèt gjennom trafikk tenaren mottek derfrå; dei lever på ulike maskinar og feilar uavhengig. Rada som oftast blir gløymd er den andre, fordi klienten ikkje kan byggja tunnelen i det heile før trafikken hans til den offentlege adressa til tenaren er løyvd. Arbeid frå topp til botn, og kvar feil har éin mogleg årsak.

Ein skuva resolver treng sin eigen regel

Om tunnelen ber DNS avheng av kva tenaren sender. Ein tenar som skuvar eit resolver-alternativ, installerer ei privat adresse i konfigurasjonen til klienten, og den adressa kan berre rutast gjennom tunnelen. Viss tenaren ikkje skuvar noko, held klienten på resolveren han allereie hadde, og reglane nedanfor har ingenting å løyva. Sjekk den skuva tilstanden og gjeldande spørjeresultat før du skriv noko:

dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numbered

Statusutskrifta nemner resolveren som blir brukt og sambandet han er bunden til, og rutesøket bak viser kva grensesnitt som ville bera ei spørjing til den adressa. Når resolveren sit på eit anna samband, er problemet tidlegare enn brannmuren, og ingen regel vil hjelpa. Når begge er samde om tunnelen, trengst to reglar, fordi UDP ber dei fleste spørjingane og TCP tek over når eit svar blir avkorta. Noter begge verdiane, fordi det er dei reglane vil nemna:

sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'

Opne den ytre vegen før den indre

Klienten må nå den offentlege adressa til tenaren før ein tunnel finst, så regelen for henne sit på det fysiske sambandet og må vera på plass fyrst. Ein policy som lèt gjennom resolveren men gløymer tenaren, lèt klienten vera heilt ute av stand til å byggja tunnelen, og det symptomet får vanlegvis skulda for ein kill switch. Lêt så gjennom tenestene du faktisk ville ha gjennom tunnelen, éin smal regel om gongen, i staden for å opna grensesnittet heilt. Dei smale reglane er grunnen til at avvisinga kan bli ståande.

sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'

Rekkjefølgja betyr noko medan du testar, fordi den første regelen er det som i det heile lèt tunnelen koma opp. Legg han til, kople til, og stadfest at tunnelen er oppe før du legg til tenesteregelen, fordi å gjera begge på ein gong betyr at ein feil ikkje fortel deg kva halvdel som er feil. Byt ut dokumentasjonsadressa ovanfor med endepunktet klienten er konfigurert for.

Fullfør klientsida ved å kople frå med vilje. Avvisinga bør framleis avvisa trafikken du med vilje utelukka, fordi ein resolver som svarar medan tunnelen er oppe berre dekkjer halvparten av ein policy som avviser ved tvil.

Ein klient som koplar til er enno ikkje sleppt inn

Tenaren har si eiga retning å ta omsyn til, og ein klient som fullfører handtrykket når framleis ingenting som køyrer på tenaren før tenaren slepp han inn. Regelen for den offentlege lyttaren lèt tunnelen berre eksistera; han slepp ikkje trafikken til tunnelen inn. På tenaren er det to reglar pluss éin sjekk på at tenesta faktisk lyttar:

sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'

Poolen i regelen må vera lik området tenaren tildeler, og tunnelnummeret må samsvara med det tenaren oppretta, fordi ein regel for eit anna grensesnitt ikkje kan skiljast frå ingen regel. limit er med vilje for ein administrativ port, fordi det strypar gjentekne tilkoplingar i staden for å løyva dei ubegrensa. Lyttar-sjekken skil ein lukka port frå ein droppa pakke, som ser identiske ut frå klienten. Nummererte reglar er heller ikkje heile biletet: before-reglane til UFW og alle handskrivne nftables-linjer treff tidlegare og kan framleis avvisa ein pakke som lista ser ut til å løyva.