જ્યારે તેનું સર્વર એક જ હોસ્ટ પર ચાલે ત્યારે OpenVPN ક્લાયન્ટ અટકી જાય છે

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

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

લક્ષણને ઉલટું વાંચો

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

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

દરેક ઇન્સ્ટન્સ માટે એક સોકેટ અને એક ઉપકરણ

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

lport 1195
nobind
dev tun1

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

nobind ક્લાયન્ટ બાજુનું છે. સર્વરે હજી પણ બાઇન્ડ કરવું અને સાંભળવું પડે છે, તેથી લાઇનને સર્વર કન્ફિગમાં કૉપિ કરશો નહીં, અને જે ક્લાયન્ટનું પીઅર નિશ્ચિત સ્રોત પોર્ટ પર ફિલ્ટર કરે છે તેના પર બાઇન્ડિંગ બંધ કરશો નહીં.

ડિફોલ્ટ રૂટ માટે એક માલિક પસંદ કરો

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

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

ઉપરના સરનામાં અને ટેબલ નંબર પ્લેસહોલ્ડર છે. નિયમ ઉમેર્યા પછી તરત જ ખાતરી કરો કે VPN સર્વરનું પોતાનું સરનામું હજી પણ સામાન્ય ટેબલ દ્વારા ઉકેલાય છે; જે ટેબલ બહારના ટ્રાન્સપોર્ટને પકડે છે તે તે ટનલને તોડે છે જેને તે રક્ષણ આપવાનું હતું, અને તે પછીનું પુનઃકનેક્શન લૂપ અવિશ્વસનીય પ્રદાતા જેવું લાગે છે.

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

સ્ટેટસ લાઇનથી નહીં, ટેબલથી ચકાસો

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

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

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

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