Blockerar UFW:s nödstopp din VPN? Tillåt motparten

Du följde checklistan: neka utgående, tillåt tunneln, aktivera ufw. Sedan väntar klienten vid handskakningen och ansluter aldrig, eller den ansluter och ingen sida laddas. Båda felen kommer från samma hål. Regeln som låter tunneln existera saknas, eftersom tunneln inte är ett gränssnitt som dina paket lämnar genom.

Varför ett tillstånd på tun0 först inte matchar något alls

tun0 skapas av klienten efter att en session finns. Datagrammen som bygger den sessionen är vanliga UDP-paket adresserade till leverantören på port 1194, och de lämnar genom wlan0 eller eth0 med den fysiska källadressen. allow out on tun0 matchar bara trafik vars utgående gränssnitt är tun0, så under handskakningen matchar den ingenting alls.

Lägg default deny outgoing ovanpå och de yttre paketen släpps innan gränssnittet ens dyker upp. Klienten försöker igen, får timeout och rapporterar ett TLS- eller handskakningsfel, vilket får folk att leta genom certifikat och MTU medan brandväggen tyst äter upp anslutningen. Regeln som skulle hålla kvar din trafik hindrar den trafiken från att hållas kvar.

Reflexfixen gör läckan permanent. sudo ufw allow out on wlan0, eller att vrida standarden tillbaka till tillåt, får upp tunneln och lämnar maskinen utan nödstopp: nästa gång tunneln faller fortsätter allt över den fysiska adaptern. Jag förlorade en eftermiddag på exakt det paret ändringar innan jag kom på vilket paket jag faktiskt filtrerade.

Vad de två paketmängderna behöver

Din trafik korsar brandväggen två gånger, i två former. Det inre paketet går från tunneladressen och ut genom tun0. Det yttre paketet går från den fysiska adressen till motparten, och det är det enda som syns på tråden. En regel per form:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Byt ut adressen och porten mot dem från din egen profil. WireGuard-motparter svarar vanligtvis på 51820/udp; OpenVPN-profiler som går över TCP 443 behöver den porten i stället. Detaljerna skiljer sig, formen inte: båda reglerna är smala, och tillsammans definierar de de enda destinationer maskinen kan nå medan tunneln ligger nere.

Ordningen är den andra myten. Med rå iptables läser du kedjan uppifrån och ned och resonerar om vilken regel som vinner. ufw är inte ett tunt omslag runt listan du skrev; det kompilerar dina regler till egna kedjor och väljer insättningspunkterna. ufw status skriver ut dem i ufw:s ordning, inte din. När en regel ser ignorerad ut, jämför ufw show added med den kompilerade mängden från iptables -S | grep ufw innan du skriver om något.

Undantaget måste förbli en adress brett

En motpartsregel är bara korrekt så länge den namnger adressen klienten ringer. Leverantörer roterar slutpunkter, och en profil som slår upp ett värdnamn följer en DNS-ändring till en ny adress medan regeln fortsätter peka på den gamla. När en tunnel som fungerat i månader slutar komma upp, jämför adressen i regeln med den klienten letar efter innan du breddar något.

Att bredda till ett helt subnät, eller till varje destination på port 1194, gör politiken åter till en brandvägg med ett hål. Undantaget är nödstoppet; när det väl är brett finns inget kvar att stänga av. Håll det på en enda adress och lämna en kommentar som namnger profilen och leverantören det hör till, för om sex månader kommer adressen att verka godtycklig.

Namnuppslagning förtjänar sin egen rad. Uppslagningen sker innan tunneln finns, över det fysiska gränssnittet, så en strikt neka-utgående-policy kan lämna klienten oförmögen att hitta sin egen server. Tillåt port 53 till adressen för din resolver, eller lös upp en gång och fäst adressen i profilen. Att tillåta DNS på varje gränssnitt är ett beslut, inte en standard.

Bygg policyn innan tunneln behövs

ufw enable tillämpar hela policyn på en gång och laddar om sina kedjor, och att ändra en standardpolicy på en brandvägg som kör laddar också om dem. ufw-handboken varnar för att detta kan släppa befintliga anslutningar som SSH. Därför går kommandona i den här ordningen, med SSH-regeln före aktiveringen och en öppen konsolsession:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset lämnas medvetet utanför det blocket. Det raderar varje regel och inaktiverar brandväggen, och på en fjärrvärd är det den följande aktiveringen som släpper din session. Om du ändå återställer, lägg till SSH-regeln och bekräfta en andra väg tillbaka via en konsol innan du går vidare.

Sekvensen är inte kosmetisk. Regler som läggs till medan ufw kör spolar ingenting, men i samma ögonblick som du vrider en standardpolicy laddas kedjorna om, och en session som den gamla policyn tillät följer med dem. Gör standarderna, tillstånden och aktiveringen i en enda omgång, medan du fortfarande har en väg in som inte beror på maskinen.

Testa det blockerade läget och behåll ångra-kommandot

Ett otestat nödstopp är en gissning. Koppla från klienten med avsikt och försök ladda en sida: det måste misslyckas. Anslut igen och det måste återhämta sig utan att röra en regel. sudo ufw status verbose bekräftar standarderna och loggningsläget, och ufw status numbered visar vilken testregel som ska raderas när den överlever sitt syfte.

Håll det omvända skriptet bredvid det framåtriktade. En maskin med neka-utgående och en död tunnel kan inte ladda ner sin egen reparation, så ångra-kommandot måste ligga på disken och vara läsbart från en konsol:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Kör det när tunneln redan ligger nere och reglerna måste bort, inte som ett rutinsteg. Innan du stänger terminalen ska fyra saker gälla: motpartsregeln namnger exakt en adress, DNS har ett namngivet undantag, aktiveringen kom efter tillstånden, och att dra ur tunneln dödar vanlig trafik utan att döda klienten för gott.