Waarom je URL een ingang op poort 80 of 443 nodig heeft, niet 45000

Typ een hostnaam in een browser en het schema bepaalt de bestemmingspoort: 80 voor http, 443 voor https. Niets in een DNS-antwoord overrulet dat, en geen enkele doorstuurrege op je machine kan een listener aan de rand van de provider verzinnen. Wanneer een VPN-provider je een hoge openbare poort zoals 45000 geeft, werkt een expliciete URL en een schone niet. De kloof zit bij het ingangspunt, niet in de applicatie.

Loop het pad van browser naar proces één keer door, en de drie publicatieopties lijken niet langer mysterieus.

Kijk waar het verzoek echt heen gaat

De browser lost de naam op naar een adres en verbindt vervolgens met dat adres op de standaardpoort van het schema, tenzij de URL een andere noemt. De rand van je provider bepaalt wat er met de binnenkomende verbinding gebeurt. Als de doorstuurtabel alleen 45000 aan je interne adres koppelt, heeft een verbinding naar 80 nergens heen te gaan en wordt deze geweigerd of weggegooid voordat je machine erbij betrokken is.

Die weigering gebeurt aan de rand, daarom tonen de logs van je applicatie helemaal niets. Het ontbreken van logs is bewijs van waar het pakket stopte, niet bewijs dat de applicatie kapot is.

Waarom een lokale regel de rand niet kan repareren

Een omleiding of een DNAT-regel op de applicatiehost werkt op pakketten die al zijn aangekomen. Pakketten die bij de provider naar poort 80 worden gestuurd, komen nooit aan, dus de regel wordt nooit geëvalueerd. Dit is het meest verspilde uur in het hele probleem.

DNS kan de poort ook niet dragen. HTTP-specificatie definieert de standaardwaarden van het schema, en een A- of AAAA-record retourneert een adres terwijl een CNAME een andere naam retourneert. De browser voegt nog steeds de poort van het schema toe, dus alleen een expliciete poort in de URL verandert de bestemming.

Optie één: de expliciete poort behouden

Vaak is het juiste antwoord het onglamoureuze. Publiceer de volledige URL met de poort, beëindig TLS op een ingang die dat ondersteunt, en zorg dat elke gegenereerde link dezelfde oorsprong houdt. Voor een klein, gecontroleerd publiek is dit compleet, en het kost niets anders dan een zichtbaar poortnummer.

Controleer omleidingen en cookiebereik terwijl je er bent, want een backend die zijn eigen hostnaam in een Location-header schrijft, maakt de regeling ongedaan.

Optie twee: een echte standaardpoortingang krijgen

Sommige providers en hostingopstellingen sturen 80 en 443 door op een gedeeld of toegewijd adres als gedocumenteerde dienst. Vraag wat er werkelijk inbegrepen is in plaats van aan te nemen dat een openbaar uitgaand adres willekeurige inkomende poorten impliceert. Een toegewijd uitgaand adres zegt niets over inkomende doorsturing.

Bevestig eigendom en beschikbaarheid schriftelijk, inclusief wat er met de ingang gebeurt wanneer de tunnel opnieuw verbindt met een ander adres. Een ingang die met de tunnel meebeweegt, veroorzaakt storingen die op DNS-fouten lijken.

Optie drie: een frontend ervoor zetten

Een reverse proxy op een bereikbaar adres kan op 443 luisteren en TLS beëindigen en een aparte verbinding naar de backend over de VPN openen. Bezoekers zien de naam en standaardpoort van de frontend, terwijl de frontend namens jou met de hoge poort van de backend praat. Dit werkt omdat het de architectuur verandert in plaats van tegen het ingangspunt te vechten. De backend heeft dan helemaal geen inkomende poort op het openbare internet nodig.

Het verandert ook wat je beheert. De frontend bezit publieke TLS, toegangsbeleid, logs en beschikbaarheid, en moet de backendkeuze beperken tot de bedoelde dienst. Als de sprong van frontend naar backend HTTPS gebruikt, behoud dan certificaatvalidatie op die sprong.

Behoud één oorsprong

De openbare hostnaam, het schema en de poort van de frontend vormen de oorsprong die bezoekers gebruiken, dus configureer de externe URL van de applicatie, omleidingen en cookies voor die oorsprong. Stuur de oorspronkelijke host en het doorgestuurde schema als de applicatie absolute links bouwt. Een antwoord dat gebruikers terugstuurt naar een privénaam of een hoge poort, maakt de schone ingang die je zojuist hebt gebouwd ongedaan.

Beslis daarna met het publiek in gedachten. Een korte URL kan een beheerde frontend rechtvaardigen, en het is niet de moeite waard om per ongeluk een privédienst alleen voor VPN in een openbare te veranderen.