DD-WRT પર OpenVPN 2.5 લિસનર મૃત? તેને બનાવેલી ગોઠવણી વાંચો

DD-WRT પર મૃત લિસનરનો અર્થ સામાન્ય રીતે એ છે કે ડેમન તેની ગોઠવણી પાર્સ કરતી વખતે બહાર નીકળી ગયો, એવું નહીં કે ફાયરવોલનો નિયમ પોર્ટ અટકાવતો હતો. OpenVPN 2.5 એ ઘણા ડિફોલ્ટ કડક કર્યા જેના પર જૂની ગોઠવણીઓ આધાર રાખતી હતી, અને જૂની આવૃત્તિ પર કામ કરતી બનાવેલી ગોઠવણી સોકેટ ખૂલે તે પહેલાં જ નકારી શકાય છે. કારણ રાઉટરના પોતાના લોગમાં છે, અને ઇનપુટ બનાવેલી ફાઇલમાં છે. બંનેને આ ક્રમમાં વાંચવું કોઈપણ પેકેટ કેપ્ચર કરતાં ઝડપી છે.

ડેમન એ ફાયરવોલ નથી

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

કંઈપણ બદલતા પહેલા બે તપાસથી તેમને અલગ કરો, કારણ કે મૃત ડેમન પર ફાયરવોલ સંપાદન ફક્ત બીજું ચલ ઉમેરે છે.

DD-WRT એ બનાવેલી ગોઠવણી વાંચો

DD-WRT તમે વેબ ઇન્ટરફેસમાં ટાઇપ કરેલો ટેક્સ્ટ OpenVPN ને આપતું નથી. તે એક બનાવેલી ગોઠવણી /tmp/openvpn/openvpn.conf માં લખે છે અને તે ફાઇલ સાથે ડેમન શરૂ કરે છે, તેથી GUI ના ફીલ્ડ અને Additional Config નો કોઈપણ ટેક્સ્ટ OpenVPN તેમને જો તે પહેલાં જ ભળી જાય છે. જો તમે બનાવેલી ફાઇલને બદલે ફોર્મ ડિબગ કરો છો, તો તમે વાસ્તવિક ઇનપુટ નહીં પણ ઇરાદો વાંચી રહ્યા છો. રીબૂટ /tmp સાફ કરે તે પહેલાં તે ફાઇલને કાયમી જગ્યાએ કૉપિ કરો.

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

જો બનાવેલી ફાઇલ ખાલી હોય અથવા ન હોય, તો ડેમન શરૂ થવા સુધી પણ પહોંચ્યો નથી, અને સમસ્યા OpenVPN પહેલાંની છે.

OpenVPN 2.5 એ શું સ્વીકારવાનું બંધ કર્યું

OpenVPN 2.5 એ ncp-ciphers ને data-ciphers થી બદલ્યું, અને ડિફોલ્ટ લઘુતમ TLS આવૃત્તિ 1.2 કરી. તેણે કમ્પ્રેશનની સંભાળ પણ બદલી, જેથી કમ્પ્રેશન ઓફર કરતું પીઅર નકારવામાં આવે જ્યાં સુધી ગોઠવણી સ્પષ્ટપણે પરવાનગી ન આપે, અને તેણે ns-cert-type જેવા જૂના વિકલ્પ નામોને remote-cert-tls ની તરફેણમાં અપ્રચલિત કર્યા. એ દરેક ફેરફાર અગાઉ કામ કરતી ગોઠવણીને પાર્સ અથવા વાટાઘાટની નિષ્ફળતામાં ફેરવે છે.

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

લોગમાં પહેલી ભૂલ વાંચો, છેલ્લી નહીં. પાર્સિંગ પહેલી ખરાબ સૂચના પર અટકે છે, અને તેના પછીનું બધું બંધ થવાનો ઘોંઘાટ છે.

Broadcom-વિશિષ્ટ પૂર્વશરતો

Broadcom આવૃત્તિઓમાં ડેમન તેનો ઉપયોગ કરે તે પહેલાં ટનલ ઉપકરણ હોવું આવશ્યક છે. તપાસો કે tun મોડ્યુલ લોડ છે અને /dev/net/tun હાજર છે, કારણ કે ઉપકરણ ન હોવાથી એવી શરૂઆતની નિષ્ફળતા થાય છે જેનો પ્રમાણપત્રો સાથે કોઈ સંબંધ નથી. એ જ વાત DD-WRT રૂટ અને DNS માટે બનાવે છે તે સહાયક સ્ક્રિપ્ટોને પણ લાગુ પડે છે: જો તે ન હોય અથવા ચલાવી શકાય તેવી ન હોય, તો ડેમન શરૂ થઈ શકે છે અને તો પણ તેનું સેટઅપ પૂરું ન કરી શકે.

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

પછી સામાન્ય સેવા પુનઃસ્થાપિત કરો, કારણ કે ફોરગ્રાઉન્ડ ડેમન અને init સ્ક્રિપ્ટ પોર્ટ માટે લડશે.

ક્લાયન્ટ ડિબગ કરતા પહેલા લિસનર હોવાનું સાબિત કરો

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

લિસનર અસ્તિત્વમાં આવ્યા પછી જ ક્લાયન્ટ બાજુનું ડિબગિંગ અર્થપૂર્ણ છે. પછી તપાસો કે ક્લાયન્ટના સાઇફર અને TLS સેટિંગ્સ સર્વરની data-ciphers યાદી અને લઘુતમ આવૃત્તિ સાથે મેળ ખાય છે, અને પોર્ટ ખરેખર રાઉટર પર ફોરવર્ડ થાય છે.

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