OpenVPN redirect-gateway: દરેક ફ્લેગ રૂટ સાથે શું કરે છે

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

દરેક ફ્લેગ ડિફોલ્ટ રૂટ સાથે શું કરે છે

કોઈ ફ્લેગ વિના, વિકલ્પ સામાન્ય ડિફોલ્ટ રૂટ દૂર કરે છે અને તેની જગ્યાએ ટનલ મૂકે છે, તેથી જોડાણ ચાલુ હોય ત્યારે જૂનું ગેટવે કોષ્ટકમાંથી અદૃશ્ય થાય છે. def1 ઉમેરો અને તે ડિફોલ્ટ યાદીમાં રહે છે, બે સાંકડા રૂટ કામ કરે છે. bypass-dhcp ઉમેરો અને DHCP રૂટ પણ ટકી રહે છે, જે એવા નેટવર્કમાં મહત્વનું છે જ્યાં ક્લાઇન્ટને હજી સ્થાનિક DHCP સર્વર સુધી પહોંચવાનું છે. OpenVPN 2.6 મેન્યુઅલ પૃષ્ઠ પરની ફ્લેગ યાદી એક વાર વાંચવા જેટલી ટૂંકી છે, અને દરેક નોંધ બદલે છે કે કયા રૂટ કોષ્ટકમાં આવશે.

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

def1 તમારા ડિફોલ્ટને સ્પર્શ્યા વિના વિશિષ્ટતાથી જીતે છે

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

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

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

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

ટનલનું અંતિમ બિંદુ પહોંચવા યોગ્ય રાખો

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

ટનલ ચાલુ હોય ત્યારે કર્નલને પૂછો કે તે અંતિમ બિંદુના સરનામા માટે કયો ઇન્ટરફેસ વાપરશે. જવાબમાં ભૌતિક ઇન્ટરફેસ અને તેના ગેટવેનું નામ હોવું જોઈએ, કદી tun0 નહીં:

ip route get 198.51.100.20

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

IPv6 ટ્રાફિક પોતાનું કોષ્ટક વાપરતું રહે છે

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

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

ip -6 route show default
ip -6 route get 2001:db8::10

સાબિત કરો કે એપ્લિકેશન કયો ઇન્ટરફેસ વાપરે છે

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

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

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

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