Per què la teva URL necessita una entrada al port 80 o 443, no al 45000

Escriu un nom d’amfitrió en un navegador i l’esquema decideix el port de destinació: 80 per a http, 443 per a https. Res en una resposta DNS ho anul·la, i cap regla de reenviament a la teva màquina no pot inventar un oient a la vora del proveïdor. Quan un proveïdor de VPN et dona un port públic alt com el 45000, una URL explícita funciona i una de neta no. El buit és al punt d’entrada, no dins de l’aplicació.

Recorre el camí del navegador al procés una vegada, i les tres opcions de publicació deixaran de semblar misterioses.

Mira on va realment la petició

El navegador resol el nom a una adreça i després es connecta a aquesta adreça al port per defecte de l’esquema, tret que la URL n’anomeni un altre. La vora del teu proveïdor decideix què passa amb la connexió entrant. Si la seva taula de reenviament només assigna el 45000 a la teva adreça interna, una connexió al 80 no té on anar i es refusa o es descarta abans que la teva màquina hi participi.

Aquest refús passa a la vora, i per això els registres de la teva aplicació no mostren res. L’absència de registres és una prova de on es va aturar el paquet, no una prova que l’aplicació estigui espatllada.

Per què una regla local no pot arreglar la vora

Una redirecció o una regla DNAT a l’amfitrió de l’aplicació actua sobre paquets que ja han arribat. Els paquets enviats al port 80 del proveïdor no arriben mai, així que la regla no s’avalua mai. Aquesta és l’hora més malgastada de tot el problema.

DNS tampoc no pot portar el port. especificació HTTP defineix els valors per defecte de l’esquema, i un registre A o AAAA retorna una adreça mentre que un CNAME retorna un altre nom. El navegador encara concatena el port de l’esquema, així que només un port explícit a la URL canvia la destinació.

Opció primera: conservar el port explícit

Sovint la resposta correcta és la poc glamurosa. Publica la URL completa amb el port, acaba TLS en una entrada que ho admeti i assegura’t que cada enllaç generat mantingui el mateix origen. Per a un públic petit i controlat això és complet, i no costa res més enllà d’un número de port visible.

Comprova les redireccions i l’abast de les galetes mentre hi ets, perquè un backend que escriu el seu propi nom d’amfitrió a la capçalera Location desfà l’arranjament.

Opció segona: aconseguir una entrada real al port per defecte

Alguns proveïdors i solucions d’allotjament reenvien el 80 i el 443 en una adreça compartida o dedicada com a servei documentat. Pregunta què s’inclou realment en lloc de suposar que una adreça de sortida pública implica ports entrants arbitraris. Una adreça de sortida dedicada no diu res sobre el reenviament entrant.

Confirma la propietat i la disponibilitat per escrit, incloent-hi què passa amb l’entrada quan el túnel es reconnecta amb una adreça diferent. Una entrada que es mou amb el túnel produeix caigudes que semblen errors de DNS.

Opció tercera: posar un frontal al davant

Un proxy invers en una adreça accessible pot escoltar al 443 i acabar TLS i obrir una connexió separada amb el backend a través de la VPN. Els visitants veuen el nom i el port per defecte del frontal, mentre que el frontal parla amb el port alt del backend en nom teu. Això funciona perquè canvia l’arquitectura en lloc de lluitar contra el punt d’entrada. Llavors el backend no necessita cap port entrant a la internet pública.

També canvia què operes. El frontal posseeix el TLS públic, la política d’accés, els registres i la disponibilitat, i ha de limitar la selecció de backend al servei previst. Si el salt del frontal al backend fa servir HTTPS, mantén la validació del certificat en aquest salt.

Mantingues un sol origen

El nom d’amfitrió públic, l’esquema i el port del frontal formen l’origen que fan servir els visitants, així que configura la URL externa de l’aplicació, les redireccions i les galetes per a aquest origen. Envia l’amfitrió original i l’esquema reenviat si l’aplicació construeix enllaços absoluts. Una resposta que fa tornar els usuaris a un nom privat o a un port alt desfà l’entrada neta que acabes de construir.

Després decideix pensant en el públic. Una URL curta pot justificar un frontal gestionat, i no val la pena convertir per accident un servei privat només per a VPN en un de públic.