OpenVPN-નું pull-filter તમે ધારેલા રૂટ કરતાં વધુ સાથે મેળ ખાય છે
pull-filter તમારા લખાણને ઉપસર્ગ તરીકે ધકેલાયેલા વિકલ્પો સાથે સરખાવે છે, તેથી route route-gateway અને route-ipv6 પણ પકડે છે. પહેલા ક્રિયાપદો જુઓ, પછી રૂટ.
તમે તમારો સ્થાનિક ડિફૉલ્ટ રૂટ રાખવા એક લીટી ઉમેરો છો, અને પછી ટનલ હવે આંતરિક DNS સર્વર સુધી પહોંચતી નથી. એ લીટી pull-filter ignore "route" હતી, જેનો અર્થ "આ રૂટને અવગણો" નથી. તેનો અર્થ "જેનું લખાણ એ પાંચ અક્ષરોથી શરૂ થાય એવા દરેક ધકેલાયેલા વિકલ્પને કાઢી નાખો" છે, અને સામાન્ય સર્વર પર તેમાં રૂટ સાથે route-gateway, route-metric અને route-ipv6 પણ સામેલ હોય છે. નીચેની ચેકલિસ્ટ એ છે જે હું બીજા કોઈએ વાપરવાની પ્રોફાઇલને અડકતા પહેલા ચલાવું છું.
ફિલ્ટર ફક્ત ધકેલાયેલા વિકલ્પો પર લાગુ પડે છે
pull-filter ફક્ત એ વિકલ્પ-લીટીઓ પર કામ કરે છે જે સર્વર ટનલ સ્થપાયા પછી મોકલે છે, અને બીજા કશા પર નહીં. તમારી સ્થાનિક ફાઇલમાં લખાયેલા વિકલ્પો તેનાથી પ્રભાવિત થતા નથી, અને એપ્લિકેશન ટ્રાફિક પણ નહીં. જો તમે કોઈ પ્રક્રિયાને ટનલ વાપરતી અટકાવવાની આશા રાખતા હતા, તો આ સાવ ખોટું સાધન છે અને ફિલ્ટરોનું કોઈ સંયોજન તે કરશે નહીં.
એ વ્યાપ ઉપયોગી છે, કારણ કે તેનો અર્થ એ છે કે તમે સર્વરનું રૂપરેખાંકન અકબંધ રાખીને પણ તેનો એક ભાગ સ્થાનિક રીતે નકારી શકો છો. તે એક મર્યાદા પણ છે જે ટિકિટમાં લખવા યોગ્ય છે: ફિલ્ટર બદલે છે આ ક્લાયન્ટ શું સ્વીકારે છે, સર્વર શું આપે છે તે નહીં. સમાન પ્રોફાઇલના બીજા વપરાશકર્તાઓ પર તેની કોઈ અસર નથી. જે ક્લાયન્ટ આ વિકલ્પ લાગુ કરતું નથી તેમાં જવાથી તે ટકતું પણ નથી, જે તેના પર કોઈ કાર્યપ્રવાહ બનાવતા પહેલા જાણવા યોગ્ય છે.
પેટર્ન લખતા પહેલા સર્વર ખરેખર શું મોકલે છે તે નિશ્ચિત કરો. વધુ વર્બોસિટી પર ક્લાયન્ટ પ્રાપ્ત થયેલી ધકેલાયેલી વિકલ્પ-શ્રેણી છાપે છે, અને તમે જે ચોક્કસ લખાણ સાથે સરખામણી કરો છો તેનો એ જ એકમાત્ર પ્રામાણિક સ્રોત છે:
sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpnધકેલાયેલી લીટીને અલ્પવિરામથી અલગ પડેલા વિકલ્પોની યાદી તરીકે વાંચો, અને ધ્યાન આપો કે વિકલ્પના નામ અને તેમના આર્ગ્યુમેન્ટ વચ્ચે જગ્યા હોય છે. તમારું ફિલ્ટર લખાણ એ પ્રવાહ સાથે સરખાવાય છે, તેથી આગલા પગલામાં જગ્યાઓ એટલી મહત્વપૂર્ણ છે.
મેળ એ ઉપસર્ગ છે, તેથી જગ્યાઓ જ આખી રમત છે
સરખામણી શ્રેણીનો ઉપસર્ગ છે, પાર્સ કરેલું વિકલ્પ નામ નહીં. તેથી "route" route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 અને route-metric 100 સાથે મેળ ખાય છે. અંતે એક જગ્યા ઉમેરવાથી તે સંભવિત કુટુંબ સુધી સંકોચાય છે, અને પૂરો ઉપસર્ગ તેને ચોક્કસ ગંતવ્ય સુધી વધુ સંકોચે છે.
| Filter text | What it actually matches | Typical outcome |
|---|---|---|
"route" | Every option beginning with those letters | Routes, gateway, metric and IPv6 routes all dropped |
"route " | Route entries only, not the hyphenated siblings | The routes go, the rest survives |
"route 10.60." | A single destination range | The narrowest rule, and the easiest to audit |
"dhcp-option DNS" | Pushed DNS settings | Resolver stays local, internal names stop resolving |
છેલ્લી પંક્તિ એ છે જે સ્પ્લિટ-ટનલ કામ દરમિયાન લોકોને પકડે છે. તમારો પોતાનો રિઝોલ્વર રાખવો કાયદેસર પસંદગી છે, અને તેનો અર્થ એ છે કે હવે દરેક આંતરિક નામ એવા રિઝોલ્વર પર આધારિત છે જે ખાનગી ઝોન જોઈ શકતું નથી. તે જાણી જોઈને સ્વીકારવાનું પરિણામ છે, ઉત્પાદનમાં શોધવાનો આડઅસર નહીં.
ઉપસર્ગ મેળનો અર્થ એ પણ છે કે નિયમ પછીથી ચૂપચાપ વિસ્તરી શકે છે. જ્યારે સર્વર તમારા લખાણથી શરૂ થતો નવો વિકલ્પ ઉમેરે છે, ત્યારે કોઈ તમારી પ્રોફાઇલ સંપાદિત કર્યા વિના તમારું ફિલ્ટર તેના પર લાગુ થવા લાગે છે. એ જ નિષ્ફળતાનો પ્રકાર છે જેની સામે રચના કરવી જોઈએ, અને ઉપાય એ છે કે વિકલ્પનો શક્ય તેટલો મોટો ભાગ મેળવવો, શક્ય તેટલો નાનો નહીં.
ત્રણ ક્રિયાપદ, ત્રણ અલગ પરિણામ
accept, ignore અને reject એક જ વિચારની ત્રણ જોડણી નથી. મેળ સાથે ક્લાયન્ટ શું કરે છે અને કોઈને ખબર પડે છે કે નહીં તેમાં તેઓ ભિન્ન છે.
ignore મેળ ખાતો વિકલ્પ ચૂપચાપ કાઢી નાખે છે, જે તમે જાણી જોઈને બદલેલા સેટિંગ માટે ઇચ્છો છો. reject તેને કાઢી નાખે છે અને ક્લાયન્ટને ફરિયાદ કરાવે છે, જે ત્યારે ઇચ્છો છો જ્યારે તેની ગેરહાજરી પછીથી શોધવાને બદલે લૉગમાં દેખાવી જોઈએ. accept સકારાત્મક સ્વરૂપ છે, જ્યારે તમે વ્યક્તિગત વિકલ્પો દૂર કરવાને બદલે પરવાનગી-યાદી બનાવો છો ત્યારે વપરાય છે.
તમે જે પણ ક્રિયાપદ વાપરો, ફિલ્ટરો તે ક્રમમાં લાગુ થાય છે જેમાં તેઓ દેખાય છે, તેથી બે અતિક્રમણ કરતા નિયમો ક્રમ-આધારિત પરિણામ આપે છે જે સમીક્ષા કરવી ખૂબ મુશ્કેલ છે. દરેક હેતુ માટે એક નિયમ રાખો અને દરેકમાં સૌથી ચોક્કસ લખાણ મૂકો. જો તમને પરવાનગી-યાદીની જરૂર હોય, તો એ જ કામ કરતા ignore નિયમોના ઢગલા કરતાં થોડા accept નિયમોને પ્રાધાન્ય આપો. પછી સમીક્ષકો ફાઇલને ઉપરથી નીચે વાંચીને પરિણામની આગાહી કરી શકે છે, અને એ જ એકમાત્ર પરીક્ષણ છે જે સ્કેલ થાય છે.
લાગુ થયેલા રૂટ અને રિઝોલ્વર ચકાસો, પ્રોફાઇલ નહીં
ફાઇલમાં સાચું દેખાતું ફિલ્ટર પણ તમને એવી ટનલ સાથે છોડી શકે છે જે ઉપયોગી કંઈ રૂટ કરતું નથી. ચાલુ સિસ્ટમ પર અસર ચકાસો, જ્યાં ધકેલાયેલા વિકલ્પો પહેલેથી લાગુ થઈ ગયા છે અથવા કાઢી નાખ્યા છે:
ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/પ્રથમ બે લીટીઓ તમને કહે છે ધકેલાયેલો ડિફૉલ્ટ રૂટ આવ્યો કે નહીં અને કેટલી સ્થિર એન્ટ્રીઓ ટકી. રિઝોલ્વર ક્વેરી બતાવે છે કે ટનલ ઇન્ટરફેસ ખરેખર કયો સર્વર વાપરે છે, અને સામાન્ય રીતે ત્યાં જ DNS આશ્ચર્ય દેખાય છે. છેલ્લી લીટી વપરાશકર્તા માટે મહત્વના એકમાત્ર પ્રશ્નનો જવાબ આપે છે.
ત્યાં હો ત્યારે બંને દિશાઓ ચકાસો. જે નિયમ તમારું સ્થાનિક ઇન્ટરનેટ ચાલુ રાખે છે પણ આંતરિક નામ-ઉકેલ ચૂપચાપ તોડે છે તે સપાટીની ચકાસણી પાસ કરે છે અને પહેલા વાસ્તવિક કાર્યમાં નિષ્ફળ જાય છે, તેથી એક આંતરિક સ્રોત અને એક જાહેર સાઇટ એ જ પરીક્ષણમાં સામેલ કરો.
અપવાદ અને તેનો માલિક નોંધો
ફિલ્ટર ઓપરેટરની રચનાનો અપવાદ છે, તેથી તેને કારણ અને સમીક્ષા-બિંદુ સાથે લખો. "સ્થાનિક ડિફૉલ્ટ રાખવા ધકેલાયેલા રૂટ અવગણે છે" સમીક્ષાયોગ્ય છે; પ્રોફાઇલમાં નરી લીટી નથી, અને આગલી વ્યક્તિ તેને ભૂંસી નાખશે અથવા અનુમાનથી વિસ્તારશે.
અહીં આવૃત્તિ પણ મહત્વની છે. મેળ વર્તન અને ચોક્કસ સ્વીકૃત સિન્ટેક્સ OpenVPN 2.4, 2.5 અને 2.6 દરમિયાન સુધારાયા છે, તેથી તમે મોકલો છો તે બિલ્ડની મેન્યુઅલ સામે પેટર્નની પુષ્ટિ કરો, જૂની આવૃત્તિ વિશેના ફોરમ પોસ્ટ સામે નહીં. OpenVPN 2.6 મેન્યુઅલ આ વિકલ્પ અને તેના મેળ નિયમનું દસ્તાવેજીકરણ કરે છે.
છેલ્લે, જે સર્વર ચલાવે છે તેની સાથે અપવાદ પર સહમત થાઓ. જાણી જોઈને બનાવેલી સર્વર નીતિનો વિરોધ કરતું ક્લાયન્ટ-બાજુનું ફિલ્ટર આગલી ઓડિટની રાહ જોતી સપોર્ટ ઘટના છે, અને પ્રોફાઇલ મોકલાય તે પહેલા તેને સેટલ કરવું ઘણું સસ્તું છે, કોઈ રૂટ ખૂટે છે એ જોયા પછી કરતાં.