Blockiert ein kommerzielles VPN den Port 5432? Vergleichen Sie Ihre Optionen

Die Anwendung sprach jeden Tag vom Büro aus mit ihrer Datenbank. Dann aktivierte jemand den kommerziellen VPN-Client auf demselben Laptop, und die Verbindung begann nach dem Handshake zurückgesetzt zu werden. In der Anwendung änderte sich nichts, der Tunnel meldet sich als gesund, und die Firewall, die Sie kontrollieren, hat keine Blockierregel. Was sich geändert hat, ist der Ausgangspfad: Die Server des Anbieters sind gemeinsam genutzte Endpunkte mit hohem Volumen, und Anbieter filtern ausgehende Ports, um Missbrauch zu reduzieren. Datenbank- und Mail-Submission-Ports bekommen den größten Teil davon ab, weil genau diese Ports Scans und Spam aus einem anonymen Adresspool anziehen.

Der Fünf-Minuten-Test, der Filterung von allem anderen trennt

Prüfen Sie von derselben Maschine aus einen Port, der offen sein muss, und den Port, der scheitert, auf demselben Host, einmal mit aktivem und einmal mit getrenntem Tunnel. Verwenden Sie beide Male denselben Befehl, damit die einzige Variable der Tunnel ist:

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

Vier Ergebnisse decken fast jeden Fall ab. Wenn 443 funktioniert und 5432 nur bei aktivem Tunnel scheitert, sehen Sie Portfilterung auf dem Ausgangspfad. Wenn beide bei aktivem Tunnel scheitern und beide ohne ihn funktionieren, liegt das Problem beim Routing oder DNS, nicht in der Portrichtlinie. Wenn beide Ports verbinden, die Anwendung aber weiterhin scheitert, liegt der Fehler bei der Authentifizierung oder TLS, nicht in der Erreichbarkeit. Und wenn nur ein Serverstandort des Anbieters scheitert, ist es eine Richtlinie pro Server, also probieren Sie einen anderen Standort, bevor Sie irgendeine Konfiguration anfassen.

Option eins: Split-Tunnel für das Datenbank-Subnetz

Wenn der Laptop das kommerzielle VPN nur für andere Zwecke braucht, schließen Sie den Adressbereich der Datenbank vom Tunnel aus, damit der Verkehr gar nicht erst in den gemeinsamen Ausgang gelangt. Das ist die sauberste Option, wenn die beiden Pfade wirklich nicht zusammenkommen müssen, und sie kostet nichts außer einer Routingregel, die Sie dokumentieren können. Der Kompromiss ist, dass Split-Tunneling eine zweite Richtlinienfläche einführt: Was vom Tunnel ausgeschlossen ist, muss bewusst geschehen, nicht als Nebenwirkung eines Subnetzes, das jemand später hinzugefügt hat.

Es funktioniert in dem Moment nicht mehr, in dem die Datenbank in dem Netzwerk liegt, das das VPN erreichen soll, also prüfen Sie das, bevor Sie sich dafür entscheiden.

Option zwei: eigener Endpunkt, eigener Egress

Ein kleiner VPN-Endpunkt auf einem VPS gibt Ihnen die Kontrolle über die Egress-Richtlinie, und es ist kein gemeinsamer Pool beteiligt. Das ist die Option, die einen ehrlichen Vergleich mit dem kommerziellen Client verdient: Sie gewinnen eine vorhersehbare Quelladresse und verlieren den globalen Fußabdruck und den Komfort des Anbieters. Für ein Team, das Datenbank- und Mailports den ganzen Tag braucht, fällt der Kompromiss meist zugunsten des eigenen Endpunkts aus, weil der Fehlermodus dann Ihre eigene Fehlkonfiguration ist und nicht die Missbrauchsrichtlinie eines anderen.

Vergleichen Sie beide bei der Stabilität der Quelladresse, dabei, wer Ihren Verkehr lesen kann, und dabei, was an dem Tag passiert, an dem der Anbieter des Endpunkts seine eigene Filterung ändert.

Option drei: nehmen Sie den Laptop aus dem Pfad

Ein CI-Job, ein geplanter Container oder ein Bastion-Host im erlaubten Netzwerk hängt nicht vom Tunnelzustand eines Menschen ab. Erreichen Sie die Datenbank per SSH-Tunnel von einem Host aus, der bereits erlaubt ist, und der Laptop spricht nie direkt mit dem Port. Das ist die Option, die skaliert, wenn mehrere Personen auf dieselbe Einschränkung stoßen, und sie ist auch diejenige, die das Problem beseitigt, statt es zu umgehen.

Es ist mehr Arbeit im Vorfeld als eine Split-Tunnel-Regel, und es hilft der einen Person nicht, die jetzt eine interaktive Sitzung braucht.

Warum das Aufnehmen der Anbieteradresse in eine Positivliste der falsche Vergleich ist

Die Ausgangsadresse des Anbieters in eine Datenbank-Positivliste aufzunehmen funktioniert, und es gewährt auch jedem anderen Abonnenten Zugang, der diese Adresse in diesem Moment teilt. Für ein schreibgeschütztes Replikat hinter einem eng vergebenen Anwendungskonto mag die Exposition für einen Tag vertretbar sein. Für alles Beschreibbare ist es kein Kompromiss, der einen Namen verdient, und rotierende Ausgangsadressen machen es schlimmer: Jede Serveränderung bricht die Regel, und die Wartung lädt breite CIDR-Einträge ein, die den Zweck einer Positivliste zunichtemachen.

Dedizierte oder statische Adressen, wo der Anbieter sie verkauft, sind die einzige Version davon, die skaliert. Binden Sie die Positivliste an eine Adresse, die nur Ihnen gehört, oder binden Sie sie gar nicht.

Was immer Sie wählen, schreiben Sie den Pfad und den Grund auf. Die nächste Person wird dieselbe zurückgesetzte Verbindung erleben und anfangen, die Anwendung zu beschuldigen.