UFW kastar bort VPN:ets DNS-server så snart tunneln är uppe

Namn slutar att lösas i samma ögonblick som VPN:en ansluter, medan en ping mot en offentlig adress fortfarande svarar och brandväggsstatusen inte visar något som ser fel ut. Ingenting har ändrats i policyn; det som har ändrats är att ett nytt gränssnitt har dykt upp, och standardavvisningen täcker det från första paketet. UFW avgör efter riktning och gränssnitt, så en regel skriven för den trådlösa länken säger ingenting om trafik som lämnar tunneln. Reparationen är en handfull smala regler tillämpade i en bestämd ordning.

Symtomet visas först när tunneln är uppe

En standardavvisningspolicy gör exakt det den blivit tillsagd: allt utan en matchande regel avvisas, på varje gränssnitt som finns. Tunneln fanns inte när reglerna skrevs, så ingen av dem kan fånga den, och avvisningen som alltid fanns där gäller nu för namnuppslagning. Direkt trafik till en litteral adress kan fortfarande fungera när ett bredare tillstånd täcker den, och det är därför en ping mot en offentlig resolver lyckas medan en namnsökning misslyckas. Gapet är en regel för ett gränssnitt som policyn aldrig har sett.

Det förklarar också varför felet vänds rent: ta bort tunneln och namn löses igen, eftersom frågan återvänder till ett gränssnitt som har regler. En policy som bara misslyckas medan tunneln är uppe är inte ett DNS-problem, och att justera resolvern själv slösar mest tid här. Läs gränssnittslistan innan du läser resolverkonfigurationen.

Tre riktningar, tre olika regeluppsättningar

En enda session berör regler i mer än en riktning, och en tunnel lägger till ett andra gränssnitt på nästan alla av dem. Att sortera trafiken efter riktning och gränssnitt först gör resten mekanisk, eftersom varje rad nedan behöver sin egen regel på sin egen plats. Exemplen använder tun0 och en pool på 10.8.0.0/24, så ersätt namnen och intervallen med dem från klientens egen utskrift.

Två rader förväxlas ofta eftersom båda nämner tunneln. En regel för resolvern tillåter trafik som klienten skickar in i tunneln, medan en regel för SSH tillåter trafik som servern tar emot därifrån; de lever på olika maskiner och misslyckas oberoende. Raden som oftast glöms bort är den andra, eftersom klienten inte alls kan bygga tunneln förrän trafiken till serverns offentliga adress är tillåten. Arbeta uppifrån och ned och varje fel har en möjlig orsak.

En framskjuten resolver behöver sin egen regel

Om tunneln bär DNS beror på vad servern skickar. En server som skjuter fram ett resolveralternativ installerar en privat adress i klientens konfiguration, och den adressen är bara routbar genom tunneln. Om servern inte skjuter fram något behåller klienten resolvern den redan hade, och reglerna nedan har ingenting att tillåta. Kontrollera det framskjutna tillståndet och det aktuella frågeresultatet innan du skriver något:

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

Statusutskriften namnger resolvern som används och länken den är bunden till, och rutsökningen bakom visar vilket gränssnitt som skulle bära en fråga till den adressen. När resolvern sitter på en annan länk är problemet tidigare än brandväggen och ingen regel hjälper. När båda är överens om tunneln behövs två regler, eftersom UDP bär de flesta frågorna och TCP tar över när ett svar trunkeras. Anteckna båda värdena, eftersom det är dem reglerna kommer att namnge:

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'

Öppna den yttre vägen före den inre

Klienten måste nå serverns offentliga adress innan en tunnel finns, så regeln för den sitter på den fysiska länken och måste vara på plats först. En policy som tillåter resolvern men glömmer servern lämnar klienten helt oförmögen att bygga tunneln, och det symtomet skylls oftast på en kill switch. Tillåt sedan tjänsterna du faktiskt ville ha genom tunneln, en smal regel i taget, istället för att öppna gränssnittet helt. De smala reglerna är anledningen till att avvisningen kan stå kvar.

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'

Ordningen spelar roll medan du testar, eftersom den första regeln är det som över huvud taget låter tunneln komma upp. Lägg till den, anslut och bekräfta att tunneln är uppe innan du lägger till tjänsteregeln, eftersom att göra båda samtidigt innebär att ett fel inte säger dig något om vilken halva som är fel. Ersätt dokumentationsadressen ovan med den slutpunkt som klienten är konfigurerad för.

Avsluta klientsidan genom att koppla från med avsikt. Avvisningen bör fortfarande avvisa trafiken du medvetet uteslöt, eftersom en resolver som svarar medan tunneln är uppe bara täcker halva en policy som avvisar vid tvekan.

En klient som ansluter är ännu inte insläppt

Servern har sin egen riktning att ta hänsyn till, och en klient som slutför handskakningen når fortfarande ingenting som körs på servern förrän servern släpper in den. Regeln för den offentliga lyssnaren låter tunneln bara existera; den släpper inte in tunnelns trafik. På servern är det två regler plus en kontroll att tjänsten faktiskt lyssnar:

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 regeln måste vara lika med det intervall servern tilldelar, och tunnelnumret måste matcha det servern skapade, eftersom en regel för ett annat gränssnitt inte går att skilja från ingen regel. limit är avsiktligt för en administrativ port, eftersom det stryper upprepade anslutningar istället för att tillåta dem utan gräns. Lyssnarkontrollen skiljer en stängd port från ett tappat paket, som ser identiska ut från klienten. Numrerade regler är inte heller hela bilden: UFW:s before-regler och alla handskrivna nftables-rader matchar tidigare och kan fortfarande avvisa ett paket som listan verkar tillåta.