UFW dropper VPN'ets DNS-server, når tunnelen er oppe

Navne holder op med at slå op i det øjeblik, VPN'et forbinder, mens et ping til en offentlig adresse stadig svarer, og firewall-status ikke viser noget, der ser forkert ud. Intet er ændret i politikken; det, der er ændret, er, at en ny grænseflade er dukket op, og standardafvisningen dækker den fra den første pakke. UFW afgør efter retning og grænseflade, så en regel skrevet til det trådløse link siger intet om trafik, der forlader tunnelen. Rettelsen er en håndfuld smalle regler anvendt i en bestemt rækkefølge.

Symptomet viser sig først, når tunnelen er oppe

En standardafvisningspolitik gør præcis, hvad den har fået besked på: alt uden en matchende regel afvises, på hver grænseflade, der findes. Tunnelen fandtes ikke, da reglerne blev skrevet, så ingen af dem kan matche den, og den afvisning, der altid var der, gælder nu for navneopslag. Direkte trafik til en litteral adresse kan stadig virke, når en bredere tilladelse dækker den, og derfor lykkes et ping til en offentlig resolver, mens et navneopslag fejler. Hullet er en regel for en grænseflade, som politikken aldrig har set.

Det forklarer også, hvorfor fejlen vender rent tilbage: fjern tunnelen, og navne slår op igen, fordi forespørgslen vender tilbage til en grænseflade, der har regler. En politik, der kun fejler, mens tunnelen er oppe, er ikke et DNS-problem, og at justere resolveren selv spilder mest tid her. Læs grænsefladelisten, før du læser resolver-konfigurationen.

Tre retninger, tre forskellige regelsæt

En enkelt session rører regler i mere end én retning, og en tunnel tilføjer en anden grænseflade til næsten hver af dem. At sortere trafikken efter retning og grænseflade først gør resten mekanisk, fordi hver række nedenfor kræver sin egen regel på sit eget sted. Eksemplerne bruger tun0 og en pulje på 10.8.0.0/24, så indsæt navnene og intervallerne fra klientens eget output.

To rækker forveksles ofte, fordi begge nævner tunnelen. En regel for resolveren tillader trafik, som klienten sender ind i tunnelen, mens en regel for SSH tillader trafik, som serveren modtager derfra; de bor på forskellige maskiner og fejler uafhængigt. Den række, der oftest glemmes, er den anden, fordi klienten slet ikke kan etablere tunnelen, før dens trafik til serverens offentlige adresse er tilladt. Arbejd fra top til bund, og hver fejl har én mulig årsag.

En skubbet resolver kræver sin egen regel

Om tunnelen bærer DNS afhænger af, hvad serveren sender. En server, der skubber en resolver-indstilling, installerer en privat adresse i klientens konfiguration, og den adresse kan kun routes gennem tunnelen. Hvis serveren ikke skubber noget, beholder klienten den resolver, den allerede havde, og reglerne nedenfor har intet at tillade. Kontroller den skubbede tilstand og det aktuelle forespørgselsresultat, før du skriver noget:

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

Statusoutputtet angiver den resolver, der bruges, og det link, den er bundet til, og det ruteopslag, der ligger bag, viser, hvilken grænseflade der ville bære en forespørgsel til den adresse. Når resolveren sidder på et andet link, er problemet tidligere end firewallen, og ingen regel vil hjælpe. Når begge er enige om tunnelen, er der brug for to regler, fordi UDP bærer de fleste forespørgsler, og TCP tager over, når et svar afkortes. Noter begge værdier, fordi det er dem, reglerne vil henvise til:

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'

Åbn den ydre vej før den indre

Klienten skal nå serverens offentlige adresse, før en tunnel findes, så reglen for den sidder på det fysiske link og skal være på plads først. En politik, der tillader resolveren men glemmer serveren, efterlader klienten ude af stand til at bygge tunnelen, og det symptom får normalt skylden på en kill switch. Tillad derefter de tjenester, du faktisk ville have gennem tunnelen, én smal regel ad gangen, i stedet for at åbne grænsefladen helt. De smalle regler er grunden til, at afvisningen kan blive 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'

Rækkefølgen betyder noget, mens du tester, fordi den første regel er det, der overhovedet lader tunnelen komme op. Tilføj den, forbind, og bekræft, at tunnelen er oppe, før du tilføjer tjenestereglen, fordi at gøre begge dele på én gang betyder, at en fejl ikke fortæller dig, hvilken halvdel der er forkert. Erstat dokumentationsadressen ovenfor med det endepunkt, klienten er konfigureret til at bruge.

Afslut klientsiden ved at afbryde med vilje. Afvisningen bør stadig afvise den trafik, du bevidst har udelukket, fordi en resolver, der svarer, mens tunnelen er oppe, kun dækker halvdelen af en politik, der afviser ved tvivl.

En klient, der forbinder, er endnu ikke lukket ind

Serveren har sin egen retning at tage hensyn til, og en klient, der fuldfører håndtrykket, kan stadig ikke nå noget, der kører på serveren, før serveren lukker den ind. Reglen for den offentlige lytter lader kun tunnelen eksistere; den lukker ikke tunnelens trafik ind. På serveren er det to regler plus ét tjek 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'

Puljen i reglen skal svare til det interval, serveren tildeler, og tunnelnummeret skal matche det, serveren har oprettet, fordi en regel for en anden grænseflade ikke kan skelnes fra ingen regel. limit er bevidst for en administrativ port, fordi det begrænser gentagne forbindelser i stedet for at tillade dem ubegrænset. Lyttertjekket skiller en lukket port fra en droppet pakke, som ser identiske ud fra klienten. Nummererede regler er heller ikke hele billedet: UFW's before-regler og alle håndskrevne nftables-linjer matcher tidligere og kan stadig afvise en pakke, som listen ser ud til at tillade.