openfortivpn ಪದೇ ಪದೇ DNS ಅನ್ನು ಮೀರಿಸಿ ಬರೆಯುತ್ತಿದೆಯೇ? ನಿಜವಾದ ಮಾಲೀಕರನ್ನು ಹುಡುಕಿ

ಸಂಪರ್ಕವು ಮೇಲೇರುವ ಕ್ಷಣದಿಂದಲೇ ಅನುಸರಿಸಿ: ಕ್ಲೈಂಟ್ ದೃಢೀಕರಿಸುತ್ತದೆ, pppd ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ, ನಂತರ ಏನೋ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ಗೆ DNS ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬರೆಯುತ್ತದೆ. VPN ನಿಮ್ಮ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಬದಲಿಸಿತು ಎಂದಷ್ಟೇ ನಿಮಗೆ ತಿಳಿದಿದ್ದರೆ, ಆ ಹಂತಗಳಲ್ಲಿ ಯಾವುದು ಅದನ್ನು ಮಾಡಿತು ಎಂಬುದು ಇನ್ನೂ ತಿಳಿದಿಲ್ಲ. ಅವುಗಳಲ್ಲಿ ಎರಡು ಮಾಡಬಲ್ಲವು, ಮತ್ತು ದಾಖಲಿತ pppd ಏಕೀಕರಣವನ್ನು ಬಳಸುವ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಅವು ಒಂದೇ ಪಾತ್ರಧಾರಿಯಂತೆ ಕಾಣುವಷ್ಟು ಹತ್ತಿರದಲ್ಲಿ ಚಲಿಸುತ್ತವೆ. ಬರಹಗಾರನನ್ನು ಹೆಸರಿಸುವುದು ಮೊದಲ ಹೆಜ್ಜೆ; ಅವನ ಬದಲಿಯನ್ನು ಆರಿಸುವುದು ಎರಡನೆಯದು, ಮತ್ತು ಅದು ತನ್ನದೇ ವೈಫಲ್ಯ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿರುವ ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರ.

ಕೆಳಗಿನ ಕ್ರಮವು ಕ್ಲೈಂಟ್ನ್ನು ಹೊರಮುಖವಾಗಿ ಅನುಸರಿಸುತ್ತದೆ: ಸಂಪರ್ಕವು ಏನನ್ನು ಬದಲಿಸಿತು, ಯಾವ ಸ್ವಿಚ್ ಯಾವ ಬರಹಗಾರನನ್ನು ಅಡಗಿಸುತ್ತದೆ, ಯಾರು ಜವಾಬ್ದಾರಿ ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ಮತ್ತು ಫಲಿತಾಂಶವು ಮರುಸಂಪರ್ಕವನ್ನು ತಾಳಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಹೇಗೆ ಖಚಿತಪಡಿಸುವುದು. ಪ್ರತಿ ಹಂತವೂ ಬೇರೆ ಜಾಡನ್ನು ಬಿಡುತ್ತದೆ, ಮತ್ತು ಆ ಜಾಡೇ ಹಸ್ತಾಂತರ ನಿಜವಾಗಿ ನಡೆಯಿತೇ ಎಂದು ನಿಮಗೆ ಹೇಳುತ್ತದೆ.

ಸಂಪರ್ಕವು ನಿಜವಾಗಿ ಏನನ್ನು ಬದಲಿಸಿತು ಎಂಬುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ

ನಿಮ್ಮ ಸಾಮಾನ್ಯ ಆದೇಶದೊಂದಿಗೆ ಒಮ್ಮೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಮೊದಲು ಹಾಗೂ ನಂತರದ ಪರಿಹಾರವನ್ನು ಹೋಲಿಸಿ. systemd-resolved ಚಲಾಯಿಸುವ Linux ಹೋಸ್ಟ್ನಲ್ಲಿ, resolvectl status ಪ್ರತಿ ಲಿಂಕ್ಗೆ DNS ಸರ್ವರ್ಗಳನ್ನು ಮತ್ತು ಹುಡುಕಾಟ ಡೊಮೇನ್ಗಳನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ತನ್ನದೇ ಸರ್ವರ್ಗಳನ್ನು ಹೊತ್ತಿರುವ ಹೊಸ tun ಅಥವಾ ppp ಲಿಂಕ್ ಕ್ಲೈಂಟ್ ಬದಿಯ ನವೀಕರಣದ ಬೆರಳಚ್ಚು. macOS ನಲ್ಲಿ, scutil --dns ರಿಸಾಲ್ವರ್ ಸಂರಚನೆಯನ್ನು ಅಪ್ಲಿಕೇಶನ್ಗಳು ಅದನ್ನು ಸಂಪರ್ಕಿಸುವ ಕ್ರಮದಲ್ಲಿ ತೋರಿಸುತ್ತದೆ.

ಅದನ್ನು ನೀವು ಬದಲಾಗುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಿದ ಕಡತದೊಂದಿಗೆ ಹೋಲಿಸಿ. ಪ್ರತಿ ಲಿಂಕ್ ನೋಟದಲ್ಲಿನ ಸಂಪರ್ಕ-ಬದ್ಧ ನಮೂದು ಮತ್ತು ಮರುಬರೆದ /etc/resolv.conf ಎರಡು ಬೇರೆ ಫಲಿತಾಂಶಗಳು, ಮತ್ತು ಎರಡನೆಯದು ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ಯಾವುದೋ ನಿರ್ವಹಿಸುವ ಸಾಂಕೇತಿಕ ಕೊಂಡಿಯಾಗಿರಬಹುದು. ರಿಸಾಲ್ವರ್ ವಿಳಾಸ, ಹುಡುಕಾಟ ಡೊಮೇನ್ಗಳು ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಹೆಸರನ್ನು ಅದೇ ಕ್ಷಣದಲ್ಲಿ ದಾಖಲಿಸಿ; ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಬದಲಾದರೆ ಬೇರೆ ಬರಹಗಾರನನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಆ ಆಧಾರ ರೇಖೆ ಇಲ್ಲದಿದ್ದರೆ, ನಂತರದ ಪ್ರತಿ ತಿದ್ದುಪಡಿಯೂ ಮೂರು ಘಟಕಗಳಲ್ಲಿ ಯಾವುದು ಜರುಗಿತು ಎಂಬ ಊಹೆಯಷ್ಟೇ.

ಎರಡು ಸ್ವಿಚ್ಗಳು ಮತ್ತು ಪ್ರತಿಯೊಂದು ಅಡಗಿಸುವ ಬರಹಗಾರ

openfortivpn ತಾನು ನಿಯಂತ್ರಿಸಬಹುದಾದ ಎರಡೂ ಬರಹಗಾರರನ್ನು ಆಫ್ ಮಾಡುವ ಆಯ್ಕೆ ತುಣುಕನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಸ್ವಿಚ್ಗೂ ಕೈಪಿಡಿ ಅದೇ ಸೆಟ್ಟಿಂಗ್ ಎಂದು ಪರಿಗಣಿಸುವ ಪೂರ್ಣವಾಗಿ ಬರೆದ ಸಮಾನಾಂತರವಿದೆ.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns ಕ್ಲೈಂಟ್ ಗೇಟ್ವೇಯಿಂದ ಕಲಿತ DNS ಸರ್ವರ್ಗಳನ್ನು ಅನ್ವಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಆದರೆ --pppd-no-peerdns pppd ಪೀರ್ DNS ಅನ್ನು ಸಿಸ್ಟಮ್ಗೆ ತಳ್ಳುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. upstream ಕೈಪಿಡಿ PPP ಮೂಲಕ DNS ನವೀಕರಣಗಳು ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ DNS ನವೀಕರಣಗಳೊಂದಿಗೆ ಸ್ಪರ್ಧಿಸಬಹುದು ಎಂದು ಎಚ್ಚರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡೂ ಸ್ವಿಚ್ಗಳು ತುಣುಕಿನಲ್ಲಿರಬೇಕು, ಒಂದನ್ನು ಸಾಕು ಎಂದು ಪರಿಗಣಿಸುವ ಬದಲು.

ಯಾವುದೇ ಸ್ವಿಚ್ ಬದಲಿ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಹೆಸರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೂ ನೆಟ್ವರ್ಕ್ ಮ್ಯಾನೇಜರ್, DHCP ಕ್ಲೈಂಟ್ ಅಥವಾ ಪ್ರತ್ಯೇಕ VPN ಏಕೀಕರಣವನ್ನು ನಂತರ ಪರಿಹಾರ ಬರೆಯದಂತೆ ತಡೆಯುವುದಿಲ್ಲ. ಎರಡು ಬರಹಗಾರರನ್ನು ಅಡಗಿಸುವುದು ಕ್ಷೇತ್ರವನ್ನು ಒಡೆತನದ್ದಾಗಿಸದೆ ತೆರೆದಿಡುತ್ತದೆ. ಮೂರನೆಯ ಘಟಕ ಈಗಾಗಲೇ DNS ನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ, ತುಣುಕು ನೀವು ಗಮನಿಸಬಹುದಾದ ಯಾವುದನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ; ಯಾವುದೂ ಅದನ್ನು ನಿರ್ವಹಿಸದಿದ್ದರೆ, ಖಾಸಗಿ ಹೆಸರು ಪರಿಹಾರದ ಏಕೈಕ ಮೂಲವನ್ನು ನೀವು ಈಗಷ್ಟೇ ತೆಗೆದುಹಾಕಿದ್ದೀರಿ. ಬದಲಿ ಮಾಲೀಕರನ್ನು ಮೊದಲು ಆರಿಸಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿದಾಗ ಮಾತ್ರ ಇದು ಮಾನ್ಯ ಜೋಡಣೆ.

ಏನನ್ನಾದರೂ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಮೊದಲು ಮಾಲೀಕರನ್ನು ಆರಿಸಿ

ಕೆಲಸದ ಹೆಸರುಗಳ ಪ್ರಶ್ನೆಗಳಿಗೆ ಯಾರು ಉತ್ತರಿಸುತ್ತಾರೆ ಎಂದು ಮೊದಲು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ಆ ಆಯ್ಕೆ ನಂತರದ ಎಲ್ಲವನ್ನೂ ಮಿತಿಗೊಳಿಸುತ್ತದೆ. ಇರುವ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದು ಎಂದರೆ ಖಾಸಗಿ ವಲಯವು ಕ್ಲೈಂಟ್ ಇರುವಲ್ಲಿಂದ ಈಗಾಗಲೇ ತಲುಪಬಲ್ಲದಾಗಿರಬೇಕು, ಮತ್ತು ಕಚೇರಿಯೊಳಗಿನ ಖಾಸಗಿ ರಿಸಾಲ್ವರ್ಗೆ ಸುರಂಗ ಮೇಲೇರಿದಾಗಲೂ ಉಳಿಯುವ ಮಾರ್ಗ ಬೇಕು. ಪ್ರತಿ ಪ್ರಶ್ನೆಯನ್ನು ಒಂದೇ ಆಂತರಿಕ ಸೇವೆಗೆ ಕಳುಹಿಸುವುದು ಹೆಚ್ಚು ತೀಕ್ಷ್ಣ ವೈಫಲ್ಯ ವಿಧಾನವಿರುವ ಮೂರನೆಯ ನೀತಿ: ಆ ಸೇವೆ ತಲುಪಲಾಗದಿದ್ದಾಗ, ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳು ಖಾಸಗಿ ಹೆಸರುಗಳೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತವೆ.

ಮಾರ್ಗದ ಒಡೆತನ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಉಳಿಯುತ್ತದೆ. ಮಾರ್ಗ ಆಯ್ಕೆಗಳು ನೀವು DNS ಬದಲಿಸಿದ್ದರಿಂದ ಅಗತ್ಯವಿಲ್ಲ, ಮತ್ತು ಬದಲಿಯನ್ನು ಸ್ಥಾಪಿಸದೆ ಮಾರ್ಗ ಸ್ಥಾಪನೆಯನ್ನು ಆಫ್ ಮಾಡುವುದು ನೀವು ಈಗಷ್ಟೇ ಆರಿಸಿದ ರಿಸಾಲ್ವರ್ ಅನ್ನು ತಲುಪಲಾಗದಂತೆ ಮಾಡಬಹುದು. ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಲ್ಲಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ರಿಸಾಲ್ವರ್ ವಿಳಾಸಕ್ಕಾಗಿ ನೋಡಿ, ನೀವು ಆಕಸ್ಮಿಕವಾಗಿ ಪರೀಕ್ಷಿಸಿದ ಅಪ್ಲಿಕೇಶನ್ ಉಪಜಾಲಕ್ಕಾಗಿ ಮಾತ್ರವಲ್ಲ.

ಪರಿಹಾರವನ್ನು ಪ್ರತಿ ಲಿಂಕ್ಗೆ ಪರಿಶೀಲಿಸಿ, ಪ್ರತಿ ಕಡತಕ್ಕೆ ಅಲ್ಲ

ಸೀಮಿತ ಅಥವಾ ಪ್ರತಿ-ಡೊಮೇನ್ ಪರಿಹಾರವಿರುವ ಹೋಸ್ಟ್ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ಗಳು ನಿಜವಾಗಿ ಏನನ್ನು ಬಳಸುತ್ತವೆ ಎಂಬ ಪಟ್ಟಿ ಒಂದು /etc/resolv.conf ಅಲ್ಲ, ಆದ್ದರಿಂದ ವೇದಿಕೆ ರಿಸಾಲ್ವರ್ ಸ್ಥಿತಿಯನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ರೀತಿಯಲ್ಲೇ ಓದಿ.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

ಸಂಪರ್ಕ ಮೇಲೇರಿದ ನಂತರ ಒಂದು ಖಾಸಗಿ ಹೆಸರು ಮತ್ತು ಒಂದು ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಕೇಳಿ, ಮತ್ತು ಯಾವ ಲಿಂಕ್ ಯಾವುದಕ್ಕೆ ಉತ್ತರಿಸಿತು ಎಂದು ಗುರುತಿಸಿ. VPN ಲಿಂಕ್ ಪ್ರತಿ-ಡೊಮೇನ್ ಹುಡುಕಾಟ ಪಟ್ಟಿಯನ್ನು ಹೊತ್ತಿರುವಲ್ಲಿ, ಖಾಸಗಿ ಹೆಸರು ಸರಿಯಾಗಿ ಪರಿಹರಿಸಲ್ಪಡಬಹುದು ಆದರೆ ಸಾರ್ವಜನಿಕ ಹೆಸರು ಇನ್ನೂ ಸ್ಥಳೀಯ ರಿಸಾಲ್ವರ್ಗೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು ಆ ವಿಭಜನೆ ವೈಫಲ್ಯವಲ್ಲ, ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ವಿನ್ಯಾಸ. ಖಾಸಗಿ ಪ್ರಶ್ನೆ ವಿಫಲವಾದರೆ, ಮತ್ತೆ DNS ಮುಟ್ಟುವ ಮೊದಲು ರಿಸಾಲ್ವರ್ಗೆ ಇರುವ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ; ಅದು ಯಶಸ್ವಿಯಾಗಿಯೂ ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾಗುತ್ತಿದ್ದರೆ, ಅಪ್ಲಿಕೇಶನ್ ತನ್ನದೇ ಕ್ಯಾಶ್ ಮಾಡಿದ ಅಥವಾ ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂರಚಿಸಿದ ರಿಸಾಲ್ವರ್ ಓದುತ್ತಿರಬಹುದು.

ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡ ಸ್ಥಿತಿಯನ್ನು ಖಚಿತಪಡಿಸಿ

ಸಂಪರ್ಕವನ್ನು ಇಳಿಸಿ ಮತ್ತು ಎರಡೂ ಪ್ರಶ್ನೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಆರಿಸಿದ ಮಾಲೀಕರು ಸ್ಥಾಪಿಸಿದ್ದನ್ನು ಅದೇ ಮಾಲೀಕರು ತೆಗೆಯಬೇಕು ಅಥವಾ ಮರುಸ್ಥಾಪಿಸಬೇಕು, ನೀವು ಸದ್ದಿಲ್ಲದೆ ಮಾಡಿದ ಕ್ಲೈಂಟ್ ಅದನ್ನು ಬಿಟ್ಟು ಹೋಗಬಾರದು. ಸುರಂಗಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುವ ಹಳೆಯ ಪ್ರತಿ-ಲಿಂಕ್ ನಮೂದು ಇನ್ನೂ ತಲುಪಲಾಗದ ವಿಳಾಸಕ್ಕೆ ಖಾಸಗಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಕಳುಹಿಸುತ್ತಲೇ ಇರುತ್ತದೆ.

ನಂತರ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ ಅದೇ ಮೂರು ಮೌಲ್ಯಗಳನ್ನು ಓದಿ: ರಿಸಾಲ್ವರ್ ವಿಳಾಸ, ಹುಡುಕಾಟ ಡೊಮೇನ್ಗಳು, ಇಂಟರ್ಫೇಸ್.

ಅವು ನೀವು ಬರೆದ ನೀತಿಗೆ ಹೊಂದಿದ್ದರೆ, ಹಸ್ತಾಂತರ ಪೂರ್ಣಗೊಂಡಿದೆ ಮತ್ತು VPN ಕ್ಲೈಂಟ್ ಇನ್ನು ಬರಹಗಾರರಲ್ಲಿ ಒಂದಲ್ಲ. ಲಿಂಕ್ ಮೇಲೇರಿದ ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಂತರ ಮೌಲ್ಯವೊಂದು ಹಿಂದೆ ಜರಿದರೆ, ಬೇರೆ ಯಾವುದೋ ಇನ್ನೂ ಸಂರಚನೆಯನ್ನು ಅನ್ವಯಿಸುತ್ತಿದೆ, ಮತ್ತು ಮುಂದಿನ ಹೆಜ್ಜೆ ಇನ್ನೊಂದು ಫ್ಲ್ಯಾಗ್ ಸೇರಿಸುವುದಲ್ಲ, ಆ ಘಟಕವನ್ನು ಗುರುತಿಸುವುದು. ನೀವು ಬಯಸುವ ಅಂತಿಮ ಸ್ಥಿತಿ ಘಟನೆರಹಿತವಾಗಿದೆ: ಒಬ್ಬ ಮಾಲೀಕ, ಒಂದು ದಾಖಲಿತ ನೀತಿ, ಮತ್ತು ಸುರಂಗ ಇದ್ದ ಮೊದಲಿನಂತೆಯೇ ನಿಖರವಾಗಿ ಪರಿಹರಿಸುವ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡ ಹೋಸ್ಟ್.