ufw allow 443 hielp niets voor een dienst achter de VPN

Ping slaagt vanaf een VPN-client, de TCP-dienst loopt in een time-out, en ufw allow 443/tcp verandert helemaal niets. Wanneer de toepassing op een host achter de gateway draait en niet op de gateway zelf, is die toestemming voor het verkeerde verkeerspad geschreven. Het pakket is niet aan de firewall geadresseerd en wordt niet aan een lokaal proces afgeleverd, dus de invoerregels zien het nooit. De reparatie is een routeregel gericht op de doorgestuurde stroom, en het bewijs daarvoor staat al in het logboek.

Bepaal of de bestemming lokaal of doorgestuurd is

Lees het pakket zoals de kernel het ziet. Verkeer dat aan een dienst op de gateway wordt afgeleverd, is lokale invoer. Verkeer dat de gateway naar een andere host routeert, is doorgestuurd, en UFW houdt aparte regelsets voor de twee paden. Het onderscheid wordt bepaald door het bestemmingsadres en de routeopzoeking, niet door de interface waarop het pakket aankwam.

Een logregel met dezelfde interface in zowel het IN- als het OUT-veld kan nog steeds een gerouteerd pakket beschrijven, omdat een tunnel die clients in en uit één apparaat draagt er precies zo uitziet. Het bestemmingsadres beslecht de vraag sneller dan de interfacenamen. Dezelfde naam twee keer zien bewijst geen lokale aflevering, en een tunnelinterface verzinnen die de uitrol nooit heeft aangemaakt helpt ook niet.

Lees het blok voordat je enige regel toevoegt

Reproduceer één geautoriseerde verbindingspoging en leg de bron, bestemming, het protocol en de bestemmingspoort vast zoals de gateway ze heeft geregistreerd. Vergelijk die vier waarden met de logregel en met de werkelijke locatie van de dienst. Een eerdere geslaagde ping bewijst alleen dat de eigen uitwisseling was toegestaan, en een firewall kan een TCP SYN naar een toepassing heel anders behandelen.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

De eerste opdracht geeft het oordeel met zijn velden terug, en de tweede toont wat al geladen is en in welke volgorde. Lees beide voordat je iets bewerkt, want een eerdere weigering boven je regel verklaart hetzelfde symptoom zonder enige ontbrekende regel.

Schrijf de smalste routeregel die past

In dit voorbeeld komen clients binnen op tun0 vanaf 172.20.8.0/24, luistert de dienst op 10.30.0.15 op poort 8443, en verlaat de gateway het netwerk via ens5. Die waarden zijn gekozen om helemaal niet te lijken op een cloud-VPC-standaard van 10.0.0.0/16 of een thuisnetwerk van 192.168.0.0/16, en 8443 houdt het voorbeeld weg van de eigen 443-luisteraar van de gateway.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

De proefrun drukt de regelset af die zou ontstaan, en dat is de goedkoopste manier om te zien of je regel voor of na een bestaande weigering landt. Controleer de interfacenamen en de interne adressen tegen de uitrol en niet tegen het voorbeeld, en onthoud dat wanneer de bestemmings-NAT eerst draait, het filter de vertaalde bestemming ziet.

Houd het retourpad stateful

UFW volgt toegestane verbindingen, dus de antwoorden op een toegestane doorgestuurde stroom worden toegelaten zonder een expliciete omgekeerde regel. Een onbeperkte regel in de tegengestelde richting toevoegen om dingen te laten werken verbreedt het beleid ver voorbij de enkele dienst en is niet nodig voor een normale vraag-en-antwoorduitwisseling. Houd het retourpad impliciet en de regelset leesbaar.

Pas de regel pas toe als de proefrun bij je bedoeling past, en bevestig dan dat de geordende lijst hem op de verwachte plaats toont. Houd de VPN-luisteraar en de beheerregels als afzonderlijke zaken, want die wijzigen is een andere beslissing dan één toepassing toelaten. Noteer de wijziging op dezelfde plek waar de topologie is opgeschreven, zodat de volgende engineer die niet opnieuw hoeft te ontdekken uit een pakketopname.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Controleer wat UFW niet voor je kan afdwingen

Een juiste regel heeft nog steeds kernel-doorgifte en een route nodig die de dienst bereikt. Bevestig beide voordat je de firewall een tweede keer de schuld geeft.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Kijk daarna buiten de host. Op een cloud-instantie vervangt het UFW-beleid van de gast geen beveiligingsgroepen, subnet-ACL's of de eigen doorgifteconfiguratie van de provider, dus een lokale blokkade is bewijs over één laag en niet het bewijs dat alle andere lagen de dienst toestaan.

Sluit af met het testen van een nieuwe verbinding terwijl de firewall aan staat, vanaf een toegestane bron en vanaf een ongerelateerde. UFW uitschakelen verwijdert het symptoom en vernietigt het bewijs in dezelfde opdracht, daarom zou het het laatste experiment moeten zijn en niet het eerste.