Un IP VPN dedicato non pubblica il tuo sito web
Un indirizzo di uscita dedicato non dice nulla sulla consegna in entrata. Controlla il contratto di inoltro, completa il lato origine, poi pubblica una porta alta.
Comprare un IP dedicato da un fornitore VPN sembra comprare una porta d’ingresso. L’indirizzo è stabile, il tunnel è attivo, e il sito continua a non caricarsi per nessuno all’esterno. Quello che hai comprato è un’assegnazione, non una regola di inoltro in entrata. Entrambe si vendono nello stesso negozio e si configurano in luoghi completamente diversi.
L’indirizzo è un’assegnazione, non una regola di inoltro
Annota l’indirizzo pubblico in entrata o il nome host, il trasporto consentito, la porta esterna assegnata e la destinazione lato client a cui il fornitore consegna. Poi conferma che il server, il protocollo e la funzione dell’account che hai scelto supportino davvero l’inoltro e che il fornitore consenta l’hosting su di esso.
Dedicato descrive l’assegnazione dell’indirizzo. Non significa che il traffico in entrata non richiesto sia consentito, e componenti aggiuntivi diversi dello stesso operatore possono avere capacità diverse. L’indirizzo dedicato e il prodotto server dedicato sono le due etichette che si confondono più spesso, e le pagine di assistenza di solito chiariscono quale delle due inoltra.
| What you have | What it gives you | What it does not |
|---|---|---|
| Dedicated exit address | A stable source address for outbound traffic | Any inbound delivery at all |
| Port-forwarding add-on | A provider-side mapping to your session | Permanence across reconnects |
| Local DNAT rule | Handling for packets that arrive | Making packets arrive |
Un contratto illustrativo è così: il fornitore consegna TCP 203.0.113.60:45000 al servizio HTTPS del tuo dispositivo connesso sulla porta 8443. È la descrizione di una mappatura configurata da qualcun altro, non una regola che puoi creare al loro bordo digitandola nel tuo firewall.
Completa il lato origine
Se l’applicazione web gira sul client VPN stesso, ha bisogno di un listener sulla porta consegnata e di un’autorizzazione limitata all’input locale per quella porta. Se il client inoltra la connessione mappata a un altro host, ha bisogno della traduzione della destinazione, della politica di inoltro e di un percorso di risposta che regga l’andata e il ritorno.
Progetta le regole di accesso intorno all’indirizzo di origine che il percorso del fornitore presenta davvero. Non è sempre il visitatore originale, e non è sempre nemmeno il server VPN, il che conta quando scrivi una regola a cui corrisponderebbe solo uno di quegli indirizzi.
Anche la traduzione delle porte non trasforma HTTP in HTTPS. La porta pubblica e la porta locale dell’applicazione possono differire liberamente, ma lo schema, l’identità del certificato e i reindirizzamenti devono comunque corrispondere al servizio che le persone raggiungono davvero. Se il certificato indica l’host pubblico, mantieni quel nome a ogni passaggio. Un’incoerenza qui si manifesta come avviso del browser e non come errore di instradamento, il che manda le persone nei registri sbagliati per un’ora.
Pubblica la porta alta con onestà
Se i visitatori si connettono direttamente e il fornitore ha assegnato una porta alta, dai loro l’URL completo. Un normale record di indirizzo DNS non può aggiungere una porta a una richiesta HTTPS che usa 443 per impostazione predefinita, e nessun ritocco del TTL lo cambia.
Un frontend web può risolverlo accettando i visitatori sulla porta abituale e aprendo una propria connessione alla porta di origine inoltrata. Le porte proxy predefinite di Cloudflare sono però un elenco definito, e una porta assegnata arbitrariamente non diventa una porta perimetrale supportata solo perché hai aggiunto un record DNS proxato.
Cambiare la porta di destinazione dell’origine è un’operazione diversa dal cambiare la porta del visitatore. Le Origin Rules di Cloudflare documentano una sostituzione della porta di destinazione per la connessione al backend, limitata a una regola, uno schema e un nome host supportati. Una sostituzione di porta non è un relè generico per UDP arbitrario o per altri protocolli.
Quando un frontend termina il TLS, convalida entrambi i passaggi: il certificato dal browser al frontend e la connessione dal frontend all’origine. Il passaggio VPN non sostituisce nessuno dei due controlli, e la fuga di un indirizzo interno nei reindirizzamenti o nei cookie è il segno abituale che solo uno dei due è stato configurato pensando al nome pubblico.
Mantieni viva la mappatura
Alcuni fornitori assegnano una porta diversa dopo una riconnessione, e una mappatura noleggiata può richiedere un rinnovo tramite un’azione lato fornitore. Segui il meccanismo documentato dal tuo fornitore e aggiorna il listener, le regole locali, il DNS o la regola del frontend solo dove il contratto attuale lo richiede.
Un indirizzo pubblico statico non rende statico il noleggio della porta. Un indirizzo e una porta ancora mostrati in una dashboard non provano che la sessione attiva possieda la mappatura, per questo il test è una richiesta nuova dall’esterno e non uno screenshot.
Poi ripeti i casi che ti aspetti: una riconnessione normale e una perdita di VPN. Se la perdita deve rendere l’origine irraggiungibile, non lasciare che un aggiornatore ripubblichi silenziosamente un percorso ISP diretto in background. E se il contratto di inoltro non può soddisfare i requisiti di stabilità del sito, scegli un’altra disposizione di pubblicazione invece di comprare un’altra etichetta di indirizzo e sperare che si comporti come un server.