Wi-Fi ನಿಂದ ಸೆಲ್ಯುಲರ್ಗೆ ಬದಲಾದ ನಂತರ ಕಿಲ್ ಸ್ವಿಚ್: ಏನು ಮುರಿಯುತ್ತದೆ

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

ಪರದೆಯ ಮೇಲೆ ಆ ಮೂರು ಸ್ಥಿತಿಗಳನ್ನು ಯಾವುದೂ ಪ್ರತ್ಯೇಕಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸೂಚಕ ಯಾವ ಬಣ್ಣ ತೋರಿಸುತ್ತದೆ ಎಂದು ಕೇಳುವ ಬದಲು ನಿಯಮಗಳನ್ನು ಯಾವ ಗುರುತುಗಳಿಗೆ ಪಿನ್ ಮಾಡಲಾಗಿತ್ತು ಎಂದು ಕೇಳಿ. Linux ನಲ್ಲಿ ನಿಯಮವು ಇಂಟರ್ಫೇಸ್ ಅಥವಾ ಅದರಿಂದ ತುಂಬಿದ ipset ಅನ್ನು ಹೆಸರಿಸಬಹುದು; Android ನಲ್ಲಿ setUnderlyingNetworks ಮೂಲಕ ಯಾವ ಆಧಾರ ನೆಟ್ವರ್ಕ್ಗಳನ್ನು ಅನುಸರಿಸಬೇಕೆಂದು VpnService ಗೆ ಹೇಳಬಹುದು. ಪ್ರತಿ ಬಂಧವು ಬದಲಾಗಲಿರುವ ಕೊಂಡಿಗೆ ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದನ್ನೂ ನಂತರ ಮತ್ತೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕು.

ಹಸ್ತಾಂತರವು ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಮರುಬರೆಯುತ್ತದೆ

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

ತೊಂದರೆ ಎಂದರೆ ನಿಯಮವು ತನ್ನ ಹಿಂದಿನ ಉದ್ದೇಶದ ಬದಲು ನಿರ್ದಿಷ್ಟ ಗುರುತನ್ನು ಸಂಕೇತಿಸುತ್ತದೆ. ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಹೊರಬರದ ಎಲ್ಲವನ್ನೂ ಬಿಟ್ಟುಬಿಡುವ ನಿಯಮವು ಇಂಟರ್ಫೇಸ್ ಹೆಸರನ್ನು ಸಂಕೇತಿಸುತ್ತದೆ; ಅಂತ್ಯ ಬಿಂದುವಿಗೆ ಅನುಮತಿ ನೀಡುವ ನಿಯಮವು ಹೊಸ ನೆಟ್ವರ್ಕ್ ಬೇರೆಡೆಗೆ ರೂಟ್ ಮಾಡಬಹುದಾದ ವಿಳಾಸವನ್ನು ಸಂಕೇತಿಸುತ್ತದೆ. ಗುರುತು ಮಾಯವಾದಾಗ ನಿಯಮವು ಕಣ್ಣಿಗೆ ತಪ್ಪಾಗುವುದಿಲ್ಲ: ಅದು ಯಾವುದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಅಥವಾ ತಪ್ಪಾದುದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ರಂಧ್ರ ಮಾಡದೆ ಹೊರಗಿನ ಟನೆಲ್ ಮತ್ತೆ ಕಟ್ಟುವುದು

ಹೊರಗಿನ ಸಾಗಣೆ ಹಳೆಯ ಮೂಲ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿತವಾಗಿತ್ತು, ಆದ್ದರಿಂದ ಅದು ಹೊಸದರಿಂದ ಹೊಸ ಸಾಕೆಟ್ ತೆರೆಯಬೇಕು. ಅಂತ್ಯ ಬಿಂದುವು ಅಕ್ಷರಶಃ ವಿಳಾಸವಲ್ಲದೆ ಹೋಸ್ಟ್ನಾಮ ಆದಾಗ, ಬ್ಲಾಕ್ ಜಾರಿಯಲ್ಲಿರುವಾಗಲೇ ಹುಡುಕಾಟ ಯಶಸ್ವಿಯಾಗಬೇಕು. ಇದೇ ಕ್ರಮದ ಬಲೆ: ಅಂತ್ಯ ಬಿಂದುವನ್ನು ಬಿಟ್ಟು ಎಲ್ಲವನ್ನೂ ಬಿಡಲು ಸಾಕಷ್ಟು ಕಟ್ಟುನಿಟ್ಟಾದ ನೀತಿ ಅದನ್ನು ಹುಡುಕಲು ಬೇಕಾದ ಹುಡುಕಾಟವನ್ನೂ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಬ್ಲಾಕ್ ಎತ್ತುವ ಮೊದಲೇ ಪರಿಹಾರ ನಡೆಯದಿದ್ದರೆ ಅಥವಾ ಇನ್ನೂ ಜೀವಂತವಿರುವ ಟನೆಲ್ ಮೂಲಕ ಸಾಗಿಸದಿದ್ದರೆ. ಎರಡೂ ಕ್ರಮಗಳು ಕೆಲಸ ಮಾಡಬಹುದು, ಆದರೆ ಕ್ಲೈಂಟ್ ತಾನು ಯಾವ ಕ್ರಮದಲ್ಲಿದ್ದೇನೆ ಎಂದು ತಿಳಿದಿದ್ದರೆ ಮಾತ್ರ.

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

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

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

ಹೊಸ ಕೊಂಡಿ IPv6 ತಂದಾಗ ಮತ್ತು ನಿಯಮಗಳು ತರದಿದ್ದಾಗ

ಸೆಲ್ಯುಲರ್ ಮತ್ತು ಅತಿಥಿ ನೆಟ್ವರ್ಕ್ಗಳು ಹೆಚ್ಚಾಗಿ ಜಾಗತಿಕ IPv6 ಪ್ರಿಫಿಕ್ಸ್ ನೀಡುತ್ತವೆ, ಕಚೇರಿಯ ತಂತಿ LAN ಅದನ್ನು ಎಂದಿಗೂ ನೀಡದಿದ್ದರೂ. ಕೇವಲ IPv4 ನಿಯಮಗಳಾಗಿ ಬರೆದ ನೀತಿ — ಕೈಯಿಂದ ಮಾಡಿದ ಬಹುಪಾಲು iptables ಮತ್ತು nftables ಪಾಕವಿಧಾನಗಳ ಡೀಫಾಲ್ಟ್ ರೂಪ — ಅದರ ಯಾವುದನ್ನೂ ಮುಚ್ಚುವುದಿಲ್ಲ. ಟನೆಲ್ ಸಂಪರ್ಕದಲ್ಲೇ ಇರುತ್ತದೆ, IPv6 ತಲುಪುವಿಕೆ ಇರುವ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಅದರ ಹೊರಗೆ ಹೋಗುತ್ತವೆ, ಮತ್ತು ಟನೆಲ್ ನಿಜವಾಗಿ ಮೇಲಿದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಸೂಚಕ ವ್ಯತ್ಯಾಸ ತೋರಿಸಲಾರದು. ವಿರುದ್ಧ ಪ್ರಕರಣವೂ ಅಷ್ಟೇ ಸಾಮಾನ್ಯ: IPv6 ಗೆ ಮಾತ್ರ ಇರುವ ನಿಯಮಗಳ ಗುಂಪು v6 ನೀಡದ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.

ಕೊಂಡಿ ಏನು ನೀಡುತ್ತದೆ ಮತ್ತು ನೀತಿ ಏನನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಹಸ್ತಾಂತರದ ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಹೋಲಿಸಿ. ಈ ಆದೇಶಗಳು ಕ್ಲೈಂಟ್ ಕೆಲಸ ಮಾಡುವ ಅದೇ ಸಂಗತಿಗಳನ್ನು ಮುದ್ರಿಸುತ್ತವೆ:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

ಎರಡನೇ ಆದೇಶ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಮುದ್ರಿಸಿ ಮೂರನೆಯದು ಶೂನ್ಯ ಕೊಡುತ್ತಿದ್ದರೆ, ಹೊಸ ಕೊಂಡಿ ಯಾವುದೇ ನಿಯಮದ ಕಣ್ಣಿಗೆ ಬೀಳದೆ ಯಂತ್ರವನ್ನು IPv6 ಮೂಲಕ ಹೊರಗೆ ಕಳುಹಿಸಬಹುದು. ಬದಲಾವಣೆಯ ನಂತರ ಮೂರನ್ನೂ ಮತ್ತೆ ಓಡಿಸಿ, ಏಕೆಂದರೆ ಆಸಕ್ತಿಕರ ಸಂಖ್ಯೆ ಎರಡೂ ಓಟಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ. ಎರಡನೆಯದು ಏನನ್ನೂ ಮುದ್ರಿಸದಿದ್ದರೆ ವಿರುದ್ಧ ಪ್ರಕರಣ ಅನ್ವಯವಾಗುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿನ ಯಾವುದೇ v6-ಭಾರೀ ನೀತಿ ಬರೀ ಅಲಂಕಾರ.

ರಿಜಾಲ್ವರ್ ಅವಧಿಯ ಮಧ್ಯದಲ್ಲಿ ಕೈ ಬದಲಿಸುತ್ತದೆ

ಆಧುನಿಕ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ರಿಜಾಲ್ವರ್ಗಳು ಕೊಂಡಿಗಳಿಗೆ ಜೋಡಣೆಯಾಗಿರುತ್ತವೆ, ಆದ್ದರಿಂದ ಹೊಸ ಕೊಂಡಿ ಹೊಸ ರಿಜಾಲ್ವರ್ ಗುಂಪು ಮತ್ತು ಬಹುಶಃ ಬೇರೆ split-DNS ನೋಟದೊಂದಿಗೆ ಬರುತ್ತದೆ. systemd-resolved ಪ್ರತಿ ಕೊಂಡಿಗೆ ಒಂದು scope ಇಟ್ಟುಕೊಂಡು ಮಾರ್ಗದ ಆಧಾರದಲ್ಲಿ ಅವುಗಳ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, macOS ಆದರೋ ಡೈನಾಮಿಕ್ ಸ್ಟೋರ್ನಿಂದ scoped ರಿಜಾಲ್ವರ್ಗಳನ್ನು ಓದಿ ಇಂಟರ್ಫೇಸ್ ಕ್ರಮವನ್ನು ಗೌರವಿಸುತ್ತದೆ. ತನ್ನದೇ ರಿಜಾಲ್ವರ್ ಸ್ಥಾಪಿಸುವ ಕ್ಲೈಂಟ್ ಕೊಂಡಿಯದರೊಂದಿಗೆ ಸ್ಪರ್ಧಿಸುತ್ತದೆ, ಮತ್ತು ಯಾರೂ ನೋಡದ ಆದ್ಯತಾ ನಿಯಮಗಳು ವಿಜೇತರನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. ಆಗ ಹೆಸರು ಪರಿಹಾರ ಮುರಿಯಬಹುದು, ಪ್ಯಾಕೆಟ್ ಫಿಲ್ಟರಿಂಗ್ ಅದಕ್ಕಾಗಿ ಬರೆದ ಕೆಲಸವನ್ನೇ ಮಾಡುತ್ತಿರುವಾಗ.

ಸಂರಚಿಸಿದ ರಿಜಾಲ್ವರ್ ಬದಲು ಸಕ್ರಿಯವಾಗಿರುವುದನ್ನು ಓದಿ. systemd ಹೋಸ್ಟ್ನಲ್ಲಿ status ಉಪ ಆದೇಶ ಪ್ರತಿ scope ಯಾವ ಕೊಂಡಿಯಿಂದ ಬಂತು ಮತ್ತು private-DNS ಹೆಸರು ಜಾರಿಯಲ್ಲಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ:

resolvectl status --no-pager
resolvectl query intranet.example.com

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

ಹಸ್ತಾಂತರವನ್ನು ಅಭ್ಯಾಸ ಮಾಡಿ ಮತ್ತು ದಾಖಲೆ ಇರಿಸಿ

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

ಅಪವಾದಗಳಿಗೆ ತಮ್ಮದೇ ಹಾದಿ ಬೇಕು, ಏಕೆಂದರೆ ಹಳೆಯ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಸಮರ್ಥನೀಯವಾದ ಬಳಸು ಹೊಸದರಲ್ಲಿ ತಾನಾಗಿಯೇ ಸಮರ್ಥನೀಯವಲ್ಲ. ಮನೆಯ LAN ನಲ್ಲಿನ ಮುದ್ರಕ, NAS ಅಥವಾ captive portal ಸೆಲ್ಯುಲರ್ನಲ್ಲಿ ಸಮಾನವನ್ನು ಹೊಂದಿಲ್ಲ, ಮತ್ತು ಅವುಗಳಿಗೆ ತಲುಪುತ್ತಿದ್ದ ಅಪವಾದ ಸಮಾನವಿಲ್ಲದ ನಿಯಮವಾಗುತ್ತದೆ.

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