Kvifor URL-en din treng ein inngang på port 80 eller 443, ikkje 45000

Skriv eit vertsnamn i ein nettlesar, og skjemaet avgjer målporten: 80 for http, 443 for https. Ingenting i eit DNS-svar overstyrer det, og inga vidaresendingsregel på maskina di kan finne opp ein lyttar ved kanten av leverandøren. Når ein VPN-leverandør gjev deg ein høg offentleg port som 45000, fungerer ein eksplisitt URL, og ein rein gjer det ikkje. Gapet ligg ved inngangspunktet, ikkje inne i applikasjonen.

Gå gjennom vegen frå nettlesar til prosess éin gong, og dei tre publiseringsmoglegheitene sluttar å verke mystiske.

Sjå kvar førespurnaden faktisk går

Nettlesaren slår opp namnet til ein adresse og koplar deretter til den adressa på standardporten til skjemaet, med mindre URL-en nemner ein annan. Kantsona til leverandøren din avgjer kva som skjer med den innkommande tilkoplinga. Viss vidaresendingstabellen berre mappar 45000 til den interne adressa di, har ei tilkopling til 80 ingen stad å gå og blir avvist eller droppa før maskina di i det heile er involvert.

Den avvisinga skjer ved kanten, og difor viser applikasjonsloggane dine ingenting i det heile. Fråvær av loggar er prov for kvar pakken stoppa, ikkje prov for at applikasjonen er øydelagd.

Kvifor ein lokal regel ikkje kan reparere kanten

Ei omdirigering eller ei DNAT-regel på applikasjonsverten verkar på pakkar som allereie har kome. Pakkar som blir sende til port 80 hos leverandøren, kjem aldri, så regelen blir aldri evaluert. Dette er den vanlegaste bortkasta timen i heile problemet.

DNS kan heller ikkje bera porten. HTTP-spesifikasjonen definerer standardverdiane i skjemaet, og ein A- eller AAAA-post returnerer ein adresse medan ein CNAME returnerer eit anna namn. Nettlesaren set framleis saman porten frå skjemaet, så berre ein eksplisitt port i URL-en endrar målet.

Alternativ éin: behald den eksplisitte porten

Ofte er det rette svaret det lite glamorøse. Publiser heile URL-en med porten, avslutt TLS på ein inngang som støttar det, og sørg for at kvar genererte lenke held same opphav. For eit lite, kontrollert publikum er dette komplett, og det kostar ingenting utover eit synleg portnummer.

Sjekk omdirigeringar og cookie-omfang medan du er der, fordi ein backend som skriv sitt eige vertsnamn i ein Location-header, øydelegg ordninga.

Alternativ to: få ein ekte standardportinngang

Nokre leverandørar og hostingoppsett vidaresender 80 og 443 på ei delt eller dedikert adresse som ei dokumentert teneste. Spør kva som faktisk er inkludert i staden for å anta at ei offentleg utgangsadresse inneber vilkårlege innkommande portar. Ei dedikert utgåande adresse seier ingenting om innkommande vidaresending.

Stadfest eigarskap og tilgjenge skriftleg, inkludert kva som skjer med inngangen når tunnelen koplar til på nytt med ei anna adresse. Ein inngang som flyttar seg med tunnelen, gjev avbrot som ser ut som DNS-feil.

Alternativ tre: set eit frontend framfor

Ein omvend proxy på ei tilgjengeleg adresse kan lytte på 443 og avslutte TLS og opne ei eiga tilkopling til backend-en over VPN-en. Besøkande ser namnet og standardporten til frontend, medan frontend snakkar med den høge porten til backend-en på dine vegner. Dette verkar fordi det endrar arkitekturen i staden for å kjempe mot inngangspunktet. Backend-en treng då ingen innkommande port på det offentlege internettet i det heile.

Det endrar òg kva du driv. Frontend eig offentleg TLS, tilgangspolicy, loggar og tilgjenge, og det må avgrense backend-valet til den tiltenkte tenesta. Viss hoppet frå frontend til backend brukar HTTPS, behald sertifikatvalideringa på det hoppet.

Behald eitt opphav

Det offentlege vertsnamnet, skjemaet og porten til frontend utgjer opphavet besøkande brukar, så konfigurer den eksterne URL-en til applikasjonen, omdirigeringar og cookies for det opphavet. Send den opphavlege verten og det vidaresende skjemaet viss applikasjonen byggjer absolutte lenker. Eit svar som sender brukarar tilbake til eit privat namn eller ein høg port, øydelegg den reine inngangen du nettopp bygde.

Avgjer deretter med publikumet i tankane. Ein kort URL kan rettferdiggjere eit administrert frontend, og det er ikkje verdt å ved eit uhell gjere ei privat teneste berre for VPN om til ei offentleg.