Varför din URL behöver en ingång på port 80 eller 443, inte 45000

Skriv ett värdnamn i en webbläsare och schemat bestämmer målporten: 80 för http, 443 för https. Ingenting i ett DNS-svar åsidosätter det, och ingen vidarebefordringsregel på din maskin kan hitta på en lyssnare vid leverantörens kant. När en VPN-leverantör ger dig en hög offentlig port som 45000 fungerar en explicit URL, men en ren gör det inte. Gapet ligger vid ingångspunkten, inte inne i applikationen.

Gå igenom vägen från webbläsare till process en gång, och de tre publiceringsalternativen slutar verka mystiska.

Se vart förfrågan faktiskt tar vägen

Webbläsaren slår upp namnet till en adress och ansluter sedan till den adressen på schemats standardport, om inte URL:en anger en annan. Kanten hos din leverantör avgör vad som händer med den inkommande anslutningen. Om dess vidarebefordringstabell bara mappar 45000 till din interna adress har en anslutning till 80 ingenstans att ta vägen och avvisas eller släpps innan din maskin ens är inblandad.

Det avvisandet sker vid kanten, och därför visar applikationens loggar ingenting alls. Avsaknaden av loggar är bevis för var paketet stannade, inte bevis för att applikationen är trasig.

Varför en lokal regel inte kan reparera kanten

En omdirigering eller en DNAT-regel på applikationsvärden verkar på paket som redan har anlänt. Paket som skickas till port 80 hos leverantören anländer aldrig, så regeln utvärderas aldrig. Det här är den vanligaste bortkastade timmen i hela problemet.

DNS kan inte heller bära porten. HTTP-specifikationen definierar schemats standardvärden, och en A- eller AAAA-post returnerar en adress medan en CNAME returnerar ett annat namn. Webbläsaren sammanfogar fortfarande schemats port, så bara en explicit port i URL:en ändrar målet.

Alternativ ett: behåll den explicita porten

Ofta är det rätta svaret det oglamorösa. Publicera hela URL:en med porten, avsluta TLS på en ingång som stöder det, och se till att varje genererad länk behåller samma ursprung. För en liten, kontrollerad publik är detta komplett, och det kostar inget utöver ett synligt portnummer.

Kontrollera omdirigeringar och cookie-omfång medan du är där, för en backend som skriver sitt eget värdnamn i en Location-header förstör arrangemanget.

Alternativ två: skaffa en riktig standardportingång

Vissa leverantörer och hostingupplägg vidarebefordrar 80 och 443 på en delad eller dedikerad adress som en dokumenterad tjänst. Fråga vad som faktiskt ingår i stället för att anta att en offentlig utgående adress innebär godtyckliga inkommande portar. En dedikerad utgående adress säger ingenting om inkommande vidarebefordran.

Bekräfta ägande och tillgänglighet skriftligt, inklusive vad som händer med ingången när tunneln återansluter med en annan adress. En ingång som flyttar med tunneln ger avbrott som ser ut som DNS-fel.

Alternativ tre: sätt en frontend framför

En omvänd proxy på en nåbar adress kan lyssna på 443 och avsluta TLS och öppna en separat anslutning till backend över VPN:en. Besökare ser frontendens namn och standardport, medan frontend talar med backendens höga port å dina vägnar. Detta fungerar eftersom det ändrar arkitekturen i stället för att kämpa mot ingångspunkten. Backend behöver då ingen inkommande port på det offentliga internet alls.

Det ändrar också vad du driftar. Frontend äger offentlig TLS, åtkomstpolicy, loggar och tillgänglighet, och den måste begränsa backend-valet till den avsedda tjänsten. Om hoppet från frontend till backend använder HTTPS, behåll certifikatvalideringen på det hoppet.

Behåll ett ursprung

Frontendens offentliga värdnamn, schema och port utgör det ursprung besökare använder, så konfigurera applikationens externa URL, omdirigeringar och cookies för det ursprunget. Skicka den ursprungliga värden och det vidarebefordrade schemat om applikationen bygger absoluta länkar. Ett svar som skickar tillbaka användare till ett privat namn eller en hög port förstör den rena ingång du just byggde.

Bestäm dig sedan med publiken i åtanke. En kort URL kan motivera en hanterad frontend, och det är inte värt att av misstag göra en privat tjänst bara för VPN till en offentlig.