તમારો જૂનો ડિફોલ્ટ માર્ગ OpenVPN પછી પણ જાણી જોઈને ટકી રહે છે

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

def1 ખરેખર શું કરે છે

ફ્લેગ 0.0.0.0/1 અને 128.0.0.0/1 ઉમેરે છે, બંને ટનલ તરફ. 0.0.0.0/1 એ દરેક સરનામું લે છે જેનો પ્રથમ ઓક્ટેટ 0 થી 127 છે, અને 128.0.0.0/1 128 થી 255 લે છે, તેથી દરેક IPv4 ગંતવ્ય પાસે જૂના ડિફોલ્ટ કરતાં વધુ ચોક્કસ મેળ હોય છે. કયો માર્ગ જીતશે તે મેટ્રિક નહીં, પ્રીફિક્સની લંબાઈ નક્કી કરે છે.

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

શા માટે /1 અને /0 નહીં

રૂટિંગ સૌથી લાંબો મેળ ખાતો પ્રીફિક્સ પસંદ કરે છે, સૌથી નીચો મેટ્રિક નહીં, તેથી ડિફોલ્ટનું મેટ્રિક શું કહે તે ગમે તે હોય, /1 એ /0 ને હરાવે છે. બંને અડધા એટલા માટે છે કે એક /1 ફક્ત અડધી જગ્યા આવરે છે; ફક્ત 0.0.0.0/1 હાજર હોય તો 128.0.0.0 થી ઉપરનું બધું હજી જૂના ડિફોલ્ટને અનુસરે છે, જે મૂંઝવણભર્યું લક્ષણ ઊભું કરે છે: કેટલીક સાઇટો કામ કરે છે અને કેટલીક નહીં.

જૂના ડિફોલ્ટનું મેટ્રિક વધારવું કે ઘટાડવું કંઈ બદલતું નથી, અને બીજા ઇન્ટરફેસ પર નીચા મેટ્રિકવાળું ડિફોલ્ટ પણ ટ્રાફિક ચોરતું નથી. પહેલા પ્રીફિક્સની લંબાઈ નક્કી કરે છે, અને ફક્ત સમાન પ્રીફિક્સ જ મેટ્રિક તરફ જાય છે.

વાસ્તવિક રૂટિંગ ટેબલ વાંચો

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

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

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

પેકેટ ખરેખર કયો માર્ગ લે છે તે તપાસો

વધુ ચોક્કસ માર્ગ હજી જીતી શકે છે: ખાનગી રેન્જ, સ્થાનિક સબનેટ અથવા VPN સર્વરનું પોતાનું સરનામું /1 કરતાં લાંબું છે. ટનલને તેના સર્વર સુધી બહારનો રસ્તો જોઈએ, અને તે જોડાણને ફરી ટનલમાં મોકલવાથી તે તરત તૂટી જશે. Linux પર ટેબલ આંખે વાંચવાને બદલે કર્નલને પૂછો: તમને રસ હોય તે ગંતવ્ય સાથે ip route get પસંદ કરેલો માર્ગ, ઇન્ટરફેસ અને સ્રોત છાપે છે. પોલિસી રૂટિંગ ગોઠવેલું હોય તો નિયમો પણ તપાસો, કારણ કે નિયમ મુખ્ય ટેબલ જોવાય તે પહેલાં બીજું ટેબલ પસંદ કરી શકે છે.

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

def1 શું આવરતું નથી

બે IPv4 નોંધ IPv6 વિશે કંઈ કહેતી નથી: IPv6 જોડાણવાળો હોસ્ટ પોતાનું ડિફોલ્ટ વાપરવાનું ચાલુ રાખે છે જ્યાં સુધી કંઈ તે કુટુંબને અલગથી વાળે નહીં, તેથી ડ્યુઅલ-સ્ટેક નેટવર્ક પર અમુક ટ્રાફિક ટનલને ટાળતો દેખાય છે. બીજા ક્લાયન્ટ અને નેટવર્ક મેનેજર સંપૂર્ણ-ટનલ રૂટિંગ અલગ રીતે લાગુ કરે છે, અને તેમના ટેબલ મેળ ખાશે નહીં. અહીં વર્ણવેલ def1 વર્તન OpenVPN ના દસ્તાવેજીકૃત ફ્લેગનું છે, મશીન પરના દરેક VPN નું નહીં.

કિલ સ્વિચ બીજા પ્રશ્નનો જવાબ આપે છે: ટનલ પડે ત્યારે મશીન શું કરે છે. માર્ગની અગ્રતા નક્કી કરે છે કે ટનલ ચાલુ હોય ત્યારે ટ્રાફિક ક્યાં જાય છે; તે પછી ફાયરવોલ શું કરે તે નક્કી કરતું નથી. કામનો ક્રમ: ટેબલ વાંચો, બંને અડધા છે તેની ખાતરી કરો, નિષ્ફળ ગંતવ્ય માટે ip route get ચલાવો, પોલિસી નિયમો તપાસો, પછી IPv6 અલગથી જુઓ. જૂનું ડિફોલ્ટ જ્યાં છે ત્યાં જ રહેવા દો.