ufw allow 443 hat einem Dienst hinter dem VPN nichts gebracht

Ping gelingt von einem VPN-Client, der TCP-Dienst läuft in den Timeout und ufw allow 443/tcp ändert überhaupt nichts. Wenn die Anwendung auf einem Host hinter dem Gateway läuft und nicht auf dem Gateway selbst, wurde diese Freigabe für den falschen Verkehrspfad geschrieben. Das Paket ist nicht an die Firewall adressiert und wird keinem lokalen Prozess zugestellt, daher sehen die Eingangsregeln es nie. Die Reparatur ist eine Routenregel, die auf den weitergeleiteten Fluss zielt, und der Beleg dafür steht bereits im Log.

Entscheide, ob das Ziel lokal oder weitergeleitet ist

Lies das Paket so, wie der Kernel es sieht. Verkehr, der an einen Dienst auf dem Gateway zugestellt wird, ist lokale Eingabe. Verkehr, den das Gateway an einen anderen Host weiterleitet, ist weitergeleitet, und UFW führt für die beiden Pfade getrennte Regelsätze. Die Unterscheidung entscheiden die Zieladresse und der Routing-Lookup, nicht die Schnittstelle, auf der das Paket ankam.

Eine Logzeile mit derselben Schnittstelle in den Feldern IN und OUT kann dennoch ein geroutetes Paket beschreiben, denn ein Tunnel, der Clients in ein Gerät hinein und wieder hinaus trägt, sieht genau so aus. Die Zieladresse beantwortet die Frage schneller als die Schnittstellennamen. Derselbe Name zweimal sagt nichts über lokale Zustellung, und eine Tunnel-Schnittstelle zu erfinden, die das Deployment nie angelegt hat, hilft ebenfalls nicht.

Lies den Block, bevor du irgendeine Regel hinzufügst

Reproduziere einen autorisierten Verbindungsversuch und erfasse Quelle, Ziel, Protokoll und Zielport so, wie das Gateway sie aufgezeichnet hat. Vergleiche diese vier Werte mit dem Logeintrag und mit dem tatsächlichen Standort des Dienstes. Ein früheres erfolgreiches Ping belegt nur, dass sein eigener Austausch erlaubt war, und eine Firewall kann ein TCP SYN an eine Anwendung ganz anders behandeln.

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

Der erste Befehl liefert das Urteil samt seinen Feldern, der zweite zeigt, was bereits geladen ist und in welcher Reihenfolge. Lies beide, bevor du etwas änderst, denn ein früheres Deny oberhalb deiner Regel erklärt dasselbe Symptom ohne jede fehlende Regel.

Schreibe die engste passende Routenregel

In dieser Anleitung kommen Clients über tun0 aus 172.20.8.0/24, der Dienst lauscht auf 10.30.0.15 an Port 8443, und das Gateway verlässt das Netz über ens5. Diese Werte wurden gewählt, damit sie überhaupt nicht wie ein Cloud-VPC-Standard von 10.0.0.0/16 oder ein Heimnetz von 192.168.0.0/16 aussehen, und 8443 hält das Beispiel vom eigenen 443-Listener des Gateways fern.

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

Der Probelauf gibt den Regelsatz aus, der entstehen würde, und das ist der billigste Weg zu sehen, ob deine Regel vor oder nach einem bestehenden Deny landet. Prüfe Schnittstellennamen und innere Adressen gegen das Deployment statt gegen das Beispiel, und bedenke, dass der Filter bei vorgeschaltetem Ziel-NAT das übersetzte Ziel sieht.

Halte den Rückweg zustandsbehaftet

UFW verfolgt erlaubte Verbindungen, daher werden die Antworten auf einen erlaubten weitergeleiteten Fluss ohne ausdrückliche Gegenregel zugelassen. Eine unbeschränkte Regel in Gegenrichtung hinzuzufügen, damit es funktioniert, weitet die Richtlinie weit über den einen Dienst hinaus aus und ist für einen normalen Anfrage-Antwort-Austausch nicht nötig. Halte den Rückweg implizit und den Regelsatz lesbar.

Wende die Regel erst an, wenn der Probelauf deiner Absicht entspricht, und bestätige dann, dass die sortierte Liste sie an der erwarteten Stelle zeigt. Behandle den VPN-Listener und die Verwaltungsregeln als getrennte Angelegenheiten, denn sie zu ändern ist eine andere Entscheidung als eine Anwendung freizugeben. Notiere die Änderung dort, wo die Topologie festgehalten ist, damit der nächste Ingenieur sie nicht aus einem Paketmitschnitt neu entdecken muss.

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

Prüfe, was UFW nicht für dich durchsetzen kann

Eine korrekte Regel braucht weiterhin Kernel-Weiterleitung und eine Route, die den Dienst erreicht. Bestätige beides, bevor du die Firewall ein zweites Mal beschuldigst.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Schau dann außerhalb des Hosts. Bei einer Cloud-Instanz ersetzt die UFW-Richtlinie des Gasts keine Security Groups, Subnetz-ACLs oder die Weiterleitungskonfiguration des Anbieters, daher ist ein lokaler Block ein Beleg für eine Schicht und nicht der Beweis, dass alle anderen Schichten den Dienst zulassen.

Schließe mit einem Test einer frischen Verbindung bei aktiver Firewall ab, von einer erlaubten Quelle und von einer unbeteiligten. UFW zu deaktivieren beseitigt das Symptom und zerstört den Beleg im selben Befehl, deshalb sollte es das letzte Experiment sein und nicht das erste.