OpenVPN route-nopull ખરેખર સર્વરને શું ધકેલતા અટકાવે છે
route-nopull ધકેલાયેલા રૂટ્સ અને DHCP વિકલ્પો કાઢી નાખે છે, હેન્ડશેક નહીં. તેની, pull-filter અથવા કંઈ નહીં વચ્ચે પસંદ કરો, પછી રૂટ્સ જાતે ઉમેરો.
તમે ક્લાયન્ટ પ્રોફાઇલમાં route-nopull મૂક્યું જેથી ટનલ તમારો ડિફોલ્ટ રૂટ ગળી ન જાય, અને હવે ઓફિસ સબનેટ પહોંચની બહાર છે જ્યારે ક્લાયન્ટ હજી પણ કહે છે કે તે જોડાયેલ છે. બંને અવલોકનો સાચા છે, અને કંઈ નિષ્ફળ ગયું નથી. ફ્લેગ ક્લાયન્ટને કહે છે કે સર્વર જે રૂટ્સ અને DHCP એન્ટ્રીઓ ધકેલે છે તે છોડી દે, જે ઉમેરતી વખતે મોટાભાગના લોકો ધારે છે તેના કરતાં સાંકડી સૂચના છે. જે રહે છે તે કાર્યરત ટનલ છે, કઈ ગંતવ્યોએ તેનો ઉપયોગ કરવો જોઈએ તે અંગે કોઈ મત વિના.
એ જ અંતર એ આખો નિર્ણય છે જેના વિશે આ લેખ છે. કાં તો સર્વર નેટવર્કનું વર્ણન કરે, અથવા ક્લાયન્ટ કરે, અને ફ્લેગ એ કામ ક્લાયન્ટને સોંપે છે, તમારા માટે તેમાંથી કંઈ પણ કર્યા વિના.
જોડાણ સમયે ફ્લેગ શું બંધ કરે છે
ખેંચતું OpenVPN ક્લાયન્ટ સામાન્ય રીતે પ્રમાણીકરણ પછી સર્વર પાસેથી બંડલ લે છે: રૂટ્સ, ડિફોલ્ટ ગેટવેનું પુનઃનિર્દેશન, DNS સર્વરો અને થોડા ટ્યુનિંગ નિર્દેશો. route-nopull અમલમાં હોય ત્યારે ક્લાયન્ટ હજી સત્ર સ્વીકારે છે, હજી પ્રમાણપત્રો ચકાસે છે, હજી સાઇફર્સ અને keepalive વાટાઘાટ કરે છે, અને હજી ઇન્ટરફેસ ઉપર લાવે છે. તે જે છોડી દે છે તે ધકેલાયેલી route લાઇનો અને ધકેલાયેલી dhcp-option લાઇનોનો ઉપયોગ છે, DNS સહિત.
મૂંઝવણ મૃત એપ્લિકેશનની બાજુમાં લીલા સૂચકથી આવે છે. ટનલ અસ્તિત્વમાં છે; ગંતવ્યોનું તે ટનલ સાથેનું મેપિંગ નથી. ક્લાયન્ટના સ્ટેટસ પેનલમાં કંઈ પણ «જોડાયેલ અને રૂટ કરી રહ્યું છે» ને «જોડાયેલ અને નિષ્ક્રિય» થી અલગ કરતું નથી, કારણ કે ટનલની દૃષ્ટિએ બંને એક જ સ્થિતિ છે.
જીવંત ટનલ હજી કેમ કંઈ રૂટ કરી શકતી નથી
ઇન્ટરફેસ પોતાના સરનામા સાથે દેખાય છે અને પોઇન્ટ-ટુ-પોઇન્ટ લિંક પર ઘણી વાર પીઅર તરફના હોસ્ટ રૂટ કરતાં વધુ ચોક્કસ કંઈ હોતું નથી. ખાનગી સબનેટ ત્યારે જ પહોંચી શકાય તેવું બને છે જ્યારે કોઈ રૂટ યોગ્ય પ્રીફિક્સ સાથે તે ઇન્ટરફેસ તરફ નિર્દેશ કરે, અને ધકેલવાનું બંધ હોય ત્યારે તે રૂટ ક્યારેય આવતું નથી. ડાઉનલોડ કરેલી પ્રોફાઇલ પણ સામાન્ય રીતે મદદ કરી શકતી નથી, કારણ કે તે એવી ધારણા પર લખાઈ હતી કે સર્વર બરાબર આ માહિતી પૂરી પાડશે. તેથી ઇન્ટરફેસ સ્વસ્થ દેખાઈ શકે છે જ્યારે સબનેટ અંધારું રહે છે.
તેથી પ્રોફાઇલ વાંચવું બહુ ઓછું સાબિત કરે છે. તેના બદલે જોડાયેલ મશીન પર ચાલુ સ્થિતિ વાંચો:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10બીજા આદેશમાં સબનેટ રૂટ વિનાનું સરનામું આ સમસ્યાની સહી છે. ત્રીજો આદેશ પછી એ પ્રશ્નનો જવાબ આપે છે જે વપરાશકર્તાઓને ખરેખર મહત્ત્વનો છે, કારણ કે તે એ ઇન્ટરફેસની જાણ કરે છે જે કર્નલ ચોક્કસ ગંતવ્ય માટે પસંદ કરશે, તમે જે યાદી વાપરશે તેવી આશા રાખી હતી તેના બદલે. જો તે તમારી ભૌતિક લિંક દ્વારા જવાબ આપે, તો ટનલ પાથમાં જ નથી.
નામ રિઝોલ્યુશન સંબંધિત કારણથી નિષ્ફળ જાય છે, અલગ કારણથી નહીં. ધકેલાયેલી dhcp-option DNS એન્ટ્રીઓ એ જ ફ્લેગ દ્વારા છોડી દેવાય છે, તેથી આંતરિક હોસ્ટ્સ માટેની ક્વેરીઓ સ્થાનિક નેટવર્કે પૂરો પાડેલા જે પણ રિઝોલ્વર હોય તેની પાસે જાય છે. તે રિઝોલ્વર પાસે ઓફિસ માટે કોઈ ઝોન નથી, તેથી ક્વેરી નિષ્ફળ જાય છે અથવા જાહેર જવાબ આપે છે, અને નિષ્ફળતા સર્વરની સમસ્યા જેવી લાગે છે જ્યારે તે ક્લાયન્ટ રૂપરેખાંકનની સમસ્યા છે. નામ પહેલાં સરનામું ચકાસવું એ બંનેને અલગ પાડે છે.
ફ્લેગ અને પ્રીફિક્સ ફિલ્ટર વચ્ચે પસંદગી
બંને વિકલ્પો એક જ ફરિયાદના જુદા જુદા આકાર ઉકેલે છે, અને ખરાબ પસંદગી એ «જોડાયેલ પણ નકામું» સ્થિતિ ઉત્પન્ન કરે છે. એક ધકેલાયેલી નીતિને સંપૂર્ણ બદલે છે, જ્યારે બીજી પ્રીફિક્સ પ્રમાણે તેમાં સંપાદન કરે છે. કોષ્ટક ટૂંકી આવૃત્તિ આપે છે, અને તેના પછીનો ફકરો એ ભાગ આવરી લે છે જે લોકોને પકડે છે.
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter ત્રણ ક્રિયાપદો સાથેનું પ્રીફિક્સ મેચર છે, તેથી તે લાઇનોનો પરિવાર સ્વીકારી શકે છે, તેમને શાંતિથી અવગણી શકે છે, અથવા પ્રીફિક્સ દેખાય ત્યારે જોડાણ સંપૂર્ણપણે નકારી શકે છે. તે છેલ્લું વર્તન જાણવા લાયક છે: નકાર કરવાનો નિયમ નીતિના મતભેદને શાંત બાદબાકીને બદલે નિષ્ફળ હેન્ડશેકમાં ફેરવે છે. OpenVPN 2.6 મેન્યુઅલ સ્વીકૃત પ્રીફિક્સો અને દરેક ક્રિયાપદનો સચોટ અર્થ સૂચિબદ્ધ કરે છે.
સામાન્ય મધ્યમ માર્ગ એ છે કે ફક્ત redirect-gateway નકારો અને ઓફિસના રૂટ્સ અને DNS ઉદ્દેશ્ય મુજબ આવવા દો. આ સર્વર જે ભાગો તમના કરતાં સારી રીતે સમજે છે તેમના માટે ધકેલવાનું કાર્યરત રાખે છે, અને સાથે સાથે તે એક લાઇનને અટકાવે છે જે તમારો ડિફોલ્ટ રૂટ સંભાળી લેત.
હાથે રૂટ્સ અને રિઝોલ્વર ઉમેરવું
જો તમે ફ્લેગ રાખો છો, તો પ્રોફાઇલે એ કહેવું જોઈએ જે સર્વર કહેત. ક્લાયન્ટ-બાજુના route નિર્દેશો જોડાણ સ્થપાયા પછી લાગુ થાય છે, તેથી તેઓ ફ્લેગ સાથે કામ કરે છે, તેના દ્વારા અવરોધાતા નથી. તેમને પ્રોફાઇલમાં મૂકો, ઇન્ટરેક્ટિવ કમાન્ડ લાઇનમાં નહીં, નહીં તો આગલું પુનઃજોડાણ કાર્યરત સ્થિતિ ફરી ઉત્પન્ન કરશે નહીં.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53DNS લાઇન અસ્વસ્થ સ્થાને છે: તે ક્લાયન્ટ-બાજુનો નિર્દેશ છે, પણ કેટલાક ક્લાયન્ટ તેને ફક્ત પ્લેટફોર્મના DNS એકીકરણ દ્વારા લાગુ કરે છે, જે લિંક બદલાય ત્યારે તેના પર લખી શકે છે. systemd હોસ્ટ પર ટનલ ઇન્ટરફેસ પર સીધું રિઝોલ્વર સેટ કરવું એ ક્લાયન્ટ પ્રાયોરિટી સ્પર્ધા જીતશે તેવી આશા કરવા કરતાં વધુ અનુમાનિત છે:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comરૂટિંગ ડોમેન સરનામા જેટલું જ મહત્ત્વનું છે. તેના વિના જાહેર નામોની ક્વેરીઓ પણ આંતરિક રિઝોલ્વરને મોકલાઈ શકે છે, અને રિકર્શન નકારતું કોઈ પણ આંતરિક રિઝોલ્વર ખાનગી ઝોન કાર્યરત રાખીને બ્રાઉઝિંગ તોડી નાખશે. તેની સાથે ફક્ત તે પ્રત્યય હેઠળના નામો ટનલ રિઝોલ્વર પર રૂટ થાય છે અને બાકીનું બધું ભૌતિક લિંકને અનુસરે છે.
પરિણામ ચકાસવું: સરનામું, નામ અને બહારનો માર્ગ
ત્રણ પરીક્ષણો સંભવિત નિષ્ફળતાઓને અલગ પાડે છે. પહેલા IP દ્વારા ખાનગી સરનામું લો, પછી નામ દ્વારા એ જ હોસ્ટ, પછી સામાન્ય જાહેર સાઇટ. કાર્યરત IP અને નિષ્ફળ નામ રિઝોલ્વર તરફ સંકેત કરે છે; નિષ્ફળ IP અને કાર્યરત નામ રૂટિંગ તરફ સંકેત કરે છે; બંને નિષ્ફળ હોય તો સામાન્ય રીતે ટનલ પાથમાં નથી.
પછી અંદરની તરફ નહીં, બહારની તરફ જુઓ. ટનલના અંતિમ બિંદુના પોતાના રૂટે પરિવર્તન ટકી રહેવું જોઈએ, અને કોઈ પણ અવરોધક નિષ્ફળતા અંતિમ બિંદુને પકડ્યા વિના ટનલ સુધી મર્યાદિત હોવી જોઈએ. ટનલ પડ્યા પછી પણ જે ક્લાયન્ટ બ્રાઉઝિંગ ચાલુ રાખે છે તે રૂટિંગ સમસ્યા નહીં, નીતિ સમસ્યા છે, અને ઉપરના ત્રણ પરીક્ષણોમાંથી કોઈમાં દેખાશે નહીં.
અંતિમ યાદી પ્રોફાઇલના દસ્તાવેજીકરણમાં લખો: રૂટ્સ, રિઝોલ્વર, ડોમેન અને દરેક કેમ અસ્તિત્વમાં છે તેનું કારણ. સમાન કોષ્ટક ફરી ઉત્પન્ન કરતું પુનઃજોડાણ એ જ એકમાત્ર પુરાવો છે કે સ્થાનિક નીતિ પૂર્ણ છે. જો ટનલ ઉપર હોવા અને ત્રણેય પરીક્ષણો પસાર થવા છતાં એપ્લિકેશનો નિષ્ફળ રહે, તો આગળ જોવાની જગ્યા પહેલેથી ચકાસાયેલા પ્રમાણપત્રો નહીં, પણ «જોડાયેલ પણ ઑફલાઇન» સમસ્યાઓનો વર્ગ છે.