route-gateway એ redirect-gateway નથી: ખરેખર શું બદલાય છે
આ વિકલ્પ ફક્ત OpenVPN ઇન્સ્ટોલ કરે તે માર્ગો માટે આગળનું હોપ આપે છે. તેને દૂર કરવાથી ધકેલાયેલું પૂર્ણ ટનલ બંધ થતું નથી, અને સુધારો રીડાયરેક્શનમાં છે.
તમારી ટનલ ઉપર આવે છે, ખાનગી સબનેટ જવાબ આપે છે, અને કોઈએ પ્રોફાઇલમાંથી ગેટવે લાઇન કાઢી નાખી હોવા છતાં સામાન્ય બ્રાઉઝિંગ હજી પણ VPN માં અદૃશ્ય થાય છે. આ સંયોજન ખોટી ડિરેક્ટિવ સંપાદિત થયાની આંગળીની છાપ છે. જે દૂર કરવામાં આવ્યું તે ક્લાયન્ટને તે ઇન્સ્ટોલ કરે તે માર્ગો માટે આગળનું હોપ આપતું હતું; જે ટ્રાફિક પકડવાનું ચાલુ રાખ્યું તે બીજે ઠેકાણેથી આવ્યું અને સર્વરે ધકેલ્યું. કવરેજ અને આગળનું હોપ અલગ કાર્યો છે, અને તેમાંથી ફક્ત એક જ નક્કી કરે છે કે સાર્વજનિક ગંતવ્યો ટનલ વાપરે છે કે નહીં.
તમે દૂર કરેલી લાઇન આગળનું હોપ હતી, નીતિ સ્વિચ નહીં
ક્લાયન્ટ જે દરેક માર્ગ ઇન્સ્ટોલ કરે છે તેને નિર્દેશ કરવા માટે ગેટવે સરનામું જોઈએ, અને જ્યારે માર્ગ પોતે કોઈ સરનામું નામ ન આપે ત્યારે ગેટવે ડિરેક્ટિવ એ સરનામાનો સ્રોત છે. તેને કાઢી નાખો તો તે માર્ગોને વળગવાનું કંઈ રહેતું નથી, તેથી તે ક્યાં તો ઇન્સ્ટોલ થતા નથી અથવા એવા માર્ગ પર ઉતરે છે જે ક્યાંય જતો નથી. ખાનગી સબનેટ એ જ છે જે આવા માર્ગ દ્વારા વહેતું હતું.
દરમિયાન જે વર્તન ટકી ગયું તેનો બીજો લેખક છે: ધકેલાયેલા બ્લોકમાં રીડાયરેક્શન વિકલ્પ, જે તેના ફ્લેગ મુજબ સામાન્ય આઉટગોઇંગ ટ્રાફિકને ટનલમાં ખસેડે છે. ગેટવે દૂર કરવાથી તે બંધ પણ થતું નથી અને નબળું પણ પડતું નથી. પરિણામ બંને સ્થિતિઓમાં સૌથી ખરાબ છે, સાર્વજનિક ટ્રાફિક હજી પકડાય છે અને ટનલને વાજબી ઠેરવતું ખાનગી ગંતવ્ય હવે પહોંચની બહાર છે. તેથી જ એ જ ભાવનામાં કરેલું બીજું સંપાદન પણ કંઈ બદલતું નથી.
ચાર લિવર, ચાર અલગ કાર્યો
આ ચર્ચામાં ચાર ડિરેક્ટિવ એકબીજાના બદલે ટાંકવામાં આવે છે, અને તેમાંથી ફક્ત એક કવરેજ નિયંત્રિત કરે છે, એટલે કે કયા ગંતવ્યો બિલકુલ ટનલ દ્વારા મોકલાય છે. બીજું તે આગળનું હોપ નક્કી કરે છે જે માર્ગો વાપરે છે, ત્રીજું એક જ પ્રીફિક્સ ઇન્સ્ટોલ કરે છે, અને ચોથું સર્વરે ધકેલેલું બધું ફેંકી દે છે, જેમાં જમાવટને જરૂરી ખાનગી માર્ગોનો પણ સમાવેશ થાય છે. કોષ્ટક તેમને નામ પ્રમાણે નહીં, પણ વ્યવસ્થાપક શું બદલવા માંગે છે તે પ્રમાણે ગોઠવે છે, કારણ કે નામો જ મૂંઝવણનું કારણ છે. તેમને ચાર અલગ નિર્ણયો તરીકે લો અને તમે ખરેખર જે ઉલટાવવા માંગો છો તે પસંદ કરો.
વ્યવહારમાં ચારેય ઘણી વાર એક જ ધકેલાયેલા બ્લોકમાં, લાઇન પછી લાઇન, આવે છે, જે તેમને એક જ સેટિંગના ભાગો જેવા દેખાડે છે. તેઓ એવા નથી, અને OpenVPN સંદર્ભ તેમને એ જ કારણસર અલગ મિકેનિઝમ તરીકે દસ્તાવેજ કરે છે. તમે કયો નિર્ણય ઉલટાવી રહ્યા છો તે શોધવું એ કામ છે; સંપાદન એક લાઇન છે.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
ધકેલાયેલી લાઇન ફિલ્ટર કરો, આગળનું હોપ રાખો
જે કવરેજ સામે તમે વાંધો ઉઠાવો છો તે ધકેલાયેલા વિકલ્પ તરીકે આવે તો સાંકડો જવાબ એ છે કે તે વિકલ્પને નામથી અવગણો અને ધકેલાયેલા બ્લોકનો બાકીનો ભાગ અકબંધ રાખો. ફિલ્ટર તરીકે લખાયેલું તે નીચેની લાઇન જેવું દેખાય છે, અને તેનું સ્થાન અસરગ્રસ્ત ક્લાયન્ટની પ્રોફાઇલમાં છે, સર્વર રૂપરેખાંકનમાં નહીં.
pull-filter ignore "redirect-gateway"સાંકડાઈ એ જ મુદ્દો છે. ફિલ્ટર ટેક્સ્ટ પ્રીફિક્સ સરખાવે છે, તેથી ટૂંકી પેટર્ન આગળના-હોપ ડિરેક્ટિવ સાથે પણ મેળ ખાય છે, જે ખાનગી માર્ગો જે માહિતી પર આધાર રાખે છે તેને બરાબર ઉતારી નાખે છે અને મૂળ ભૂલને નવા વેશમાં પુનરાવર્તિત કરે છે. ફિલ્ટર ફક્ત ધકેલાયેલા વિકલ્પો પર જ કામ કરે છે, તેથી તે સ્થાનિક રીતે લખાયેલી અથવા નેટવર્ક મેનેજર દ્વારા લાદવામાં આવેલી સમકક્ષ લાઇનને ક્યારેય સ્પર્શતું નથી. પછી ફરી જોડાઓ, કારણ કે જીવંત સત્ર સર્વરે ધકેલેલાનું ફરી મૂલ્યાંકન કરતું નથી.
કોષ્ટક નહીં, શોધ વાંચો
પ્રોફાઇલ ફરી લોડ કર્યા પછી કર્નલને પૂછો કે બે ગંતવ્યો ખરેખર ક્યાં જશે: એક ખાનગી પ્રીફિક્સની અંદર અને એક સાર્વજનિક ઇન્ટરનેટ પર. મુખ્ય કોષ્ટકનું સંપૂર્ણ ડમ્પ વાંચવું વધુ મુશ્કેલ અને ખોટું વાંચવું સરળ છે, કારણ કે માર્ગ અસ્તિત્વમાં હોઈ શકે અને તેમ છતાં વધુ ચોક્કસ મેળ સામે હારી શકે. નીતિ આધારિત રૂટિંગમાં નિયમ, કોષ્ટક અને સ્રોત સરનામું પણ તપાસનો ભાગ છે.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showdef1 પ્રકાર ઓળખવા લાયક છે, કારણ કે તે જૂની ડિફોલ્ટ એન્ટ્રી દૃશ્યમાન રાખે છે જ્યારે અડધા-ડિફોલ્ટની જોડી શોધ જીતે છે. તેથી આઉટપુટમાં 0.0.0.0/0 લાઇન પોતાની રીતે કંઈ સાબિત કરતી નથી. શોધ એ પ્રશ્નનો જવાબ આપે છે જેનો યાદી ફક્ત જવાબ આપતી હોય તેમ લાગે છે.
DNS, IPv6 અને ખાનગી માર્ગ હજી પણ કામ કરવું જોઈએ
એક IPv4 રીડાયરેક્શન નકારવાથી રિઝોલ્વર વિશે કંઈ કહેવાતું નથી, તેથી ધકેલાયેલો DNS વિકલ્પ માર્ગો સાચા દેખાતા હોય ત્યારે પણ પ્રશ્નો ટનલમાં મોકલવાનું ચાલુ રાખી શકે છે. IPv6 ડિફોલ્ટ એવા સરનામા કુટુંબ માટે એ જ કરી શકે છે જેને IPv4 તપાસે ક્યારેય સ્પર્શ કર્યો નથી. બંનેને ધારણાને બદલે સ્પષ્ટ નિર્ણયની જરૂર છે. પછી ખાતરી કરો કે ખાનગી સેવા હજી જવાબ આપે છે, કારણ કે ખાનગી માર્ગ ગુમાવેલી સ્પ્લિટ ટનલ સ્પ્લિટ ટનલ નથી, તે તૂટેલી છે.
એક વધુ પહોળું સાધન ચેતવણીને પાત્ર છે: route-nopull દરેક ધકેલાયેલો માર્ગ અને દરેક ધકેલાયેલો DNS વિકલ્પ ફેંકી દે છે, જે ચોક્કસપણે પૂર્ણ ટનલને રોકે છે અને તેટલી જ ચોક્કસપણે જમાવટ જે ખાનગી માર્ગો પર આધાર રાખે છે તેને તોડે છે, તેથી તે એક વિકલ્પ પર નિશાન તાકેલા નામ-ફિલ્ટર કરતાં ઘણું મોટું હથોડું છે. કોઈપણ ફેરફાર પછી ખાનગી ગંતવ્ય, સાર્વજનિક ગંતવ્ય અને રિઝોલ્વર તપાસો, અને પૂર્ણ થયેલા હેન્ડશેકને હેન્ડશેક સિવાય બીજું કંઈ પુરાવો ન ગણો.