Hvorfor URL-en din trenger en inngang på port 80 eller 443, ikke 45000

Skriv et vertsnavn i en nettleser, og skjemaet bestemmer målporten: 80 for http, 443 for https. Ingenting i et DNS-svar overstyrer det, og ingen videresendingsregel på maskinen din kan finne opp en lytter ved leverandørens kant. Når en VPN-leverandør gir deg en høy offentlig port som 45000, fungerer en eksplisitt URL, og en ren gjør det ikke. Gapet ligger ved inngangspunktet, ikke inne i applikasjonen.

Gå gjennom veien fra nettleser til prosess én gang, og de tre publiseringsmulighetene slutter å virke mystiske.

Se hvor forespørselen faktisk går

Nettleseren slår opp navnet til en adresse og kobler deretter til den adressen på skjemaets standardport, med mindre URL-en navngir en annen. Kantsonen til leverandøren din avgjør hva som skjer med den innkommende tilkoblingen. Hvis videresendingstabellen bare mapper 45000 til din interne adresse, har en tilkobling til 80 ingen steder å gå og blir avvist eller droppet før maskinen din i det hele tatt er involvert.

Den avvisningen skjer ved kanten, og derfor viser applikasjonsloggene dine ingenting i det hele tatt. Fravær av logger er bevis for hvor pakken stoppet, ikke bevis for at applikasjonen er ødelagt.

Hvorfor en lokal regel ikke kan reparere kanten

En omdirigering eller en DNAT-regel på applikasjonsverten virker på pakker som allerede har ankommet. Pakker sendt til port 80 hos leverandøren ankommer aldri, så regelen blir aldri evaluert. Dette er den vanligste bortkastede timen i hele problemet.

DNS kan heller ikke bære porten. HTTP-spesifikasjonen definerer skjemaets standardverdier, og en A- eller AAAA-post returnerer en adresse mens en CNAME returnerer et annet navn. Nettleseren setter fortsatt sammen skjemaets port, så bare en eksplisitt port i URL-en endrer målet.

Alternativ én: behold den eksplisitte porten

Ofte er det riktige svaret det lite glamorøse. Publiser hele URL-en med porten, avslutt TLS på en inngang som støtter det, og sørg for at hver genererte lenke beholder samme opprinnelse. For et lite, kontrollert publikum er dette komplett, og det koster ingenting utover et synlig portnummer.

Sjekk omdirigeringer og cookie-omfang mens du er der, fordi en backend som skriver sitt eget vertsnavn i en Location-header, ødelegger ordningen.

Alternativ to: få en ekte standardportinngang

Noen leverandører og hostingoppsett videresender 80 og 443 på en delt eller dedikert adresse som en dokumentert tjeneste. Spør hva som faktisk er inkludert i stedet for å anta at en offentlig utgangsadresse innebærer vilkårlige innkommende porter. En dedikert utgående adresse sier ingenting om innkommende videresending.

Bekreft eierskap og tilgjengelighet skriftlig, inkludert hva som skjer med inngangen når tunnelen kobler til på nytt med en annen adresse. En inngang som flytter seg med tunnelen, gir avbrudd som ser ut som DNS-feil.

Alternativ tre: sett et frontend foran

En omvendt proxy på en tilgjengelig adresse kan lytte på 443 og avslutte TLS og åpne en egen tilkobling til backenden over VPN-en. Besøkende ser navnet og standardporten til frontend, mens frontend snakker med backendens høye port på dine vegne. Dette fungerer fordi det endrer arkitekturen i stedet for å kjempe mot inngangspunktet. Backenden trenger da ingen innkommende port på det offentlige internettet i det hele tatt.

Det endrer også hva du drifter. Frontend eier offentlig TLS, tilgangspolicy, logger og tilgjengelighet, og det må begrense backend-valget til den tiltenkte tjenesten. Hvis hoppet fra frontend til backend bruker HTTPS, behold sertifikatvalideringen på det hoppet.

Behold én opprinnelse

Frontendens offentlige vertsnavn, skjema og port utgjør opprinnelsen besøkende bruker, så konfigurer applikasjonens eksterne URL, omdirigeringer og cookies for den opprinnelsen. Send den opprinnelige verten og det videresendte skjemaet hvis applikasjonen bygger absolutte lenker. Et svar som sender brukere tilbake til et privat navn eller en høy port, ødelegger den rene inngangen du nettopp bygde.

Bestem deg deretter med publikumet i tankene. En kort URL kan rettferdiggjøre et administrert frontend, og det er ikke verdt å ved et uhell gjøre en privat tjeneste kun for VPN om til en offentlig.