Warum Ihre URL einen Eintrag auf Port 80 oder 443 braucht, nicht 45000
Ein Browser wählt 80 oder 443 aus dem Schema, nicht den hohen Port Ihres Anbieters. Gehen Sie den Einstiegspfad und den Ursprung durch, den jede Veröffentlichungsoption hinterlässt.
Geben Sie einen Hostnamen in einen Browser ein, und das Schema bestimmt den Zielport: 80 für http, 443 für https. Nichts in einer DNS-Antwort überschreibt das, und keine Weiterleitungsregel auf Ihrem Rechner kann am Rand des Anbieters einen Listener erfinden. Wenn ein VPN-Anbieter Ihnen einen hohen öffentlichen Port wie 45000 gibt, funktioniert eine explizite URL und eine saubere nicht. Die Lücke liegt am Einstiegspunkt, nicht in der Anwendung.
Gehen Sie den Weg vom Browser zum Prozess einmal durch, und die drei Veröffentlichungsoptionen wirken nicht mehr rätselhaft.
Sehen Sie nach, wohin die Anfrage tatsächlich geht
Der Browser löst den Namen in eine Adresse auf und verbindet sich dann mit dieser Adresse über den Standardport des Schemas, sofern die URL keinen anderen nennt. Der Rand Ihres Anbieters entscheidet, was mit der ankommenden Verbindung geschieht. Wenn seine Weiterleitungstabelle nur 45000 auf Ihre interne Adresse abbildet, hat eine Verbindung zu 80 kein Ziel und wird abgelehnt oder verworfen, bevor Ihr Rechner überhaupt beteiligt ist.
Diese Ablehnung geschieht am Rand, weshalb Ihre Anwendungsprotokolle gar nichts zeigen. Fehlende Protokolle sind ein Beleg dafür, wo das Paket stehen blieb, nicht dafür, dass die Anwendung defekt ist.
Warum eine lokale Regel den Rand nicht reparieren kann
Eine Weiterleitung oder eine DNAT-Regel auf dem Anwendungshost wirkt auf Pakete, die bereits angekommen sind. Pakete, die beim Anbieter an Port 80 gesendet werden, kommen nie an, also wird die Regel nie ausgewertet. Das ist die häufigste verlorene Stunde im ganzen Problem.
Auch DNS kann den Port nicht tragen. HTTP-Spezifikation definiert die Standardwerte des Schemas, und ein A- oder AAAA-Eintrag liefert eine Adresse, während ein CNAME einen anderen Namen liefert. Der Browser hängt weiterhin den Port des Schemas an, also ändert nur ein expliziter Port in der URL das Ziel.
Option eins: den expliziten Port behalten
Oft ist die richtige Antwort die unglamouröse. Veröffentlichen Sie die vollständige URL mit dem Port, beenden Sie TLS an einem Eintrag, der das unterstützt, und stellen Sie sicher, dass jeder erzeugte Link denselben Ursprung behält. Für ein kleines, kontrolliertes Publikum ist das vollständig, und es kostet nichts außer einer sichtbaren Portnummer.
Prüfen Sie Weiterleitungen und Cookie-Geltungsbereich, während Sie dort sind, denn ein Backend, das seinen eigenen Hostnamen in einen Location-Header schreibt, macht die Vereinbarung zunichte.
Option zwei: einen echten Standardport-Eintrag bekommen
Manche Anbieter und Hosting-Konstrukte leiten 80 und 443 auf einer gemeinsamen oder dedizierten Adresse als dokumentierten Dienst weiter. Fragen Sie, was tatsächlich enthalten ist, statt anzunehmen, dass eine öffentliche Ausgangsadresse beliebige eingehende Ports bedeutet. Eine dedizierte Ausgangsadresse sagt nichts über eingehende Weiterleitung aus.
Bestätigen Sie Eigentum und Verfügbarkeit schriftlich, einschließlich dessen, was mit dem Eintrag geschieht, wenn der Tunnel sich mit einer anderen Adresse neu verbindet. Ein Eintrag, der mit dem Tunnel wandert, erzeugt Ausfälle, die wie DNS-Fehler aussehen.
Option drei: ein Frontend davorsetzen
Ein Reverse-Proxy auf einer erreichbaren Adresse kann auf 443 lauschen und TLS beenden und eine separate Verbindung zum Backend über das VPN öffnen. Besucher sehen den Namen und Standardport des Frontends, während das Frontend in Ihrem Namen mit dem hohen Port des Backends spricht. Das funktioniert, weil es die Architektur ändert, statt gegen den Einstiegspunkt zu kämpfen. Das Backend braucht dann überhaupt keinen eingehenden Port im öffentlichen Internet.
Es ändert auch, was Sie betreiben. Das Frontend besitzt öffentliches TLS, Zugriffsrichtlinie, Protokolle und Verfügbarkeit, und es muss die Backend-Auswahl auf den vorgesehenen Dienst begrenzen. Wenn der Sprung vom Frontend zum Backend HTTPS verwendet, behalten Sie die Zertifikatsprüfung auf diesem Sprung bei.
Einen Ursprung behalten
Öffentlicher Hostname, Schema und Port des Frontends bilden den Ursprung, den Besucher verwenden, also konfigurieren Sie die externe URL der Anwendung, Weiterleitungen und Cookies für diesen Ursprung. Senden Sie den ursprünglichen Host und das weitergeleitete Schema, wenn die Anwendung absolute Links baut. Eine Antwort, die Benutzer auf einen privaten Namen oder einen hohen Port zurückwirft, macht den sauberen Eintrag zunichte, den Sie gerade gebaut haben.
Entscheiden Sie dann mit Blick auf das Publikum. Eine kurze URL kann ein verwaltetes Frontend rechtfertigen, und es lohnt sich nicht, versehentlich einen privaten Dienst nur für VPN in einen öffentlichen zu verwandeln.