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 ಕೈಪಿಡಿ ಈ ಆಯ್ಕೆ ಮತ್ತು ಅದರ ಹೊಂದಿಕೆ ನಿಯಮವನ್ನು ದಾಖಲಿಸುತ್ತದೆ.
ಕೊನೆಯದಾಗಿ, ಸರ್ವರ್ ನಡೆಸುವವರೊಂದಿಗೆ ಅಪವಾದವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಿ. ಉದ್ದೇಶಪೂರ್ವಕ ಸರ್ವರ್ ನೀತಿಗೆ ವಿರುದ್ಧವಾಗುವ ಕ್ಲೈಂಟ್-ಬದಿಯ ಫಿಲ್ಟರ್ ಮುಂದಿನ ಆಡಿಟ್ಗೆ ಕಾಯುತ್ತಿರುವ ಬೆಂಬಲ ಘಟನೆ, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಕಳುಹಿಸುವ ಮೊದಲು ಅದನ್ನು ಬಗೆಹರಿಸುವುದು ಯಾರಾದರೂ ಮಾರ್ಗಗಳು ಕಾಣೆಯಾಗಿರುವುದನ್ನು ಗಮನಿಸಿದ ನಂತರ ಬಗೆಹರಿಸುವುದಕ್ಕಿಂತ ಬಹಳ ಅಗ್ಗ.