OpenVPN રૂટ પ્લાનમાં bypass-dhcp ખરેખર શું ઉમેરે છે

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

ફક્ત મોબાઇલ નેટવર્કની નિષ્ફળતાને સરનામા ફાળવણી પર ઢોળતા પહેલાં ફ્લેગને અલગ પાડો. એ શબ્દમાળાના બે અડધા ભાગનો એકબીજા સાથે કોઈ સંબંધ નથી.

બે ફ્લેગ, બે અસંબંધિત કામ

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

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

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

અપવાદ ખરેખર કેટલો મર્યાદિત છે

સફળ કનેક્શન પછીનું ઉદાહરણ ટેબલ આકાર દર્શાવે છે: ટનલ દ્વારા બે અડધા-ડિફોલ્ટ રૂટ, અને ભૌતિક ગેટવે દ્વારા DHCP સર્વર માટે એક હોસ્ટ રૂટ. તેને તમારા પોતાના સરનામાં તરીકે નહીં, પણ આકાર તરીકે વાંચો.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

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

ક્લાયન્ટે ખરેખર શું ઇન્સ્ટોલ કર્યું તે તપાસો

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

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

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

બાકીનો માર્ગ આ ફ્લેગમાં નથી

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

નામ ઉકેલ અને IPv6 બંનેને પોતાની નીતિ જોઈએ. IPv4 બદલાવ રિઝોલ્વરને ટનલ-બાજુના સર્વર તરફ નથી વાળતો કે નથી IPv6 કવરેજ ઊભું કરતો, અને ફક્ત v4 રીડાયરેક્ટ કરતો ક્લાયન્ટ v6 માર્ગને અસ્પૃશ્ય રાખે છે.

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