’n Toegewyde VPN-IP publiseer nie jou webwerf nie
’n Toegewyde uitgangsadres sê niks oor inkomende aflewering nie. Kontroleer die deurstuur-kontrak, maak die oorsprongkant klaar en publiseer dan ’n hoë poort.
Om ’n toegewyde IP by ’n VPN-verskaffer te koop voel soos om ’n voordeur te koop. Die adres is stabiel, die tonnel is op, en die webwerf laai steeds nie vir enigiemand buite nie. Wat jy gekoop het, is ’n toewysing, nie ’n inkomende deurstuur-reël nie. Albei word in dieselfde winkel verkoop en op heeltemal verskillende plekke opgestel.
Die adres is ’n toewysing, nie ’n deurstuur-reël nie
Teken die inkomende publieke adres of gasheernaam aan, die toegelate transport, die toegewysde eksterne poort en die kliëntkant-bestemming waarnatoe die verskaffer aflewer. Bevestig dan dat die bediener, protokol en rekeningfunksie wat jy gekies het, werklik deurstuur ondersteun, en dat die verskaffer gasheer daarop toelaat.
Toegewys beskryf adrestoewysing. Dit beteken nie dat ongevraagde inkomende verkeer toegelaat word nie, en verskillende byvoegings van dieselfde operateur kan verskillende vermoëns hê. Die toegewyde adres en die toegewyde bediener-produk is die twee etikette wat mense die meeste verwar, en die ondersteuningsbladsye spel gewoonlik uit watter een deurstuur.
| 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 |
’n Voorbeeldkontrak lyk so: die verskaffer lewer TCP 203.0.113.60:45000 aan jou gekoppelde toestel se HTTPS-diens op poort 8443. Dit is ’n beskrywing van ’n koppeling wat iemand anders opgestel het, nie ’n reël wat jy by hul rand kan skep deur dit in jou eie firewall te tik nie.
Maak die oorsprongkant klaar
As die webtoepassing op die VPN-kliënt self loop, het dit ’n luisteraar op die afgelewerde poort nodig en ’n beperkte plaaslike-invoer-toestemming vir daardie poort. As die kliënt die gekoppelde verbinding na ’n ander gasheer deurstuur, het dit die bestemmingvertaling, die deurstuurbeleid en ’n antwoordpad nodig wat die rondreis oorleef.
Ontwerp toegangsreëls rondom die bronadres wat die verskafferpad werklik aanbied. Dit is nie altyd die oorspronklike besoeker nie, en dit is ook nie altyd die VPN-bediener nie, wat saak maak wanneer jy ’n reël skryf waarop net een van daardie adresse sou pas.
Poortvertaling skakel ook nie HTTP na HTTPS oor nie. Die publieke poort en die plaaslike toepassingpoort kan vry verskil, maar die skema, sertifikaatidentiteit en aansturings moet steeds pas by die diens wat mense werklik bereik. As die sertifikaat die publieke gasheer noem, hou dit so op elke sprong. ’n Wanpassing hier wys as ’n blaaierwaarskuwing eerder as ’n roetefout, wat mense vir ’n uur na die verkeerde logs stuur.
Publiseer die hoë poort eerlik
As besoekers direk koppel en die verskaffer het ’n hoë poort toegewys, gee hulle die volledige URL. ’n Gewone DNS-adresrekord kan nie ’n poort by ’n HTTPS-versoek voeg wat by verstek 443 gebruik nie, en geen TTL-verstelling verander dit nie.
’n Webfrontend kan dit oplos deur besoekers op die gewone poort te aanvaar en sy eie verbinding na die doorgestuurde oorsprongpoort te maak. Cloudflare se verstek-proxy-poorte is egter ’n vasgestelde lys, en ’n willekeurige toegewysde poort word nie ’n ondersteunde randpoort omdat jy ’n proxy-DNS-rekord bygevoeg het nie.
Om die oorsprong-bestemmingpoort te verander is ’n ander operasie as om die besoekerpoort te verander. Cloudflare se Origin Rules dokumenteer ’n bestemmingpoort-oorheersing vir die backend-verbinding, beperk tot ’n ondersteunde reël, skema en gasheernaam. ’n Poortoorheersing is nie ’n algemene aflos vir willekeurige UDP of ander protokolle nie.
Wanneer ’n frontend TLS termineer, valideer albei spronge: die blaaier-tot-frontend-sertifikaat en die frontend-tot-oorsprong-verbinding. Die VPN-sprong vervang nie een van die twee kontroles nie, en ’n interne adres wat in aansturings of koekies lek, is die gewone teken dat net een van die twee met die publieke naam in gedagte opgestel is.
Hou die koppeling lewendig
Sommige verskaffers ken ’n ander poort toe ná ’n herverbinding, en ’n gehuurde koppeling kan vernuwing deur ’n verskafferaksie vereis. Volg die meganisme wat jou verskaffer dokumenteer, en werk die luisteraar, plaaslike reëls, DNS of frontend-reël net by waar die huidige kontrak dit vereis.
’n Statiese publieke adres maak nie die poort huurkontrak staties nie. ’n Adres en poort wat nog in ’n paneel wys, is nie bewys dat die lewendige sessie die koppeling besit nie, daarom is die toets ’n vars versoek van buite eerder as ’n skermkiekie.
Herhaal dan die gevalle wat jy verwag: ’n normale herverbinding en ’n VPN-verlies. As verlies die oorsprong onbeskikbaar moet maak, moenie toelaat dat ’n opdaterer stilweg ’n direkte ISP-pad in die agtergrond herpubliseer nie. En as die deurstuur-kontrak nie die werf se stabiliteitsvereistes kan nakom nie, kies ’n ander publikasie-reëling eerder as om nog ’n adresetiket te koop en te hoop dit gedra hom soos ’n bediener.