Synology પર OpenVPN હેન્ડશેક નિષ્ફળ? LAN ફોરવર્ડ તપાસો

તમારું લેપટોપ જણાવે છે કે TLS હેન્ડશેક નિષ્ફળ ગયું, તેથી પ્રમાણપત્રો ફરી બનાવવાનું લોભ થાય. પહેલાં વધુ કંટાળાજનક પ્રશ્ન પૂછો: Synology ખરેખર કયા Ethernet પોર્ટ પર સાંભળે છે? બે LAN પોર્ટવાળા NAS પાસે બે સરનામાં હોય છે, અને DSMનું VPN Server પેકેજ તેના OpenVPN શ્રોતાને તેમાંથી એક સાથે બાંધે છે. જ્યારે રાઉટર 1194 ને બીજા સરનામા તરફ ફોરવર્ડ કરે છે, ત્યારે કોઈ પેકેટ ક્યારેય સેવા સુધી પહોંચતું નથી, અને ક્લાયન્ટ પાસે વાટાઘાટ કરવા માટે કંઈ હોતું નથી.

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

શ્રોતા જે સરનામા સાથે બંધાયેલો છે તે શોધો

DSM તેના પોર્ટને LAN 1 અને LAN 2 કહે છે, અને દરેકનું અલગ સરનામું અને સબનેટ હોય છે. VPN Server ખોલો, OpenVPN ટૅબ પર દર્શાવેલ ઇન્ટરફેસ વાંચો, પછી Control Panel ખોલો અને DSM પાસે તે જ ઇન્ટરફેસ પર જે IPv4 સરનામું છે તે નોંધો. ફોરવર્ડે આ બે મૂલ્યોનું નામ આપવું જોઈએ, NASનું હોસ્ટનામ નહીં.

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

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

sudo netstat -anp | grep 1194

બીજું ઉમેરવાને બદલે હાલનું ફોરવર્ડ સંપાદિત કરો

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

external 1194/udp  ->  192.0.2.20:1194/udp

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

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

પેકેટ ક્યારેય પહોંચે છે કે નહીં તે સાબિત કરો

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

sudo tcpdump -i any -n udp port 1194

મૌન એટલે ટ્રાફિક સેવા પહેલાં જ મૃત્યુ પામ્યો: ખોટું આંતરિક સરનામું, DSM ફાયરવૉલ પર બંધ પોર્ટ, અથવા વહીવટી રીતે બંધ ઇન્ટરફેસ. આઉટપુટમાં પેકેટ હોય તો ફોરવર્ડ કામ કરે છે, અને બાકીની ખામી નેટવર્ક સ્તરની ઉપર રહે છે, જે ઘણું નાનું શોધ ક્ષેત્ર છે.

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

પેકેટ આવે ત્યારે ફોરવર્ડને દોષ આપવાનું બંધ કરો

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

પરિવહન એ બીજી અસંગતિ છે જે સ્પષ્ટ રીતે તપાસવા જેવી છે, કારણ કે પ્રોફાઇલ અને પેકેજ અલગ જગ્યાએ સંપાદિત થાય છે. પેકેજ બદલ્યા વિના પ્રોફાઇલ UDPથી TCP કરવાથી ક્લાયન્ટ એવા શ્રોતાની રાહ જુએ છે જે અસ્તિત્વમાં નથી, અને ક્લાયન્ટ બાકીની દરેક વસ્તુ માટે જે સામાન્ય હેન્ડશેક લખાણ જણાવે છે તે જ જણાવે છે. ફાઇલમાં proto લીટી વાંચો, પછી સર્વર પૃષ્ઠ પર પસંદ કરેલો પ્રોટોકોલ જુઓ, અને ત્યારે જ નિષ્કર્ષ કાઢો કે તે મેળ ખાય છે. DSM ફાયરવૉલ નિયમો વાંચવું ત્રીજી તપાસ છે: સ્થાનિક સબનેટથી પોર્ટ ખોલતો પણ ઇન્ટરનેટથી ન ખોલતો નિયમ પરીક્ષણ પછી ભૂલી જવો સહેલો છે, અને તે એવું જોડાણ બનાવે છે જે રસોડામાંથી કામ કરે છે અને બીજા દરેક સ્થળેથી નિષ્ફળ જાય છે.

દૂરસ્થ વપરાશકર્તા ખરેખર જે માર્ગ લે છે તેનું પરીક્ષણ કરો

એ જ LANની અંદરનો ક્લાયન્ટ ફોરવર્ડને ક્યારેય અડ્યા વિના NAS સુધી પહોંચી શકે છે, તેથી તે દૂરસ્થ પ્રવેશ વિશે કંઈ સાબિત કરતું નથી. Wi-Fi બંધ હોય તેવો ફોન વાપરો, અથવા નેટવર્કની બહારની વ્યક્તિને પૂછો, અને તે પ્રયાસ દરમિયાન રાઉટર કૉઉન્ટર જુઓ. જો દૂરસ્થ પ્રયાસ નિષ્ફળ જાય અને સ્થાનિક સફળ થાય, તો ફોરવર્ડ કે ફાયરવૉલ હજી ચિત્રમાં છે.

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