એક જ રાઉટર પાછળ કેમ ફક્ત એક VPN ક્લાયન્ટ જ જોડાય છે

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

કોઈ ક્લાયન્ટને સ્પર્શ કરતાં પહેલાં ગેટવેનો લોગ વાંચો

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

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

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

રાઉટર GRE અને NAT-T સાથે શું કરે છે

PPTP એ ઉત્તમ ગુનેગાર છે: નિયંત્રણ ચેનલ TCP 1723 છે જ્યારે ડેટા માર્ગ GRE, એટલે કે IP પ્રોટોકોલ 47 છે. ઘણા ગ્રાહક રાઉટર PPTP સહાયક સાથે આવે છે જે એક જ નિયંત્રણ જોડાણને અનુસરે છે, તેથી એક જ NAT પાછળનું બીજું ક્લાયન્ટ પોતાની નિયંત્રણ ચેનલ ખોલે છે અને પછી કોઈ ડેટા માર્ગ જ મળતો નથી. 47 નંબરનો TCP પોર્ટ ફોરવર્ડ કરવાથી GRE માટે કંઈ થતું નથી, કારણ કે GRE એ પ્રોટોકોલ નંબર છે, પોર્ટ નહીં.

L2TP IPsec ઉપર ડિઝાઇન મુજબ અલગ વર્તે છે: IKE UDP 500 વાપરે છે, NAT ટ્રાવર્સલ સુરક્ષિત પેલોડને UDP 4500 પર ખસેડે છે, અને એન્કેપ્સ્યુલેશન એટલા માટે જ છે કે એક સરનામા પાછળના ઘણા ક્લાયન્ટ એ જ ગેટવે સુધી પહોંચી શકે. એ ડિઝાઇન ગેટવે કે વચ્ચેના બોક્સને દરેક સરનામા માટે સત્ર મર્યાદા લાદતું અટકાવતી નથી, અને સોફા પરથી બંને નિષ્ફળતા સરખી દેખાય છે. SoftEtherના પોતાના પ્રોટોકોલમાં એ જ વર્ગની સમસ્યા છે: કામ કરતા પાસ-થ્રુ વિનાનું રાઉટર LANમાંથી પહેલા ક્લાયન્ટને અંદર લે છે અને બીજાને છોડી દે છે. રાઉટરનું ALG કે પાસ-થ્રુ સ્વિચ બંને સ્થિતિમાં ચકાસો, કારણ કે જૂના ક્લાયન્ટ માટે લખાયેલો સહાયક હાલના ક્લાયન્ટ મોકલે છે તે પેકેટ બગાડી શકે છે.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

ટ્રાન્સપોર્ટ મર્યાદા જેવી દેખાતી ઓળખ મર્યાદા

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

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

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

સમારકામને લોગ એન્ટ્રી સાથે મેળવો

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

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

બે જીવંત સત્રોની ચકાસણી

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

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