En dedikert VPN-IP publiserer ikke nettstedet ditt
En dedikert utgangsadresse sier ingenting om innkommende levering. Kontroller videresendingsavtalen, fullfør opphavssiden og publiser deretter en høy port.
Å kjøpe en dedikert IP fra en VPN-leverandør føles som å kjøpe en inngangsdør. Adressen er stabil, tunnelen er oppe, og nettstedet lastes fortsatt ikke for noen utenfra. Det du kjøpte, er en tildeling, ikke en regel for innkommende videresending. Begge selges i samme butikk og konfigureres på helt forskjellige steder.
Adressen er en tildeling, ikke en videresendingsregel
Noter den innkommende offentlige adressen eller vertsnavnet, transporten som er tillatt, den tildelte eksterne porten og klientmålet leverandøren leverer til. Bekreft deretter at serveren, protokollen og kontofunksjonen du valgte faktisk støtter videresending, og at leverandøren tillater hosting på den.
Dedikert beskriver adressetildeling. Det betyr ikke at uoppfordret innkommende trafikk er tillatt, og ulike tillegg fra samme operatør kan ha forskjellige egenskaper. Den dedikerte adressen og produktet dedikert server er de to etikettene folk oftest blander sammen, og støttesidene pleier å si hvilken av dem som videresender.
| 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 |
En illustrerende avtale ser slik ut: leverandøren leverer TCP 203.0.113.60:45000 til HTTPS-tjenesten på den tilkoblede enheten din på port 8443. Det er en beskrivelse av en tilordning noen andre har konfigurert, ikke en regel du kan opprette på deres kant ved å skrive den inn i din egen brannmur.
Fullfør opphavssiden
Hvis webapplikasjonen kjører på VPN-klienten selv, trenger den en lytter på den leverte porten og en begrenset tillatelse for lokalt inndata på den porten. Hvis klienten videresender den tilordnede forbindelsen til en annen vert, trenger den måloversettelse, videresendingspolicy og en svarvei som tåler turen frem og tilbake.
Design tilgangsreglene rundt kildeadressen som leverandørveien faktisk presenterer. Det er ikke alltid den opprinnelige besøkende, og det er heller ikke alltid VPN-serveren, noe som betyr noe når du skriver en regel som bare én av disse adressene ville passe på.
Portoversettelse gjør heller ikke HTTP om til HTTPS. Den offentlige porten og den lokale applikasjonsporten kan fritt være forskjellige, men skjemaet, sertifikatets identitet og omdirigeringene må fortsatt stemme med tjenesten folk faktisk når. Hvis sertifikatet nevner den offentlige verten, hold det navnet på hvert hopp. Et avvik her vises som en nettleseradvarsel og ikke som en rutingsfeil, noe som sender folk til feil logger i en time.
Publiser den høye porten ærlig
Hvis besøkende kobler til direkte og leverandøren tildelte en høy port, gi dem hele URL-en. En vanlig DNS-adressepost kan ikke legge til en port på en HTTPS-forespørsel som som standard bruker 443, og ingen TTL-justering endrer det.
En webfrontend kan løse dette ved å ta imot besøkende på den vanlige porten og lage sin egen forbindelse til den videresendte opphavsporten. Cloudflares standard proxy-porter er imidlertid en definert liste, og en vilkårlig tildelt port blir ikke en støttet kantport fordi du la til en proxyet DNS-post.
Å endre opphavets målport er en annen operasjon enn å endre besøkendens port. Cloudflares Origin Rules dokumenterer en overstyring av målporten for backend-forbindelsen, begrenset til en støttet regel, skjema og vertsnavn. En portoverstyring er ikke et generelt relé for vilkårlig UDP eller andre protokoller.
Når en frontend avslutter TLS, valider begge hoppene: sertifikatet fra nettleseren til frontend og forbindelsen fra frontend til opphavet. VPN-hoppet erstatter ingen av de to kontrollene, og en intern adresse som lekker ut i omdirigeringer eller informasjonskapsler er det vanlige tegnet på at bare én av de to ble konfigurert med det offentlige navnet i tankene.
Hold tilordningen i live
Noen leverandører tildeler en annen port etter en gjenoppkobling, og en leid tilordning kan kreve fornyelse gjennom en handling på leverandørens side. Følg mekanismen leverandøren din dokumenterer, og oppdater lytteren, lokale regler, DNS eller frontendregelen bare der den gjeldende avtalen krever det.
En statisk offentlig adresse gjør ikke portleien statisk. En adresse og port som fortsatt vises i et dashbord er ikke bevis for at den aktive økten eier tilordningen, og derfor er testen en fersk forespørsel utenfra i stedet for et skjermbilde.
Gjenta så tilfellene du forventer: en normal gjenoppkobling og et VPN-tap. Hvis tapet skal gjøre opphavet utilgjengelig, ikke la en oppdaterer i det stille publisere en direkte ISP-vei på nytt i bakgrunnen. Og hvis videresendingsavtalen ikke kan oppfylle nettstedets stabilitetskrav, velg en annen publiseringsordning i stedet for å kjøpe nok en adresseetikett og håpe den oppfører seg som en server.