Perché il tuo URL ha bisogno di una voce sulla porta 80 o 443, non sulla 45000

Digita un nome host in un browser e lo schema decide la porta di destinazione: 80 per http, 443 per https. Niente in una risposta DNS lo sovrascrive, e nessuna regola di inoltro sulla tua macchina può inventare un listener al bordo del provider. Quando un provider VPN ti assegna una porta pubblica alta come 45000, un URL esplicito funziona e uno pulito no. Il divario sta nel punto d’ingresso, non dentro l’applicazione.

Ripercorri una volta il percorso dal browser al processo, e le tre opzioni di pubblicazione smettono di sembrare misteriose.

Guarda dove va davvero la richiesta

Il browser risolve il nome in un indirizzo, poi si connette a quell’indirizzo sulla porta predefinita dello schema, a meno che l’URL non ne indichi un’altra. Il bordo del tuo provider decide cosa accade alla connessione in arrivo. Se la sua tabella di inoltro mappa solo 45000 al tuo indirizzo interno, una connessione alla 80 non ha dove andare e viene rifiutata o scartata prima che la tua macchina sia coinvolta.

Quel rifiuto avviene al bordo, per questo i log della tua applicazione non mostrano nulla. L’assenza di log è una prova di dove si è fermato il pacchetto, non una prova che l’applicazione sia rotta.

Perché una regola locale non può riparare il bordo

Un reindirizzamento o una regola DNAT sull’host dell’applicazione agisce sui pacchetti già arrivati. I pacchetti inviati alla porta 80 presso il provider non arrivano mai, quindi la regola non viene mai valutata. Questa è l’ora più spesso sprecata dell’intero problema.

Nemmeno DNS può trasportare la porta. specifica HTTP definisce i valori predefiniti dello schema, e un record A o AAAA restituisce un indirizzo mentre un CNAME restituisce un altro nome. Il browser concatena comunque la porta dello schema, quindi solo una porta esplicita nell’URL cambia la destinazione.

Opzione uno: mantenere la porta esplicita

Spesso la risposta corretta è quella poco appariscente. Pubblica l’URL completo con la porta, termina TLS su una voce che lo supporta e assicurati che ogni link generato mantenga la stessa origine. Per un pubblico piccolo e controllato questo è completo, e non costa nulla oltre a un numero di porta visibile.

Controlla i reindirizzamenti e l’ambito dei cookie mentre sei lì, perché un backend che scrive il proprio nome host in un’intestazione Location annulla la soluzione.

Opzione due: ottenere una vera voce sulla porta predefinita

Alcuni provider e soluzioni di hosting inoltrano 80 e 443 su un indirizzo condiviso o dedicato come servizio documentato. Chiedi cosa è realmente incluso invece di dare per scontato che un indirizzo di uscita pubblico implichi porte in ingresso arbitrarie. Un indirizzo di uscita dedicato non dice nulla sull’inoltro in ingresso.

Conferma proprietà e disponibilità per iscritto, incluso cosa succede alla voce quando il tunnel si riconnette con un indirizzo diverso. Una voce che si sposta con il tunnel produce interruzioni che sembrano errori DNS.

Opzione tre: mettere un frontend davanti

Un proxy inverso su un indirizzo raggiungibile può ascoltare sulla 443 e terminare TLS e aprire una connessione separata al backend tramite la VPN. I visitatori vedono il nome e la porta predefinita del frontend, mentre il frontend parla alla porta alta del backend per tuo conto. Funziona perché cambia l’architettura invece di combattere il punto d’ingresso. Il backend quindi non ha affatto bisogno di una porta in ingresso su internet pubblico.

Cambia anche ciò che gestisci. Il frontend possiede il TLS pubblico, la politica di accesso, i log e la disponibilità, e deve limitare la selezione del backend al servizio previsto. Se il salto dal frontend al backend usa HTTPS, mantieni la validazione del certificato su quel salto.

Mantieni una sola origine

Il nome host pubblico, lo schema e la porta del frontend formano l’origine usata dai visitatori, quindi configura l’URL esterno dell’applicazione, i reindirizzamenti e i cookie per quell’origine. Invia l’host originale e lo schema inoltrato se l’applicazione costruisce link assoluti. Una risposta che rimanda gli utenti a un nome privato o a una porta alta annulla la voce pulita che hai appena costruito.

Poi decidi pensando al pubblico. Un URL breve può giustificare un frontend gestito, e non vale la pena trasformare per errore un servizio privato solo VPN in uno pubblico.