Blokkeert de noodschakelaar van UFW je VPN? Sta de peer toe

Je volgde de checklist: uitgaand weigeren, de tunnel toestaan, ufw inschakelen. Dan wacht de client bij de handshake en verbindt nooit, of hij verbindt en er laadt geen pagina. Beide fouten komen uit hetzelfde gat. De regel die de tunnel laat bestaan ontbreekt, omdat de tunnel geen interface is waar je pakketten uit vertrekken.

Waarom een toestemming op tun0 eerst nergens op past

tun0 wordt door de client aangemaakt nadat een sessie bestaat. De datagrammen die die sessie opbouwen zijn gewone UDP-pakketten die aan de provider op poort 1194 zijn geadresseerd, en ze vertrekken via wlan0 of eth0 met het fysieke bronadres. allow out on tun0 past alleen op verkeer waarvan de uitgaande interface tun0 is, dus tijdens de handshake past het op helemaal niets.

Zet default deny outgoing erbovenop en de buitenste pakketten worden weggegooid voordat de interface überhaupt verschijnt. De client probeert opnieuw, loopt in een time-out en meldt een TLS- of handshakefout, wat mensen door certificaten en MTU laat zoeken terwijl de firewall de verbinding stil opvreet. De regel die je verkeer moest indammen, verhindert dat dat verkeer wordt ingedamd.

De reflexmatige fix maakt het lek permanent. sudo ufw allow out on wlan0, of de standaard terugzetten op toestaan, brengt de tunnel omhoog en laat de machine zonder noodschakelaar achter: de volgende keer dat de tunnel valt, gaat alles weer over de fysieke adapter. Ik verloor een middag aan precies dat paar aanpassingen voordat ik uitvogelde welk pakket ik eigenlijk filterde.

Wat de twee pakketsets nodig hebben

Je verkeer kruist de firewall twee keer, in twee vormen. Het binnenste pakket loopt van het tunneladres naar buiten via tun0. Het buitenste pakket loopt van het fysieke adres naar de peer, en dat is het enige dat op de draad zichtbaar is. Eén regel per vorm:

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'

Vervang het adres en de poort door die uit je eigen profiel. WireGuard-peers antwoorden meestal op 51820/udp; OpenVPN-profielen die over TCP 443 gaan hebben die poort nodig in plaats daarvan. De details verschillen, de vorm niet: beide regels zijn smal, en samen bepalen ze de enige bestemmingen die de machine kan bereiken terwijl de tunnel plat ligt.

Volgorde is de tweede mythe. Met ruwe iptables lees je de keten van boven naar beneden en redeneert over welke regel wint. ufw is geen dunne wikkel om de lijst die je typte; het compileert je regels in zijn eigen ketens en kiest de invoegpunten. ufw status drukt ze af in de volgorde van ufw, niet de jouwe. Als een regel genegeerd lijkt, vergelijk ufw show added met de gecompileerde set uit iptables -S | grep ufw voordat je iets herschrijft.

De uitzondering moet één adres breed blijven

Een peer-regel is alleen correct zolang hij het adres noemt dat de client kiest. Providers roteren eindpunten, en een profiel dat een hostnaam oplost volgt een DNS-wijziging naar een nieuw adres terwijl de regel naar het oude blijft wijzen. Als een tunnel die maanden werkte niet meer omhoog komt, vergelijk dan het adres in de regel met dat waar de client naar zoekt voordat je iets verbreedt.

Verbreden naar een heel subnet, of naar elke bestemming op poort 1194, maakt van het beleid weer een firewall met een gat. De uitzondering is de noodschakelaar; zodra die breed is, valt er niets meer om te schakelen. Houd hem op één adres en laat een opmerking achter die het profiel en de provider noemt waartoe hij hoort, want over zes maanden zal het adres willekeurig lijken.

Naamresolutie verdient een eigen regel. De opzoeking gebeurt voordat de tunnel bestaat, over de fysieke interface, dus een strikt uitgaand-weigerbeleid kan de client niet in staat laten zijn zijn eigen server te vinden. Sta poort 53 toe naar het adres van je resolver, of los één keer op en zet het adres vast in het profiel. DNS toestaan op elke interface is een beslissing, geen standaard.

Bouw het beleid voordat de tunnel nodig is

ufw enable past het hele beleid in één keer toe en herlaadt zijn ketens, en het wijzigen van een standaardbeleid op een draaiende firewall herlaadt ze ook. De ufw-handleiding waarschuwt dat dit bestaande verbindingen zoals SSH kan laten vallen. Daarom gaan de commando's in deze volgorde, met de SSH-regel vóór het inschakelen en een open consolesessie:

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 is met opzet buiten dat blok gelaten. Het verwijdert elke regel en schakelt de firewall uit, en op een externe host is het volgende inschakelen wat je sessie laat vallen. Als je toch reset, voeg dan de SSH-regel toe en bevestig een tweede weg terug via een console voordat je verder gaat.

De volgorde is niet cosmetisch. Regels die worden toegevoegd terwijl ufw draait, spoelen niets, maar op het moment dat je een standaardbeleid omdraait worden de ketens herladen, en een sessie die het oude beleid toestond gaat mee. Doe de standaarden, de toestemmingen en het inschakelen in één gang, zolang je nog een weg naar binnen hebt die niet van de machine afhangt.

Test de geblokkeerde toestand, en houd de ongedaanmaking

Een ongeteste noodschakelaar is een gok. Verbreek de client expres en probeer een pagina te laden: het moet mislukken. Verbind opnieuw en het moet herstellen zonder een regel aan te raken. sudo ufw status verbose bevestigt de standaarden en de logstatus, en ufw status numbered laat zien welke testregel je moet verwijderen als die zijn doel overleeft.

Houd het omgekeerde script naast het voorwaartse. Een machine met uitgaand-weigeren en een dode tunnel kan zijn eigen reparatie niet downloaden, dus de ongedaanmaking moet op schijf staan en leesbaar zijn vanaf een console:

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

Voer het uit wanneer de tunnel al plat ligt en de regels eraf moeten, niet als routinestap. Voordat je de terminal sluit, moeten vier dingen kloppen: de peer-regel noemt precies één adres, DNS heeft een benoemde uitzondering, het inschakelen kwam na de toestemmingen, en het lostrekken van de tunnel doodt gewoon verkeer zonder de client voorgoed te doden.