UFW slipper DNS-tjeneren til VPN-en når tunnelen er oppe

Navn slutter å løses i det øyeblikket VPN-en kobler til, mens en ping til en offentlig adresse fortsatt svarer og brannmurstatusen ikke viser noe som ser galt ut. Ingenting er endret i policyen; det som er endret, er at et nytt grensesnitt har dukket opp, og standardavvisningen dekker det fra første pakke. UFW avgjør etter retning og grensesnitt, så en regel skrevet for den trådløse forbindelsen sier ingenting om trafikk som forlater tunnelen. Reparasjonen er en håndfull smale regler brukt i en bestemt rekkefølge.

Symptomet vises først når tunnelen er oppe

En standardavvisningspolicy gjør nøyaktig det den er bedt om: alt uten en samsvarende regel avvises, på hvert grensesnitt som finnes. Tunnelen fantes ikke da reglene ble skrevet, så ingen av dem kan treffe den, og avvisningen som alltid var der, gjelder nå for navneoppslag. Direkte trafikk til en bokstavelig adresse kan fortsatt virke når en bredere tillatelse dekker den, og derfor lykkes en ping til en offentlig resolver mens et navneoppslag feiler. Hullet er en regel for et grensesnitt som policyen aldri har sett.

Det forklarer også hvorfor feilen snur rent tilbake: fjern tunnelen, og navn løses igjen, fordi spørringen går tilbake til et grensesnitt som har regler. En policy som bare feiler mens tunnelen er oppe, er ikke et DNS-problem, og å justere resolveren selv kaster bort mest tid her. Les grensesnittlisten før du leser resolver-konfigurasjonen.

Tre retninger, tre ulike regelsett

Én økt berører regler i mer enn én retning, og en tunnel legger til et andre grensesnitt på nesten alle av dem. Å sortere trafikken etter retning og grensesnitt først gjør resten mekanisk, fordi hver rad nedenfor trenger sin egen regel på sin egen plass. Eksemplene bruker tun0 og en pool på 10.8.0.0/24, så bytt ut navnene og områdene med dem fra klientens egen utskrift.

To rader forveksles ofte fordi begge nevner tunnelen. En regel for resolveren tillater trafikk klienten sender inn i tunnelen, mens en regel for SSH tillater trafikk serveren mottar derfra; de lever på forskjellige maskiner og feiler uavhengig. Raden som oftest glemmes er den andre, fordi klienten ikke kan bygge tunnelen i det hele tatt før trafikken dens til serverens offentlige adresse er tillatt. Arbeid fra topp til bunn, og hver feil har én mulig årsak.

En skjøvet resolver trenger sin egen regel

Om tunnelen bærer DNS avhenger av hva serveren sender. En server som skyver et resolver-alternativ, installerer en privat adresse i klientens konfigurasjon, og den adressen kan bare rutes gjennom tunnelen. Hvis serveren ikke skyver noe, beholder klienten resolveren den allerede hadde, og reglene nedenfor har ingenting å tillate. Sjekk den skjøvede tilstanden og gjeldende spørringsresultat før du skriver noe:

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

Statusutskriften navngir resolveren som brukes og forbindelsen den er bundet til, og rutesøket bak viser hvilket grensesnitt som ville bære en spørring til den adressen. Når resolveren sitter på en annen forbindelse, er problemet tidligere enn brannmuren, og ingen regel vil hjelpe. Når begge er enige om tunnelen, trengs to regler, fordi UDP bærer de fleste spørringene og TCP tar over når et svar blir avkortet. Noter begge verdiene, fordi det er dem reglene vil navngi:

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'

Åpne den ytre veien før den indre

Klienten må nå serverens offentlige adresse før en tunnel finnes, så regelen for den sitter på den fysiske forbindelsen og må være på plass først. En policy som tillater resolveren men glemmer serveren, lar klienten være helt ute av stand til å bygge tunnelen, og det symptomet får vanligvis skylden på en kill switch. Tillat deretter tjenestene du faktisk ville ha gjennom tunnelen, én smal regel av gangen, i stedet for å åpne grensesnittet helt. De smale reglene er grunnen til at avvisningen kan bli stående.

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'

Rekkefølgen betyr noe mens du tester, fordi den første regelen er det som i det hele tatt lar tunnelen komme opp. Legg den til, koble til, og bekreft at tunnelen er oppe før du legger til tjenesteregelen, fordi å gjøre begge på én gang betyr at en feil ikke forteller deg hvilken halvdel som er feil. Bytt ut dokumentasjonsadressen ovenfor med endepunktet klienten er konfigurert for.

Fullfør klientsiden ved å koble fra med vilje. Avvisningen bør fortsatt avvise trafikken du med vilje utelukket, fordi en resolver som svarer mens tunnelen er oppe bare dekker halvparten av en policy som avviser ved tvil.

En klient som kobler til er ennå ikke sluppet inn

Serveren har sin egen retning å ta hensyn til, og en klient som fullfører håndtrykket når fortsatt ingenting som kjører på serveren før serveren slipper den inn. Regelen for den offentlige lytteren lar tunnelen bare eksistere; den slipper ikke trafikken til tunnelen inn. På serveren er det to regler pluss én sjekk på at tjenesten faktisk lytter:

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å være lik området serveren tildeler, og tunnelnummeret må samsvare med det serveren opprettet, fordi en regel for et annet grensesnitt ikke kan skilles fra ingen regel. limit er med vilje for en administrativ port, fordi det struper gjentatte tilkoblinger i stedet for å tillate dem ubegrenset. Lytter-sjekken skiller en lukket port fra en droppet pakke, som ser identiske ut fra klienten. Numregerte regler er heller ikke hele bildet: UFWs before-regler og alle håndskrevne nftables-linjer treffer tidligere og kan fortsatt avvise en pakke som listen ser ut til å tillate.