A dedikált VPN-IP nem teszi közzé a webhelyét
A dedikált kilépési cím semmit sem mond a bejövő kézbesítésről. Ellenőrizze a továbbítási szerződést, fejezze be az eredet oldalát, majd tegyen közzé egy magas portot.
Dedikált IP-t vásárolni egy VPN-szolgáltatótól olyan, mint bejárati ajtót venni. A cím stabil, az alagút él, a webhely mégsem tölt be senkinek kívülről. Amit vásárolt, az egy címkiosztás, nem bejövő továbbítási szabály. Mindkettőt ugyanabban a boltban árulják, és teljesen más helyeken állítják be.
A cím kiosztás, nem továbbítási szabály
Jegyezze fel a bejövő nyilvános címet vagy gépnevet, az engedélyezett átvitelt, a kiosztott külső portot és az ügyféloldali célt, ahová a szolgáltató kézbesít. Ezután erősítse meg, hogy a választott kiszolgáló, protokoll és fiókfunkció valóban támogatja a továbbítást, és hogy a szolgáltató engedélyezi rajta a tárhelyszolgáltatást.
A dedikált szó a címkiosztást írja le. Nem jelenti azt, hogy a kéretlen bejövő forgalom engedélyezett, és ugyanazon szolgáltató különböző bővítményeinek eltérő képességei lehetnek. A dedikált cím és a dedikált kiszolgáló termék az a két címke, amelyet a legtöbbször összekevernek, és a támogatási oldalak általában megmondják, melyik továbbít.
| 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 |
Egy szemléltető szerződés így néz ki: a szolgáltató TCP-t kézbesít a 203.0.113.60:45000 címen a csatlakoztatott eszköz HTTPS-szolgáltatásának a 8443-as porton. Ez egy másvalaki által beállított leképezés leírása, nem olyan szabály, amelyet a saját tűzfalába beírva hozhatna létre az ő peremükön.
Fejezze be az eredet oldalát
Ha a webalkalmazás magán a VPN-ügyfélen fut, szüksége van egy figyelőre a kézbesített porton, és ehhez a porthoz korlátozott helyi bemeneti engedélyre. Ha az ügyfél a leképezett kapcsolatot egy másik gazdagéphez továbbítja, szüksége van a célfordításra, a továbbítási szabályzatra és egy válaszútra, amely kibírja az oda-vissza utat.
A hozzáférési szabályokat ahhoz a forráscímhez igazítsa, amelyet a szolgáltatói útvonal valóban mutat. Ez nem mindig az eredeti látogató, és nem is mindig a VPN-kiszolgáló, ami számít, amikor olyan szabályt ír, amelyre csak e címek egyike illeszkedne.
A portfordítás sem alakítja át a HTTP-t HTTPS-sé. A nyilvános port és a helyi alkalmazásport szabadon eltérhet, de a séma, a tanúsítvány identitása és az átirányítások továbbra is meg kell feleljenek annak a szolgáltatásnak, amelyet az emberek ténylegesen elérnek. Ha a tanúsítvány a nyilvános gazdagépet nevezi meg, minden ugrásnál tartsa meg ezt a nevet. Az itteni eltérés böngészőfigyelmeztetésként jelenik meg, nem útválasztási hibaként, ami egy órára a rossz naplókhoz küldi az embereket.
Tegye közzé a magas portot őszintén
Ha a látogatók közvetlenül csatlakoznak, és a szolgáltató magas portot osztott ki, adja meg nekik a teljes URL-t. Egy közönséges DNS-címrekord nem tud portot hozzáfűzni egy HTTPS-kéréshez, amely alapértelmezés szerint a 443-at használja, és ezen semmilyen TTL-hangolás nem változtat.
Egy webes frontend ezt úgy oldhatja meg, hogy a látogatókat a szokásos porton fogadja, és saját kapcsolatot létesít a továbbított eredeti port felé. A Cloudflare alapértelmezett proxyportjai azonban meghatározott lista, és egy önkényesen kiosztott port nem válik támogatott peremporttá attól, hogy proxizott DNS-rekordot adott hozzá.
Az eredeti célportjának módosítása más művelet, mint a látogatói port módosítása. A Cloudflare Origin Rules dokumentációja a háttérkapcsolat célport-felülírását írja le, támogatott szabályra, sémára és gépnévre korlátozva. A portfelülírás nem általános átjátszó tetszőleges UDP-hez vagy más protokollokhoz.
Amikor egy frontend lezárja a TLS-t, mindkét ugrást ellenőrizze: a böngésző és a frontend közötti tanúsítványt, valamint a frontend és az eredet közötti kapcsolatot. A VPN-ugrás egyiket sem pótolja, és a belső cím átirányításokba vagy sütikbe szivárgása a szokásos jele annak, hogy a kettő közül csak az egyiket állították be a nyilvános névre gondolva.
Tartsa életben a leképezést
Egyes szolgáltatók újracsatlakozás után más portot osztanak ki, és a bérelt leképezés megújítást igényelhet egy szolgáltatóoldali művelettel. Kövesse a szolgáltatója által dokumentált mechanizmust, és csak ott frissítse a figyelőt, a helyi szabályokat, a DNS-t vagy a frontendszabályt, ahol az aktuális szerződés megköveteli.
A statikus nyilvános cím nem teszi statikussá a portbérletet. Az irányítópulton még látható cím és port nem bizonyítja, hogy az élő munkamenet birtokolja a leképezést, ezért a teszt egy kívülről érkező friss kérés, nem képernyőkép.
Ezután ismételje meg a várt eseteket: egy normál újracsatlakozást és egy VPN-kiesést. Ha a kiesésnek elérhetetlenné kell tennie az eredetit, ne engedje, hogy egy frissítő csendben újraközöljön egy közvetlen ISP-útvonalat a háttérben. És ha a továbbítási szerződés nem tudja teljesíteni a webhely stabilitási követelményeit, válasszon más közzétételi elrendezést, ahelyett hogy újabb címkét vásárolna, és abban reménykedne, hogy kiszolgálóként viselkedik.