SoftEther VPN Azure: રિલે માર્ગ, ખુલ્લું પોર્ટ નહીં

તમારું સર્વર એવા રાઉટર પાછળ છે જેને તમે ગોઠવી શકતા નથી, તેથી પોર્ટ ફોરવર્ડ કરવાની સ્પષ્ટ યોજના ઉપલબ્ધ નથી. VPN Azure તે પરિસ્થિતિ માટે જ અસ્તિત્વમાં છે, અને પ્રથમ જોડાણની દિશા ઉલટાવીને તેને ઉકેલે છે: સર્વર બહાર રિલે તરફ જોડાય છે, અને ક્લાયન્ટ સર્વરને બદલે રિલે સુધી પહોંચે છે. એ ઉલટાવ સમજવાથી સેવા શું સુધારે છે અને પછીથી તમે જે મર્યાદાઓનો સામનો કરશો તે બંને સ્પષ્ટ થાય છે.

માર્ગમાં શું બદલાય છે

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

રિલે તે સર્વરને પોતાના ડોમેન પર નામ આપે છે, અને ક્લાયન્ટ ત્યાં જોડાવા ગોઠવાય છે.

એ નામ રિલે સેવાનું છે, જે Microsoft Azure VPN Gateway નથી છતાં બંનેને Azure કંઈક કહેવાય છે. તેમને અદલાબદલી ગણવાથી એવી ગોઠવણી બને છે જે કામ કરી શકે નહીં.

કયા પ્રોટોકોલ રિલેમાંથી પસાર થાય છે

રિલે SoftEther પ્રોટોકોલ વહન કરે છે, અને પ્રોજેક્ટ SSTP ને ક્લાયન્ટ વિકલ્પ તરીકે દસ્તાવેજ કરે છે, જે ઉપયોગી છે કારણ કે Windows સાથે SSTP ક્લાયન્ટ આવે છે. પરંતુ તે હોસ્ટ પરના દરેક શ્રોતા માટે સામાન્ય વાહક બનતું નથી: OpenVPN શ્રોતા, IPsec પ્રતિસાદક અને L2TP સેવાને દરેકને પોતાનું પહોંચી શકાય તેવું અંતિમ બિંદુ જોઈએ છે, અને ફક્ત SoftEther સર્વર જોડાયેલું હોવાને કારણે તેમાંથી કોઈ રિલે દ્વારા વહન પામતું નથી.

તેથી ક્લાયન્ટ પ્રોફાઇલ સર્વર સરનામા પર નહીં પણ રિલે નામ પર નિર્દેશ કરે છે, અને સીધા જોડાણ માટે બનાવેલું હાલનું પ્રોફાઇલ બદલ્યા વિના કામ કરશે નહીં. રિલે જે પ્રોટોકોલ વહન કરતું નથી તેની આસપાસ રચના કરતા પહેલાં તમે ચલાવો છો તે આવૃત્તિ માટે સમર્થિત ક્લાયન્ટની યાદી જુઓ.

રિલે તમારા માટે શું કરતું નથી

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

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

પ્રમાણપત્ર ચકાસણી અને વપરાશકર્તા પ્રમાણીકરણ સર્વરની જવાબદારી રહે છે, અને રિલે ક્યારેય બંનેમાંથી એકનું સ્થાન લેતું નથી.

તેને નિર્ભરતા તરીકે ચલાવો

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

વિલંબ તમારા વપરાશકર્તાઓની નિકટતાને બદલે રિલેના ભૂગોળને અનુસરે છે, જે તેના પર ઇન્ટરેક્ટિવ પ્રદર્શનનું વચન આપતા પહેલાં માપવા જેવું છે.

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