તમારા URLને પોર્ટ 80 અથવા 443 પર પ્રવેશની જરૂર કેમ છે, 45000 પર નહીં

બ્રાઉઝરમાં હોસ્ટનામ લખો અને સ્કીમ લક્ષ્ય પોર્ટ નક્કી કરે છે: http માટે 80, https માટે 443. DNS જવાબમાં કંઈ પણ તેને રદ કરતું નથી, અને તમારા મશીન પરનો કોઈ ફોરવર્ડિંગ નિયમ પ્રદાતાની ધાર પર શ્રોતા શોધી શકતો નથી. જ્યારે VPN પ્રદાતા તમને 45000 જેવો ઊંચો જાહેર પોર્ટ આપે છે, ત્યારે સ્પષ્ટ URL કામ કરે છે અને સ્વચ્છ નહીં. ગેપ પ્રવેશ બિંદુ પર છે, એપ્લિકેશનની અંદર નહીં.

બ્રાઉઝરથી પ્રોસેસ સુધીનો માર્ગ એક વાર જુઓ, અને ત્રણ પ્રકાશન વિકલ્પો રહસ્યમય લાગવાનું બંધ કરશે.

જુઓ વિનંતી ખરેખર ક્યાં જાય છે

બ્રાઉઝર નામને સરનામામાં ઉકેલે છે, પછી URL બીજો પોર્ટ ન કહે તો સ્કીમના ડિફૉલ્ટ પોર્ટ પર તે સરનામા સાથે જોડાય છે. આવતા કનેક્શનનું શું થાય તે તમારા પ્રદાતાની ધાર નક્કી કરે છે. જો તેનું ફોરવર્ડિંગ કોષ્ટક ફક્ત 45000 ને તમારા આંતરિક સરનામા સાથે મેપ કરે છે, તો 80 પરના કનેક્શનને જવાનું કોઈ સ્થળ નથી અને તમારું મશીન સંડોવાય તે પહેલાં તે નકારી કાઢવામાં આવે છે અથવા છોડી દેવામાં આવે છે.

તે નકાર ધાર પર થાય છે, તેથી તમારી એપ્લિકેશનના લોગ કંઈ જ બતાવતા નથી. લોગની ગેરહાજરી પેકેટ ક્યાં અટક્યું તેનો પુરાવો છે, એપ્લિકેશન બગડેલી છે તેનો પુરાવો નહીં.

સ્થાનિક નિયમ ધારને કેમ સુધારી શકતો નથી

એપ્લિકેશન હોસ્ટ પર રીડાયરેક્ટ અથવા DNAT નિયમ પહેલેથી આવેલા પેકેટ પર કામ કરે છે. પ્રદાતા પર પોર્ટ 80 પર મોકલેલા પેકેટ ક્યારેય પહોંચતા નથી, તેથી નિયમનું ક્યારેય મૂલ્યાંકન થતું નથી. આ આખી સમસ્યામાં સૌથી સામાન્ય બગડેલો કલાક છે.

DNS પણ પોર્ટ વહન કરી શકતું નથી. HTTP સ્પેસિફિકેશન સ્કીમના ડિફૉલ્ટ વ્યાખ્યાયિત કરે છે, અને A અથવા AAAA રેકોર્ડ સરનામું પરત કરે છે જ્યારે CNAME બીજું નામ પરત કરે છે. બ્રાઉઝર હજી પણ સ્કીમનો પોર્ટ જોડે છે, તેથી URL માં સ્પષ્ટ પોર્ટ જ લક્ષ્ય બદલે છે.

વિકલ્પ એક: સ્પષ્ટ પોર્ટ રાખો

ઘણી વાર સાચો જવાબ બિનઆકર્ષક હોય છે. પોર્ટ સાથે સંપૂર્ણ URL પ્રકાશિત કરો, તેને સમર્થન આપતા પ્રવેશ પર TLS સમાપ્ત કરો, અને ખાતરી કરો કે દરેક જનરેટ થયેલી લિંક સમાન મૂળ રાખે છે. નાના, નિયંત્રિત પ્રેક્ષકો માટે આ સંપૂર્ણ છે, અને દેખીતા પોર્ટ નંબર સિવાય તેનો કોઈ ખર્ચ નથી.

ત્યાં હોય ત્યારે રીડાયરેક્ટ અને કૂકી અવકાશ તપાસો, કારણ કે પોતાનું હોસ્ટનામ Location હેડરમાં લખતું બેકએન્ડ આ ગોઠવણને રદ કરે છે.

વિકલ્પ બે: ડિફૉલ્ટ પોર્ટ પર ખરેખરો પ્રવેશ મેળવો

કેટલાક પ્રદાતાઓ અને હોસ્ટિંગ ગોઠવણો દસ્તાવેજીકૃત સેવા તરીકે વહેંચાયેલા અથવા સમર્પિત સરનામા પર 80 અને 443 ફોરવર્ડ કરે છે. જાહેર એક્ઝિટ સરનામું મનગમતા ઇનબાઉન્ડ પોર્ટ સૂચવે છે એમ ધારવાને બદલે ખરેખર શું સમાવિષ્ટ છે તે પૂછો. સમર્પિત આઉટબાઉન્ડ સરનામું ઇનબાઉન્ડ ફોરવર્ડિંગ વિશે કંઈ કહેતું નથી.

માલિકી અને ઉપલબ્ધતા લેખિતમાં પુષ્ટિ કરો, જેમાં ટનલ જુદા સરનામા સાથે ફરી જોડાય ત્યારે પ્રવેશનું શું થાય તેનો સમાવેશ થાય છે. ટનલ સાથે ખસતો પ્રવેશ એવા વિક્ષેપ પેદા કરે છે જે DNS નિષ્ફળતા જેવા લાગે છે.

વિકલ્પ ત્રણ: આગળ ફ્રન્ટએન્ડ મૂકો

પહોંચી શકાય તેવા સરનામા પર રિવર્સ પ્રોક્સી 443 પર સાંભળવું અને TLS સમાપ્ત કરવું અને VPN દ્વારા બેકએન્ડ સાથે અલગ કનેક્શન ખોલી શકે છે. મુલાકાતીઓ ફ્રન્ટએન્ડનું નામ અને ડિફૉલ્ટ પોર્ટ જુએ છે, જ્યારે ફ્રન્ટએન્ડ તમારા વતી બેકએન્ડના ઊંચા પોર્ટ સાથે વાત કરે છે. આ કામ કરે છે કારણ કે તે પ્રવેશ બિંદુ સાથે લડવાને બદલે આર્કિટેક્ચર બદલે છે. પછી બેકએન્ડને જાહેર ઇન્ટરનેટ પર કોઈ ઇનબાઉન્ડ પોર્ટની જરૂર જ નથી.

તે તમે શું ચલાવો છો તે પણ બદલે છે. ફ્રન્ટએન્ડ જાહેર TLS, પ્રવેશ નીતિ, લોગ અને ઉપલબ્ધતાનો માલિક છે, અને તેણે બેકએન્ડ પસંદગીને ઇચ્છિત સેવા સુધી મર્યાદિત કરવી જોઈએ. જો ફ્રન્ટએન્ડથી બેકએન્ડ સુધીનો કૂદકો HTTPS વાપરે છે, તો તે કૂદકા પર સર્ટિફિકેટ માન્યતા રાખો.

એક મૂળ રાખો

ફ્રન્ટએન્ડનું જાહેર હોસ્ટનામ, સ્કીમ અને પોર્ટ મુલાકાતીઓ જે મૂળ વાપરે છે તે બનાવે છે, તેથી એપ્લિકેશનનું બાહ્ય URL, રીડાયરેક્ટ અને કૂકી તે મૂળ માટે ગોઠવો. જો એપ્લિકેશન નિરપેક્ષ લિંક બનાવે છે તો મૂળ હોસ્ટ અને ફોરવર્ડ કરેલી સ્કીમ મોકલો. વપરાશકર્તાઓને ખાનગી નામ અથવા ઊંચા પોર્ટ પર પાછા ફેંકતો પ્રતિભાવ તમે હમણાં બનાવેલા સ્વચ્છ પ્રવેશને રદ કરે છે.

પછી પ્રેક્ષકોને ધ્યાનમાં રાખીને નિર્ણય લો. ટૂંકું URL સંચાલિત ફ્રન્ટએન્ડને ન્યાયી ઠેરવી શકે છે, અને ફક્ત VPN માટેની ખાનગી સેવાને ભૂલથી જાહેર બનાવવી યોગ્ય નથી.