NAT પાછળ SoftEther: સીધું ટ્રાવર્સલ કે VPN Azure રિલે?

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

ત્રણ રીતો, ત્રણ જુદા વચનો

ડાયનેમિક DNS એ નામકરણ છે. તે હોસ્ટનામને બદલાતા સરનામા તરફ રાખે છે જેથી લોકો નંબર પાછળ દોડવાનું બંધ કરે, અને તે બીજું કંઈ કરતું નથી. મૂળ NAT ટ્રાવર્સલ એ સંકલન છે: બે SoftEther એન્ડપોઇન્ટ માહિતીની આપલે કરે છે અને તેમની વચ્ચેના અનુવાદ ઉપકરણો દ્વારા વપરાયોગ્ય UDP માર્ગ ખોલવાનો પ્રયાસ કરે છે. VPN Azure એ રિલે છે: સર્વર સેવા તરફ આઉટબાઉન્ડ ડાયલ કરે છે, અને ક્લાયન્ટ્સ રિલેની ઇન્ફ્રાસ્ટ્રક્ચર પરના હોસ્ટનામ દ્વારા આવે છે.

ત્રણેય એકબીજાના પૂરક છે, એક જ સુવિધાના સંસ્કરણો નથી. એક તૈનાતી નામકરણ વાપરી શકે છે જ્યારે તેનું જોડાણ ખરેખર ટ્રાવર્સલ કે રિલે પર આધાર રાખે છે.

ક્લાયન્ટ અને નેટવર્ક પરથી નક્કી કરો

પસંદગી ક્લાયન્ટથી શરૂ થાય છે, કારણ કે ટ્રાવર્સલ ફક્ત મૂળ SoftEther જોડાણ પદ્ધતિમાં જ હોય છે. એક જ સર્વર પરના OpenVPN, L2TP/IPsec અને SSTP શ્રોતાઓ તેને વારસામાં મેળવતા નથી, જોકે તેઓ એક હોસ્ટ વહેંચે છે. જુઓ વપરાશકર્તા શું ચલાવશે, પછી નેટવર્ક શું મંજૂરી આપે છે. જે કોર્પોરેટ નેટવર્ક ફક્ત TCP 443 ની મંજૂરી આપે છે તે તમને તે પોર્ટ પરના રિલે તરફ ધકેલે છે, જ્યારે ટ્રાવર્સલને જરૂરી UDP પોર્ટ પસાર કરતું નેટવર્ક સીધો માર્ગ અજમાવી શકે છે; બંનેને વાસ્તવિક ઇગ્રેસ નીતિ સામે ચકાસો.

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

ખાતરી કરો કે સેશને કયો ટ્રાન્સપોર્ટ પસંદ કર્યો

જોડાણ સ્થિતિ એ વપરાતા માર્ગ માટેનો એકમાત્ર પ્રામાણિક સ્રોત છે. તેને સર્વર પર વાંચો, અને ક્લાયન્ટને મળેલું હોસ્ટનામ રિઝોલ્વ કરો.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

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

પસંદ કરેલો માર્ગ શેના પર આધાર રાખે તેનું આયોજન કરો

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

હોસ્ટનામ, પ્રોટોકોલ, સુવિધાની સેટિંગ્સ અને અવલોકિત ટ્રાન્સપોર્ટ લખો. તે ચાર-ભાગનો રેકોર્ડ જ આગલી વ્યક્તિને કામ કરતું જોડાણ પુનઃઉત્પન્ન કરવા દે છે.