VPN ರೂಟ್ ಕ್ಯಾಶ್ ನಿಮ್ಮ ಬದಲಾವಣೆಯನ್ನು ಮರೆಮಾಡುತ್ತಿದೆಯೇ? ಮೂರು ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

ಬದಲಾವಣೆ ಜಾರಿಗೆ ಬಾರದಿದ್ದಾಗ ರೂಟ್ ಕ್ಯಾಶ್ ಖಾಲಿ ಮಾಡುವುದು ಮೊದಲ ಪ್ರವೃತ್ತಿ, ಮತ್ತು ಆಧುನಿಕ Linux ನಲ್ಲಿ ಅದು ವ್ಯರ್ಥ ಶ್ರಮ: ಜಾಗತಿಕ IPv4 ರೂಟ್ ಕ್ಯಾಶ್ ವರ್ಷಗಳ ಹಿಂದೆ ತೆಗೆದುಹಾಕಲಾಗಿದೆ, ಆದ್ದರಿಂದ ip route show cache ಏನನ್ನೂ ಮುದ್ರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಖಾಲಿ ಮಾಡಲು ಏನೂ ಇಲ್ಲ. ನಿಮ್ಮನ್ನು ಮೋಸಗೊಳಿಸುವ ಸ್ಥಿತಿ ಒಂದು ಪದರ ಮೇಲೆ ಇರುತ್ತದೆ: socket ನಲ್ಲಿ, NAT ಮ್ಯಾಪಿಂಗ್‌ನಲ್ಲಿ, resolver ನಲ್ಲಿ ಅಥವಾ ಹಳೆಯ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಮತ್ತೆ ಅನ್ವಯಿಸಿದ ನೆಟ್‌ವರ್ಕ್ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿ. ಮೂರು ಪ್ರಶ್ನೆಗಳು ಆ ಪ್ರಕರಣಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತವೆ: ತಪ್ಪಾದ ಮಾರ್ಗ ಹೊಸ ಹರಿವಿನಿಂದ ಬರುತ್ತಿದೆಯೇ ಅಥವಾ ಹಳೆಯ ಸಂಪರ್ಕದಿಂದ, ನಿಮ್ಮ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ರೂಟ್‌ಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡುತ್ತದೆಯೇ, ಮತ್ತು ಸ್ಥಿತಿ ರೂಟಿಂಗ್‌ನಲ್ಲಿದೆಯೇ ಅಥವಾ ಅದರ ಮೇಲಿದೆಯೇ. ಇಂಟರ್‌ಫೇಸ್ ಮರುಹೊಂದಿಸುವ ಮೊದಲು ಅವಕ್ಕೆ ಉತ್ತರಿಸಿ.

ಪರಿಶೀಲನೆ ಒಂದು: ಹಳೆಯ ಮಾರ್ಗ ಹೊಸ ಹರಿವಿನಿಂದ ಬರುತ್ತಿದೆಯೇ?

ಸ್ಥಾಪಿತ ಸಂಪರ್ಕವು ಅದನ್ನು ರಚಿಸಿದ ಮಾರ್ಗವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಆದ್ದರಿಂದ ಟನೆಲ್ ಮೇಲಿನ SSH ಅಧಿವೇಶನವು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದ ಬದಲಾವಣೆಯನ್ನು ಉಳಿದುಕೊಳ್ಳುತ್ತದೆ, ಹೊಸ ಅಧಿವೇಶನವು ತಕ್ಷಣ ಹೊಸ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಆದ್ದರಿಂದ «ಬದಲಾವಣೆ ಏನೂ ಮಾಡಲಿಲ್ಲ» ಎಂದರೆ ಹೆಚ್ಚಾಗಿ «ಹಳೆಯ socket ಇನ್ನೂ ಅದನ್ನು ಹಿಡಿದಿದೆ». ಹೊಸ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ, ಈಗಾಗಲೇ ತೆರೆದಿರುವ ವಿಂಡೋದೊಂದಿಗೆ ಅಲ್ಲ.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

ಕೊನೆಯ ಆದೇಶವು ಹೊಸ ಸಂಪರ್ಕವು ನಿಜವಾಗಿ ತಲುಪಿದ ವಿಳಾಸವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಸ್ಥಿತಿ ವಿಂಡೋವನ್ನು ನಂಬದೆ ನಿಜವಾದ ಮಾರ್ಗವನ್ನು ನೋಡಲು ಇದು ಅಗ್ಗದ ದಾರಿ. ಅದನ್ನು namespace ಅಥವಾ ಇಂಟರ್‌ಫೇಸ್ ಬಳಸಬೇಕಿದ್ದ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಹೊಸ ಹರಿವು ಸರಿಯಾದ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಂಡು ಹಳೆಯದು ಚೇತರಿಸಿಕೊಳ್ಳದಿದ್ದರೆ, ರೂಟಿಂಗ್ ನೋಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಮಾರ್ಗ ಸರಿಯಾಗಿತ್ತು; ಅಧಿವೇಶನ ಹಳೆಯದಾಗಿತ್ತು.

ಪರಿಶೀಲನೆ ಎರಡು: ನಿಮ್ಮ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ರೂಟ್ ಕ್ಯಾಶ್ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆಯೇ?

Linux ನಲ್ಲಿ ಉತ್ತರ ಇಲ್ಲ, ಹೆಚ್ಚಿನ ಮಾರ್ಗದರ್ಶಿಗಳು ಉದ್ದೇಶಿಸುವ ಅರ್ಥದಲ್ಲಿ. ಬಿಸಾಡಲು ಜಾಗತಿಕ ಗಮ್ಯಸ್ಥಾನ ಕ್ಯಾಶ್ ಇಲ್ಲ, ಮತ್ತು ಆಯ್ಕೆಮಾಡಿದ ಮಾರ್ಗವನ್ನು ಹಿಡಿದಿಡುವ ಪ್ರತಿ-socket ನಮೂದು socket ಜೊತೆಗೆ ಬಿಡುಗಡೆಯಾಗುತ್ತದೆ. ip-route ಕೈಪಿಡಿಯ ಕ್ಯಾಶ್ ವಿಭಾಗವು ಐತಿಹಾಸಿಕ ವರ್ತನೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಪ್ರಸ್ತುತ ಕರ್ನಲ್‌ನಲ್ಲಿ ನೀವು ಖಾಲಿ ಮಾಡಬಹುದಾದುದನ್ನು ಅಲ್ಲ.

ಇತರ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಭಿನ್ನ, ಮತ್ತು ಸಲಹೆಗಳನ್ನು ನಕಲಿಸುವುದು ಇಲ್ಲಿಯೇ ತಪ್ಪಾಗುತ್ತದೆ. Windows ಗಮ್ಯಸ್ಥಾನ ಕ್ಯಾಶ್ ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಅದನ್ನು netsh interface ip delete destinationcache ನಿಂದ ಸ್ವಚ್ಛಗೊಳಿಸಬಹುದು. BSD ಮತ್ತು macOS route -n get ಮೂಲಕ ಪ್ರತಿ-ಗಮ್ಯಸ್ಥಾನ ಹುಡುಕಾಟಗಳನ್ನು ತೋರಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳ ಕ್ಯಾಶ್‌ಗಳು ತಮ್ಮದೇ ವೇಳಾಪಟ್ಟಿಯಂತೆ ಮುಕ್ತಾಯಗೊಳ್ಳುತ್ತವೆ. ಇವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಆದೇಶ Linux ನಲ್ಲಿ ಏನೂ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದೇ ಪರಿಹಾರವನ್ನು ಪ್ರಯತ್ನಿಸುವ ಅರ್ಧದಷ್ಟು ಜನರಿಗೆ ಅದು ವಿಫಲವಾದಂತೆ ಕಾಣುತ್ತದೆ.

NAT ಅಥವಾ conntrack ಕೋಷ್ಟಕ ರೂಟ್ ಕ್ಯಾಶ್ ಅಲ್ಲ, ಆದರೂ ಅದೇ ಲಕ್ಷಣವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ನಿಮ್ಮ ಬದಲಾವಣೆಗೆ ಮೊದಲು ಅನುವಾದಗೊಂಡ ಹರಿವು ತನ್ನ ಅನುವಾದವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ರೂಟಿಂಗ್ ನೀತಿ ಮುಂದೆ ಸಾಗಿದ ಬಹಳ ಸಮಯದ ನಂತರವೂ conntrack -L ಅದನ್ನು ತೋರಿಸುತ್ತದೆ. ಅದು ಹಳೆಯ ಸ್ಥಿತಿ, ಆದರೆ ರೂಟ್‌ಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವುದು ಅದನ್ನು ಮುಟ್ಟುವುದಿಲ್ಲ.

ಪರಿಶೀಲನೆ ಮೂರು: ಸ್ಥಿತಿ ರೂಟಿಂಗ್‌ನಲ್ಲಿದೆಯೇ ಅಥವಾ ಅದರ ಮೇಲಿದೆಯೇ?

ಬೇರೆ ಏನನ್ನೂ ಓದುವ ಮೊದಲು ಪ್ರಸ್ತುತ ಹುಡುಕಾಟವನ್ನು ಓದಿ: ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ip route get, ನಂತರ from ಮತ್ತು ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಅದೇ ಆದೇಶ, ನಂತರ ip rule show. ಈ ಮೂರು ನಿಮ್ಮ ಉದ್ದೇಶಕ್ಕೆ ಹೊಂದಿಕೆಯಾದರೆ, ರೂಟಿಂಗ್ ಸರಿಪಡಿಸಬೇಕಾದ ಪದರವಲ್ಲ, ಮತ್ತು ಹಳೆಯ ವೀಕ್ಷಣೆ ಬೇರೆಲ್ಲಿಂದ ಬಂದಿದೆ.

ಮೂರು ಸಾಮಾನ್ಯ ಶಂಕಿತರು ರೂಟಿಂಗ್‌ನ ಮೇಲೆ ಕುಳಿತುಕೊಳ್ಳುತ್ತಾರೆ. ನೆಟ್‌ವರ್ಕ್ ಮ್ಯಾನೇಜರ್ ನೀವು ಅಳಿಸಿದ ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಂತರ ಉಳಿಸಿದ ಪ್ರೊಫೈಲ್‌ನಿಂದ ಮಾರ್ಗವನ್ನು ಮತ್ತೆ ಸ್ಥಾಪಿಸಬಹುದು, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಬದಲಾವಣೆ ಮರಳಿ ಬರುತ್ತಿರುವಂತೆ ಕಾಣುತ್ತದೆ; ಕೋಷ್ಟಕವನ್ನು ಮತ್ತೆ ಸಂಪಾದಿಸುವ ಮೊದಲು nmcli connection show --active ಮತ್ತು ಘಟಕದ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ. Resolver ಕ್ಯಾಶ್ ಹಳೆಯ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಅದು ಕ್ಯಾಶ್ ಮುರಿಯುವ ಸಾಧನದೊಂದಿಗೆ ಅದೇ ಹೆಸರನ್ನು ಕೇಳುವವರೆಗೆ ರೂಟಿಂಗ್ ವೈಫಲ್ಯದಂತೆ ಕಾಣುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಂಪರ್ಕ ಪೂಲ್ ಹಳೆಯ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಕೆಲಸ ಮಾಡುವ socket ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಕರ್ನಲ್‌ಗೆ ಎಂದಿಗೂ ಹೊಸ ನಿರ್ಧಾರವನ್ನು ಕೇಳುವುದಿಲ್ಲ.

ಮೂರು ಉತ್ತರಗಳು ಏನು ತೀರ್ಮಾನಿಸಲು ಅನುಮತಿಸುತ್ತವೆ

ಉತ್ತರಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸಿ, ಸರಿಪಡಿಸುವಿಕೆ ಸಾಮಾನ್ಯವಾಗಿ ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ಹೇಳಿಕೊಳ್ಳುತ್ತದೆ. ರೂಟ್ ಕ್ಯಾಶ್ ಇಲ್ಲದ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಹೊಸ ಹರಿವು ತಪ್ಪು ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಂಡರೆ ನೀತಿ ನಿಜವಾಗಿಯೂ ತಪ್ಪು ಎಂದರ್ಥ, ಆದ್ದರಿಂದ ಟನೆಲ್ ಸ್ಥಾಪಿಸಿದ ನಿಯಮಗಳು ಮತ್ತು ಕೋಷ್ಟಕವನ್ನು ಓದಿ. ಹಳೆಯ ಅಧಿವೇಶನ ನಿಂತಿರುವಾಗ ಹೊಸ ಹರಿವು ಸರಿಯಾದ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಂಡರೆ ಸಮಸ್ಯೆ ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ socket ಎಂದರ್ಥ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸರಿಯಾದ ಮಾರ್ಗಗಳೊಂದಿಗೆ ಮುರಿದ ವೀಕ್ಷಣೆ ಎಂದರೆ ಸ್ಥಿತಿ ರೂಟಿಂಗ್‌ನ ಮೇಲಿದೆ.

ಸಾಮಾನ್ಯ ರಿಫ್ರೆಶ್‌ಗೆ ಪ್ರತಿರೋಧಿಸಿ. ನೆಟ್‌ವರ್ಕ್ ಸ್ಟಾಕ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು ಅಥವಾ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಟನೆಲ್ ಆಗಿರುವ ಯಂತ್ರದಲ್ಲಿ ಪ್ರತಿ ಮಾರ್ಗವನ್ನು ಅಳಿಸುವುದು ನೀವು ಅದನ್ನು ಸರಿಪಡಿಸಲು ಬಳಸುತ್ತಿರುವ ಸಂಪರ್ಕವನ್ನೇ ಕಡಿತಗೊಳಿಸಬಹುದು, ಮತ್ತು ಯಾವ ಪದರ ವಿಫಲವಾಯಿತು ಎಂದು ಹೇಳುತ್ತಿದ್ದ ಸಾಕ್ಷ್ಯವನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ.

ನಿಜವಾಗಿಯೂ ಏನನ್ನಾದರೂ ಸ್ವಚ್ಛಗೊಳಿಸಬೇಕಿದ್ದರೆ, ರೋಗನಿರ್ಣಯಕ್ಕೆ ಹೊಂದುವ ಅತ್ಯಂತ ಚಿಕ್ಕ ವಸ್ತುವನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಿ: ಒಂದು ಪ್ರಕ್ರಿಯೆಯ socket ಗಳು, ಒಂದು conntrack ನಮೂದು, resolver ಕ್ಯಾಶ್. ನಂತರ ಅದೇ ಹೊಸ-ಹರಿವಿನ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ ಮತ್ತು ಏನು ಬದಲಾಯಿತು ಎಂದು ಬರೆಯಿರಿ.

ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಮೂರು ಸ್ಥಿತಿಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ

ಉಳಿಸಿದ ಸಂರಚನೆ, ಪ್ರಸ್ತುತ ಹುಡುಕಾಟ ಮತ್ತು ಗಮನಿಸಿದ ಹರಿವು ಮೂರು ವಿಭಿನ್ನ ಸತ್ಯಗಳು, ಮತ್ತು ಅವುಗಳನ್ನು «ಕ್ಯಾಶ್» ಆಗಿ ವಿಲೀನಗೊಳಿಸುವುದೇ ದೋಷವನ್ನು ಮತ್ತೆ ಉಂಟುಮಾಡಲು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ. ಮಾರ್ಗವನ್ನು ಹೊಂದಿರುವ ಪ್ರೊಫೈಲ್ ಅಥವಾ ಘಟಕ, ip route get ನ ಔಟ್‌ಪುಟ್, ಮತ್ತು ನಿಜವಾದ ಸಂಪರ್ಕದ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಬರೆಯಿರಿ.

ಅವುಗಳ ಪಕ್ಕದಲ್ಲಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿಯನ್ನು ಬರೆಯಿರಿ, ಏಕೆಂದರೆ Windows ಗಮ್ಯಸ್ಥಾನ ಕ್ಯಾಶ್ ಸ್ವಚ್ಛಗೊಳಿಸುವ ಪರಿಹಾರ Linux ಹೋಸ್ಟ್‌ಗೆ ಅನ್ವಯವಾಗುವ ಪರಿಹಾರವಲ್ಲ, ಮತ್ತು ಎರಡರ ನಡುವೆ ನಕಲಿಸಿದ ಕಾರ್ಯವಿಧಾನ ತಪ್ಪು ಪಾಠವನ್ನು ಕಲಿಸುತ್ತದೆ. ಸಮಸ್ಯೆಯನ್ನು ಬೇರೆಯವರಿಗೆ ಒಪ್ಪಿಸಿದಾಗ, ಆ ಮೂರು ಸಾಲುಗಳು ಊಹಿಸುವ ಬದಲು ವಿಫಲ ಸ್ಥಿತಿಯನ್ನು ಮರುಸೃಷ್ಟಿಸಲು ಅನುಮತಿಸುತ್ತವೆ.