Ett dedikerat VPN-IP publicerar inte din webbplats
En dedikerad utgående adress säger ingenting om inkommande leverans. Kontrollera vidarebefordringsavtalet, slutför ursprungssidan och publicera sedan en hög port.
Att köpa en dedikerad IP från en VPN-leverantör känns som att köpa en ytterdörr. Adressen är stabil, tunneln är uppe, och webbplatsen laddas fortfarande inte för någon utifrån. Det du köpte är en tilldelning, inte en regel för inkommande vidarebefordran. Båda säljs i samma butik och konfigureras på helt olika ställen.
Adressen är en tilldelning, inte en vidarebefordringsregel
Anteckna den inkommande offentliga adressen eller värdnamnet, det tillåtna transportprotokollet, den tilldelade externa porten och klientmålet som leverantören levererar till. Bekräfta sedan att servern, protokollet och kontofunktionen du valde verkligen stöder vidarebefordran och att leverantören tillåter hosting på den.
Dedikerad beskriver adresstilldelningen. Det betyder inte att oönskad inkommande trafik är tillåten, och olika tillägg från samma operatör kan ha olika förmågor. Den dedikerade adressen och produkten dedikerad server är de två etiketter som oftast blandas ihop, och supportsidorna brukar ange vilken av dem som vidarebefordrar.
| 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 |
Ett illustrativt avtal ser ut så här: leverantören levererar TCP 203.0.113.60:45000 till HTTPS-tjänsten på din anslutna enhet på port 8443. Det beskriver en mappning som någon annan har konfigurerat, inte en regel du kan skapa vid deras kant genom att skriva in den i din egen brandvägg.
Slutför ursprungssidan
Om webbapplikationen körs på själva VPN-klienten behöver den en lyssnare på den levererade porten och en begränsad behörighet för lokalt indata på den porten. Om klienten vidarebefordrar den mappade anslutningen till en annan värd behöver den målöversättning, vidarebefordringspolicy och en svarsväg som klarar fram- och återresan.
Utforma åtkomstreglerna kring den källadress som leverantörens väg faktiskt presenterar. Det är inte alltid den ursprungliga besökaren, och inte alltid VPN-servern heller, vilket spelar roll när du skriver en regel som bara en av dessa adresser skulle matcha.
Portöversättning gör inte heller HTTPS av HTTP. Den offentliga porten och den lokala applikationsporten får skilja sig fritt, men schemat, certifikatets identitet och omdirigeringarna måste fortfarande stämma med tjänsten som folk faktiskt når. Om certifikatet anger den offentliga värden ska du behålla det namnet på varje hopp. En avvikelse här syns som en webbläsarvarning och inte som ett routingfel, vilket skickar folk till fel loggar i en timme.
Publicera den höga porten ärligt
Om besökare ansluter direkt och leverantören tilldelade en hög port ska du ge dem hela URL:en. En vanlig DNS-adresspost kan inte lägga till en port på en HTTPS-förfrågan som som standard använder 443, och ingen TTL-justering ändrar det.
En webbfrontend kan lösa detta genom att ta emot besökare på den vanliga porten och själv ansluta till den vidarebefordrade ursprungsporten. Cloudflares standardproxyportar är dock en definierad lista, och en godtyckligt tilldelad port blir inte en stödd kantport bara för att du lade till en proxyad DNS-post.
Att ändra ursprungets målport är en annan åtgärd än att ändra besökarens port. Cloudflares Origin Rules dokumenterar en åsidosättning av målporten för backend-anslutningen, begränsad till en stödd regel, ett schema och ett värdnamn. En portöverskridning är inte en allmän relä för godtycklig UDP eller andra protokoll.
När en frontend avslutar TLS ska du validera båda hoppen: certifikatet från webbläsaren till frontend och anslutningen från frontend till ursprunget. VPN-hoppet ersätter ingen av de två kontrollerna, och en intern adress som läcker ut i omdirigeringar eller cookies är det vanliga tecknet på att bara en av de två konfigurerades med det offentliga namnet i åtanke.
Håll mappningen levande
Vissa leverantörer tilldelar en annan port efter en återanslutning, och en leasad mappning kan kräva förnyelse genom en åtgärd på leverantörens sida. Följ mekanismen som din leverantör dokumenterar, och uppdatera lyssnaren, lokala regler, DNS eller frontendregeln bara där det nuvarande avtalet kräver det.
En statisk offentlig adress gör inte portleasingen statisk. En adress och port som fortfarande visas i en instrumentpanel är inte bevis för att den aktiva sessionen äger mappningen, därför är testet en färsk förfrågan utifrån och inte en skärmbild.
Upprepa sedan fallen du förväntar dig: en normal återanslutning och en VPN-förlust. Om förlusten ska göra ursprunget otillgängligt ska du inte låta en uppdaterare tyst publicera om en direkt ISP-väg i bakgrunden. Och om vidarebefordringsavtalet inte kan uppfylla webbplatsens stabilitetskrav ska du välja en annan publiceringsordning i stället för att köpa ännu en adressetikett och hoppas att den beter sig som en server.