Dediĉita VPN-IP ne publikigas vian retejon
Dediĉita elira adreso diras nenion pri envena livero. Kontrolu la transsendan kontrakton, finu la originan flankon, poste publikigu altan pordon.
Aĉeti dediĉitan IP ĉe VPN-provizanto sentiĝas kiel aĉeti antaŭpordon. La adreso estas stabila, la tunelo funkcias, kaj tamen la retejo ne ŝargiĝas por iu ajn ekstere. Tio, kion vi aĉetis, estas atribuo, ne regulo por envena transsendo. Ambaŭ estas vendataj en la sama butiko kaj agordataj en tute malsamaj lokoj.
La adreso estas atribuo, ne transsenda regulo
Notu la envenan publikan adreson aŭ gastigantan nomon, la permesitan transporton, la atribuitan eksteran pordon kaj la klientflankan celon, al kiu la provizanto liveras. Poste konfirmu, ke la servilo, protokolo kaj konta funkcio, kiujn vi elektis, vere subtenas transsendon, kaj ke la provizanto permesas gastigadon sur ĝi.
Dediĉita priskribas adresan atribuon. Ĝi ne signifas, ke malpetita envena trafiko estas permesata, kaj malsamaj aldonaĵoj de la sama funkciigisto povas havi malsamajn kapablojn. La dediĉita adreso kaj la produkto dediĉita servilo estas la du etikedoj, kiujn homoj plej ofte konfuzas, kaj la subtenaj paĝoj kutime klarigas, kiu el ili transsendas.
| 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 |
Ilustra kontrakto aspektas tiel: la provizanto liveras TCP 203.0.113.60:45000 al la HTTPS-servo de via konektita aparato sur pordo 8443. Tio estas priskribo de mapado, kiun agordis iu alia, ne regulo, kiun vi povas krei ĉe ilia rando tajpante ĝin en vian propran fajroŝirmilon.
Finu la originan flankon
Se la reta aplikaĵo funkcias sur la VPN-kliento mem, ĝi bezonas aŭskultanton sur la liverita pordo kaj limigitan permeson por loka enigo sur tiu pordo. Se la kliento transsendas la mapitan konekton al alia gastiganto, ĝi bezonas la celan tradukon, la transsendan politikon kaj respondan vojon, kiu eltenas la rondvojaĝon.
Projektu alirregulojn ĉirkaŭ la fonta adreso, kiun la provizanta vojo efektive prezentas. Ĝi ne ĉiam estas la origina vizitanto, kaj ĝi ankaŭ ne ĉiam estas la VPN-servilo, kio gravas kiam vi skribas regulon, kiun nur unu el tiuj adresoj kongruus.
Pordotraduko ankaŭ ne konvertas HTTP al HTTPS. La publika pordo kaj la loka aplikaĵa pordo povas libere malsami, sed la skemo, la identeco de la atestilo kaj la alidirektadoj ankoraŭ devas kongrui kun la servo, kiun homoj efektive atingas. Se la atestilo nomas la publikan gastiganton, konservu tiun nomon ĉe ĉiu salto. Miskongruo ĉi tie aperas kiel retumila averto anstataŭ kiel eraro de enkursigo, kio sendas homojn al la malĝustaj protokoloj por horo.
Publikigu la altan pordon honeste
Se vizitantoj konektiĝas rekte kaj la provizanto atribuis altan pordon, donu al ili la plenan URL-on. Ordinara DNS-adresa rikordo ne povas aldoni pordon al HTTPS-peto, kiu defaŭlte uzas 443, kaj nenia TTL-agordo ŝanĝas tion.
Reta fronto povas solvi tion akceptante vizitantojn sur la kutima pordo kaj farante sian propran konekton al la transsendita origina pordo. Tamen la defaŭltaj prokuraj pordoj de Cloudflare estas difinita listo, kaj arbitre atribuita pordo ne fariĝas subtenata randa pordo nur ĉar vi aldonis prokuran DNS-rikordon.
Ŝanĝi la celan pordon de la origino estas alia operacio ol ŝanĝi la pordon de la vizitanto. La Origin Rules de Cloudflare dokumentas anstataŭigon de la cela pordo por la malantaŭa konekto, limigita al subtenata regulo, skemo kaj gastiganta nomo. Porda anstataŭigo ne estas ĝenerala relajso por arbitra UDP aŭ aliaj protokoloj.
Kiam fronto finas TLS, validigu ambaŭ saltojn: la atestilon de la retumilo al la fronto kaj la konekton de la fronto al la origino. La VPN-salto anstataŭas neniun el la du kontroloj, kaj ena adreso likanta en alidirektadojn aŭ kuketojn estas la kutima signo, ke nur unu el la du estis agordita kun la publika nomo en la kapo.
Tenu la mapadon viva
Iuj provizantoj atribuas alian pordon post rekonekto, kaj luigita mapado povas postuli renovigon per ago ĉe la provizanto. Spuru la mekanismon, kiun via provizanto dokumentas, kaj ĝisdatigu la aŭskultanton, lokajn regulojn, DNS aŭ la frontan regulon nur tie, kie la nuna kontrakto tion postulas.
Statika publika adreso ne faras la pordan luon statika. Adreso kaj pordo ankoraŭ montrataj en panelo ne pruvas, ke la viva seanco posedas la mapadon, tial la testo estas freŝa peto ekstere anstataŭ ekrankopio.
Poste ripetu la kazojn, kiujn vi atendas: normalan rekonekton kaj perdon de VPN. Se la perdo devas igi la originon neatingebla, ne lasu ĝisdatigilon trankvile republikigi rektan ISP-vojon en la fono. Kaj se la transsenda kontrakto ne povas plenumi la stabilecajn postulojn de la retejo, elektu alian publikigan aranĝon anstataŭ aĉeti plian adresan etikedon kaj esperi, ke ĝi kondutos kiel servilo.