એક જ હોસ્ટ પર OpenVPN સર્વર અને ક્લાયન્ટ: ક્લાયન્ટ કેમ નીકળી જાય છે

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

એક મશીન, બે ભૂમિકાઓ, અને જવાબો ક્યાં જવા જોઈએ તે વિશે બે અસંગત જવાબો.

એક જ પૂલ, બે સર્વર: કોણ જીતે

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

સંપાદન પહેલાં શું સક્રિય છે તેની યાદી બનાવો: ip -4 addr show ટનલ ઉપકરણોની યાદી આપે છે, ss -lunp શ્રોતાઓની યાદી આપે છે, અને systemctl list-units યુનિટોનાં નામ આપે છે. ટનલ સરનામાં પર એક નજર પૂલ અથડાય છે કે નહીં તે નક્કી કરે છે.

ક્લાયન્ટ પ્રોફાઇલ કોષ્ટકમાં શું ઉમેરે છે

ક્લાયન્ટ-અડધો જોડાય કે તરત જ રૂટ લખે છે. redirect-gateway def1 ડિફોલ્ટ રૂટને 0.0.0.0/1 વત્તા 128.0.0.0/1 માં વિભાજિત કરે છે, બંને નવા ઉપકરણ દ્વારા રૂટ થાય છે, સાથે દૂરના સર્વર તરફનો હોસ્ટ રૂટ જે જાણી જોઈને ભૌતિક ઇન્ટરફેસ સાથે પિન કરેલો છે. એ પિન એટલા માટે છે કે ટનલ પોતાના પરિવહન માટે રસ્તો રાખે. બાકીનું બધું, સ્થાનિક સર્વર પોતાના ક્લાયન્ટને આપવા પાત્ર જવાબો સહિત, હવે નવા ડિફોલ્ટને અનુસરે છે અને દૂરની લિંક દ્વારા બહાર જાય છે.

તો બીજી અથડામણ તૂટેલું ટનલ નથી. તે કોષ્ટકમાં ખોટી જગ્યાએ બેઠેલું કાર્યકારી ટનલ છે.

ભૂમિકાઓને અલગ રાખવાની ત્રણ રીતો

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

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

બે ઇન્સ્ટન્સમાંથી કોણ દોષિત છે

ક્લાયન્ટ ઇન્સ્ટન્સ બંધ કરો અને મૂળ ક્લાયન્ટની ફરી ચકાસણી કરો. તાત્કાલિક રિકવરી એટલે રૂટિંગ, સર્વર નહીં. ક્લાયન્ટ પાછો લાવો અને ip route get વડે એક જવાબ ટ્રેસ કરો, જેને સ્રોત અને ગંતવ્ય બંને સરનામાં આપવામાં આવ્યાં છે, જે કર્નલ કયો રસ્તો પસંદ કરશે તે દર્શાવે છે, પછી પેકેટ ખરેખર કયું ઇન્ટરફેસ વાપરે છે તે tcpdump -ni any port 1194 વડે જુઓ. સર્વરની સ્ટેટસ ફાઇલ, જે દર થોડી સેકન્ડે status નિર્દેશ દ્વારા લખાય છે, જોડાયેલા ક્લાયન્ટની યાદી અને બંને દિશાના બાઇટ કાઉન્ટર ધરાવે છે.

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