Windows પર OpenVPN એડેપ્ટર ફ્લેપ થાય છે? નકલી IP ચકાસો

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

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

ક્લાયંટ લોગથી નહીં, Windows ઇવેન્ટ લોગથી શરૂ કરો

Windows સરનામા સંઘર્ષ સિસ્ટમ લોગમાં ઇવેન્ટ ID 4198 અને 4199 સાથે નોંધે છે. પ્રથમ સરનામા માટે મળેલા સંઘર્ષની જાણ કરે છે, બીજું જાણ કરે છે કે ઇન્ટરફેસ તેના કન્ફિગર કરેલા સરનામાનો ઉપયોગ કરી શક્યું નહીં. બંનેમાંથી કોઈ OpenVPN નો ઉલ્લેખ કરતું નથી, અને તેથી જ તેમને ધ્યાનમાં ન લેવાનું સરળ છે.

તાજેતરની ઘટનાઓ ખેંચો અને તેમની ટાઈમસ્ટેમ્પની સરખામણી એડેપ્ટરના નવીકરણ ચક્ર સાથે કરો: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. દર પંદર સેકન્ડે એક સંઘર્ષ એવા ક્લાયંટ સાથે મેળ ખાય છે જે એ જ સરનામું એવા માલિક સામે ફરી પ્રયત્ન કરે છે જે તેનો જવાબ આપવાનું ચાલુ રાખે છે. કનેક્શન સમયે એકલો સંઘર્ષ તેના બદલે એકવારની ટક્કર તરફ નિર્દેશ કરે છે. કોઈપણ સ્થિતિમાં, આગળનો પ્રશ્ન એ છે કે સરનામું બીજું કોણ ધરાવે છે.

ત્રણ ગોઠવણીઓ બે હોસ્ટને એક સરનામા પર મૂકે છે

સર્વરને પૂછો કે તેના મતે સરનામું કોણ ધરાવે છે, પછી નેટવર્કને પૂછો કે તેનો જવાબ કોણ આપે છે. grep -H ifconfig-push /etc/openvpn/ccd/* દરેક પિન કરેલા ટનલ સરનામા અને તે જે સર્ટિફિકેટનું છે તેની સૂચિ આપે છે. ip -4 neigh show dev tap0 બ્રિજે બીજા સ્તરે શું શીખ્યું તે દર્શાવે છે. આ બે યાદીઓની સરખામણી કરવાથી મોટાભાગની નકલો એક મિનિટથી ઓછા સમયમાં મળી આવે છે.

ત્રણ ગોઠવણીઓ લગભગ બધાને સમજાવે છે: client-config-dir પ્રવેશ બે સર્ટિફિકેટ માટે એક સરનામું પિન કરે છે, બ્રિજ કરેલો tap સેગમેન્ટ મશીનને એવું સરનામું આપે છે જે બીજા હોસ્ટ પાસે પહેલેથી સ્થિર રીતે છે, અથવા જૂની લીઝ ફાઇલ એવું સરનામું પાછું આપે છે જે હજી જોડાયેલો ક્લાયંટ પોતાનું માને છે. ત્રીજો કિસ્સો સૌથી કપટી છે, કારણ કે ifconfig-pool-persist જાણીતા ક્લાયંટ માટે સરનામાં જાણી જોઈને ફરી વાપરે છે.

સરનામા માટે દોડવાને બદલે તેને અનન્ય બનાવો

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

persist ફાઇલ ફક્ત ત્યારે જ કાઢો જ્યારે તમે જાણો કે તે કઈ લીઝ ધરાવે છે, નહીં તો આગલું પુનઃકનેક્શન ફરી એ જ સરનામાં આપશે.

યોગ્ય ક્રમમાં ફરી શરૂ કરો અને દરેક સરનામા માટે એક માલિકની ખાતરી કરો

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

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

ટિકિટ બંધ કરતાં પહેલાં સંપૂર્ણ નવીકરણ ચક્ર દરમિયાન નજર રાખો

એક સ્વચ્છ વાંચન કંઈ સાબિત કરતું નથી. ઓછામાં ઓછા દસ મિનિટ એડેપ્ટર પર નજર રાખો અને વચ્ચે પુનઃકનેક્શન ફરજિયાત કરો: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. સરનામું પુનઃકનેક્શન ટકી રહેવું જોઈએ અને પસંદગીની સ્થિતિમાં રહેવું જોઈએ.

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

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