ડેડિકેટેડ VPN IP તમારી વેબસાઇટ પ્રકાશિત કરતું નથી
ડેડિકેટેડ એક્ઝિટ સરનામું ઇનબાઉન્ડ ડિલિવરી વિશે કંઈ કહેતું નથી. ફોર્વર્ડિંગ કરાર ચકાસો, ઓરિજિન બાજુ પૂરી કરો, પછી ઊંચું પોર્ટ પ્રકાશિત કરો.
VPN પ્રદાતા પાસેથી ડેડિકેટેડ IP ખરીદવું એ આગળનું દરવાજો ખરીદવા જેવું લાગે છે. સરનામું સ્થિર છે, ટનલ ચાલુ છે, અને છતાં વેબસાઇટ બહારના કોઈને માટે લોડ થતી નથી. તમે જે ખરીદ્યું છે તે એક ફાળવણી છે, ઇનબાઉન્ડ ફોર્વર્ડિંગ નિયમ નથી. બંને એક જ દુકાનમાં વેચાય છે અને સંપૂર્ણપણે અલગ જગ્યાએ ગોઠવાય છે.
સરનામું ફાળવણી છે, ફોર્વર્ડિંગ નિયમ નથી
ઇનબાઉન્ડ જાહેર સરનામું કે હોસ્ટનામ, માન્ય ટ્રાન્સપોર્ટ, ફાળવેલ બાહ્ય પોર્ટ અને પ્રદાતા જે ક્લાયન્ટ-બાજુના ગંતવ્ય પર પહોંચાડે છે તે નોંધો. પછી ખાતરી કરો કે તમે પસંદ કરેલ સર્વર, પ્રોટોકોલ અને એકાઉન્ટ સુવિધા ખરેખર ફોર્વર્ડિંગને સમર્થન આપે છે અને પ્રદાતા તેના પર હોસ્ટિંગની પરવાનગી આપે છે.
ડેડિકેટેડ શબ્દ સરનામાની ફાળવણી વર્ણવે છે. તેનો અર્થ એ નથી કે માંગ્યા વગરનું ઇનબાઉન્ડ ટ્રાફિક માન્ય છે, અને એક જ ઓપરેટરના જુદા જુદા એડ-ઓનની ક્ષમતાઓ જુદી હોઈ શકે છે. ડેડિકેટેડ સરનામું અને ડેડિકેટેડ સર્વર ઉત્પાદન એ બે લેબલ છે જે લોકો સૌથી વધુ ભેળવી દે છે, અને સપોર્ટ પૃષ્ઠો સામાન્ય રીતે સ્પષ્ટ કરે છે કે કયું ફોર્વર્ડ કરે છે.
| 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 |
એક ઉદાહરણ કરાર આવો દેખાય છે: પ્રદાતા TCP 203.0.113.60:45000 તમારા જોડાયેલા ઉપકરણની HTTPS સેવાને 8443 પોર્ટ પર પહોંચાડે છે. તે બીજા કોઈએ ગોઠવેલ મેપિંગનું વર્ણન છે, એવો નિયમ નથી જે તમે તેમના એજ પર તમારા પોતાના ફાયરવોલમાં લખીને બનાવી શકો.
ઓરિજિન બાજુ પૂરી કરો
જો વેબ એપ્લિકેશન VPN ક્લાયન્ટ પર જ ચાલે છે, તો તેને પહોંચાડેલ પોર્ટ પર શ્રોતા અને તે પોર્ટ માટે મર્યાદિત સ્થાનિક-ઇનપુટ પરવાનગી જોઈએ. જો ક્લાયન્ટ મેપ કરેલ જોડાણને બીજા હોસ્ટ પર ફોર્વર્ડ કરે છે, તો તેને ગંતવ્ય અનુવાદ, ફોર્વર્ડિંગ નીતિ અને આવ-જા ટકી રહે તેવો જવાબ માર્ગ જોઈએ.
એક્સેસ નિયમો પ્રદાતાનો માર્ગ ખરેખર જે સ્રોત સરનામું રજૂ કરે છે તેની આસપાસ ડિઝાઇન કરો. તે હંમેશા મૂળ મુલાકાતી નથી, અને હંમેશા VPN સર્વર પણ નથી, જે ત્યારે મહત્ત્વનું છે જ્યારે તમે એવો નિયમ લખો જેનાથી ફક્ત એક જ સરનામું મેળ ખાય.
પોર્ટ અનુવાદ પણ HTTP ને HTTPS માં ફેરવતું નથી. જાહેર પોર્ટ અને સ્થાનિક એપ્લિકેશન પોર્ટ મુક્તપણે અલગ હોઈ શકે છે, પણ સ્કીમ, પ્રમાણપત્રની ઓળખ અને રીડાયરેક્ટ લોકો ખરેખર પહોંચતી સેવા સાથે મેળ ખાવા જોઈએ. જો પ્રમાણપત્ર જાહેર હોસ્ટનું નામ આપે છે, તો દરેક હોપ પર એ નામ રાખો. અહીં અસંગતિ રાઉટિંગ નિષ્ફળતા તરીકે નહીં પણ બ્રાઉઝર ચેતવણી તરીકે દેખાય છે, જે લોકોને એક કલાક માટે ખોટા લોગ પર મોકલે છે.
ઊંચું પોર્ટ પ્રામાણિકપણે પ્રકાશિત કરો
જો મુલાકાતીઓ સીધા જોડાય છે અને પ્રદાતાએ ઊંચું પોર્ટ ફાળવ્યું છે, તો તેમને સંપૂર્ણ URL આપો. સામાન્ય DNS સરનામા રેકોર્ડ HTTPS વિનંતીમાં પોર્ટ ઉમેરી શકતું નથી, જે ડિફોલ્ટ રીતે 443 વાપરે છે, અને TTL બદલવાથી તે બદલાતું નથી.
વેબ ફ્રન્ટએન્ડ આને મુલાકાતીઓને સામાન્ય પોર્ટ પર સ્વીકારીને અને ફોર્વર્ડ કરેલા ઓરિજિન પોર્ટ સાથે પોતાનું જોડાણ બનાવીને ઉકેલી શકે છે. જોકે Cloudflare ના ડિફોલ્ટ પ્રોક્સી પોર્ટ એક નિર્ધારિત યાદી છે, અને મનસ્વી રીતે ફાળવેલું પોર્ટ ફક્ત પ્રોક્સી DNS રેકોર્ડ ઉમેરવાથી સમર્થિત એજ પોર્ટ બનતું નથી.
ઓરિજિન ગંતવ્ય પોર્ટ બદલવું એ મુલાકાતી પોર્ટ બદલવાથી અલગ ક્રિયા છે. Cloudflare ના Origin Rules બેકએન્ડ જોડાણ માટે ગંતવ્ય-પોર્ટ ઓવરરાઇડનું દસ્તાવેજીકરણ કરે છે, જે સમર્થિત નિયમ, સ્કીમ અને હોસ્ટનામ સુધી મર્યાદિત છે. પોર્ટ ઓવરરાઇડ મનસ્વી UDP કે અન્ય પ્રોટોકોલ માટે સામાન્ય રિલે નથી.
જ્યારે ફ્રન્ટએન્ડ TLS સમાપ્ત કરે છે, ત્યારે બંને હોપ ચકાસો: બ્રાઉઝરથી ફ્રન્ટએન્ડ સુધીનું પ્રમાણપત્ર અને ફ્રન્ટએન્ડથી ઓરિજિન સુધીનું જોડાણ. VPN હોપ બંનેમાંથી કોઈપણ તપાસનું સ્થાન લેતું નથી, અને આંતરિક સરનામું રીડાયરેક્ટ કે કૂકીઝમાં લીક થવું એ સામાન્ય સંકેત છે કે બંનેમાંથી ફક્ત એક જ જાહેર નામને ધ્યાનમાં રાખીને ગોઠવાયું છે.
મેપિંગને જીવંત રાખો
કેટલાક પ્રદાતાઓ ફરી જોડાણ પછી અલગ પોર્ટ ફાળવે છે, અને ભાડે લીધેલ મેપિંગને પ્રદાતાની બાજુની ક્રિયા દ્વારા નવીકરણની જરૂર પડી શકે છે. તમારો પ્રદાતા જે પદ્ધતિનું દસ્તાવેજીકરણ કરે તેને અનુસરો, અને શ્રોતા, સ્થાનિક નિયમો, DNS કે ફ્રન્ટએન્ડ નિયમ ફક્ત ત્યાં જ અપડેટ કરો જ્યાં વર્તમાન કરાર તેની માંગ કરે છે.
સ્થિર જાહેર સરનામું પોર્ટ લીઝને સ્થિર બનાવતું નથી. ડેશબોર્ડમાં હજી દેખાતું સરનામું અને પોર્ટ એ પુરાવો નથી કે જીવંત સત્ર મેપિંગનો માલિક છે, તેથી પરીક્ષણ બહારથી નવી વિનંતી છે, સ્ક્રીનશોટ નહીં.
પછી તમે અપેક્ષા રાખો તે કેસોનું પુનરાવર્તન કરો: સામાન્ય ફરી જોડાણ અને VPN ગુમાવવું. જો ગુમાવવાથી ઓરિજિન અનુપલબ્ધ થવું જોઈએ, તો અપડેટરને પૃષ્ઠભૂમિમાં ચૂપચાપ સીધો ISP માર્ગ ફરી પ્રકાશિત કરવા ન દો. અને જો ફોર્વર્ડિંગ કરાર સાઇટની સ્થિરતાની જરૂરિયાતો પૂરી કરી શકતો નથી, તો બીજું સરનામું લેબલ ખરીદીને સર્વર જેવું વર્તન કરશે એવી આશા રાખવાને બદલે બીજી પ્રકાશન ગોઠવણી પસંદ કરો.