ಎರಡು ಅಪ್ಲಿಂಕ್ fe80::1 ಹಂಚಿಕೊಂಡಾಗ IPv6 ನೀತಿ ಮಾರ್ಗನಿರ್ದೇಶನ

ನಿಮಗೆ ಎರಡು ಅಪ್ಲಿಂಕ್ ಇವೆ, ಮತ್ತು ip -6 route show ಎರಡರಲ್ಲೂ ಒಂದೇ ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಮುದ್ರಿಸುತ್ತದೆ: default via fe80::1 dev uplink0 ಮತ್ತು default via fe80::1 dev uplink1. ಇದು ನಕಲಿ ವಿಳಾಸದ ಘರ್ಷಣೆ ಅಲ್ಲ, ಮತ್ತು ಬರಿಯ ಮುಂದಿನ ಹಾಪ್ fe80::1 ಅನ್ನು ನೀತಿ ಕೋಷ್ಟಕಕ್ಕೆ ನಕಲಿಸುವುದು ಯಾವ ಲಿಂಕ್ ಎಂದು ನೀವು ಉದ್ದೇಶಿಸಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಕರ್ನಲ್ಗೆ ಹೇಳುವುದಿಲ್ಲ. ನಿಜವಾದ ಪ್ರಶ್ನೆ ಲಕ್ಷಣ ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಸಣ್ಣದು: ಎರಡನೇ ಕೋಷ್ಟಕಕ್ಕೆ ಒಂದು ಲಿಂಕ್ ಬೇಕೇ ಅಥವಾ ಎರಡೂ ಬೇಕೇ, ಮತ್ತು ಮರುಬೂಟ್ ನಂತರ ಆ ಮಾರ್ಗಗಳನ್ನು ಯಾವುದು ಜೀವಂತವಾಗಿ ಇಡುತ್ತದೆ. ಕ್ರಮವಾಗಿ ಪರಿಶೀಲಿಸುವ ಮೂರು ಷರತ್ತುಗಳು ಬಹುಪಾಲನ್ನು ಬಗೆಹರಿಸುತ್ತವೆ.

ಅದೇ fe80::1 ಎರಡು ವಿಭಿನ್ನ ನೆರೆಹೊರೆಯವರು

ಲಿಂಕ್-ಸ್ಥಳೀಯ ವಿಳಾಸಗಳು ಒಂದೇ ಲಿಂಕ್ಗೆ ಸೀಮಿತವಾಗಿವೆ, ಆದ್ದರಿಂದ fe80::1 ಎರಡು ಬಾರಿ ಮುದ್ರಿಸಿದ ಒಂದೇ ವಿಳಾಸವಲ್ಲ; ಅದು ಒಂದೇ ಅಂತ್ಯಪ್ರತ್ಯಯವನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಎರಡು ನೆರೆಹೊರೆಯವರು. ವಲಯ ಸೂಚ್ಯಂಕವು ಹೋಸ್ಟ್ ಯಾವುದನ್ನು ಉದ್ದೇಶಿಸಿದೆ ಎಂದು ಹೇಳುವ ವಿಧಾನ, ಆದ್ದರಿಂದ fe80::1%uplink0 ಮತ್ತು fe80::1%uplink1 ಕರ್ನಲ್ಗೆ ವಿಭಿನ್ನ ಗಮ್ಯಸ್ಥಾನಗಳು, ಮತ್ತು ಆ ಅಂತ್ಯಪ್ರತ್ಯಯ ಎಂದಿಗೂ ದೂರದ ರೌಟರ್ಗೆ ಹೋಗುವುದಿಲ್ಲ. RFC 4007 ಇದರ ಹಿಂದಿನ ವಲಯ ಮಾದರಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ನೀತಿ ಕೋಷ್ಟಕವು ಪ್ರತಿ ಲಿಂಕ್-ಸ್ಥಳೀಯ ಮುಂದಿನ ಹಾಪ್ ಜೊತೆಗೆ ಸಾಧನವನ್ನು ಹೊತ್ತಿರಬೇಕು.

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

ಸಾಧನವನ್ನು ತೆಗೆದರೆ ಮಾರ್ಗವು ಬರೆಯಲಾಗದಂತಾಗುತ್ತದೆ. ip -6 route add default via fe80::1 table 200 ಗೇಟ್ವೇಯನ್ನು ಪರಿಹರಿಸಲಾರದು, ಮತ್ತು iproute2 ಅದನ್ನು Error: Nexthop has invalid gateway. ದೋಷದೊಂದಿಗೆ ತಿರಸ್ಕರಿಸುತ್ತದೆ. dev uplink0 ಸೇರಿಸಿದರೆ ಆಜ್ಞೆ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಆ ಎರಡು ನೆರೆಹೊರೆಯವರಲ್ಲಿ ಒಬ್ಬರಿಗೆ ಬಿಗಿದಿರುವುದು ಸಾಧನವೇ. ಸಾಧನ ಹೇಳಲಾಗದ ವಿಷಯ ಎಂದರೆ uplink0 ಈ ಕೋಷ್ಟಕಕ್ಕೆ ಸರಿಯಾದ ಲಿಂಕ್ ಆಗಿದೆಯೇ ಎಂಬುದು, ಮತ್ತು ಇನ್ನೊಂದು ಹೋಸ್ಟ್ನಿಂದ ನಕಲಿಸಿದ ಮಾರ್ಗವು ಆ ಹೋಸ್ಟ್ನ ಇಂಟರ್ಫೇಸ್ ಹೆಸರುಗಳನ್ನು ಜೊತೆಗೆ ತರುತ್ತದೆ; ನಿಜವಾದ ತಪ್ಪುಗಳು ಅಲ್ಲಿಂದಲೇ ಬರುತ್ತವೆ.

ಷರತ್ತು ಒಂದು: ಕೋಷ್ಟಕದಲ್ಲಿ ಒಂದು ಲಿಂಕ್ ಅಥವಾ ಎರಡು

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

ಆ ಎರಡನೇ ಸಂದರ್ಭದಲ್ಲಿ ಕೋಷ್ಟಕವನ್ನು ಯಾವಾಗ ನೋಡಬೇಕೆಂದು ನಿಯಮ ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾರ್ಗ ನಿರ್ಧರಿಸುತ್ತದೆ:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

ಒಂದು ವಸ್ತು ಇನ್ನೊಂದಕ್ಕೆ ಬದಲಿಯಲ್ಲ, ಮತ್ತು ಕೇವಲ ಡಿಫಾಲ್ಟ್ ಇರುವ ಕೋಷ್ಟಕವೂ ತನ್ನ ಗೇಟ್ವೇಯನ್ನು ಪರಿಹರಿಸಲು ವಿಫಲವಾಗಬಹುದು. ಸೇರಿಸುವಿಕೆ ತಿರಸ್ಕೃತವಾದರೆ, ಅಥವಾ ಮಾರ್ಗ ಇದ್ದರೂ ಬಳಸಲಾಗದಿದ್ದರೆ, ಆ ಇಂಟರ್ಫೇಸ್ನ ಸಂಯೋಜಿತ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಅದೇ ಕೋಷ್ಟಕಕ್ಕೆ ಹಾಕಿ, ಅಥವಾ ಹಾಪ್ ಅನ್ನು onlink ಎಂದು ಗುರುತಿಸಿ (ಆ ಪ್ರಿಫಿಕ್ಸ್ ಬೇರೆಡೆ ಮಾರ್ಗಿತವಾದಾಗ). ಮೇಲಿನ ಬ್ಲಾಕ್ನಲ್ಲಿ 2001:db8:100::/48 uplink1 ನಲ್ಲಿನ ಆ ಸಂಯೋಜಿತ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಅನಿಯಂತ್ರಿತ ಗಮ್ಯಸ್ಥಾನವನ್ನಲ್ಲ. fwmark ನಿಯಮವು ಬೇರೆ ಯಾವುದೋ ಜೊತೆ ಹಾಕಬೇಕಾದ ಗುರುತನ್ನು ಮಾತ್ರ ಬಳಸುತ್ತದೆ: ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗದಲ್ಲಿನ nftables ಅಥವಾ iptables ನಿಯಮದಿಂದ, ಅಥವಾ SO_MARK ಸಾಕೆಟ್ನಿಂದ, ಆದ್ದರಿಂದ ಗುರುತಿನ ಮೂಲವಿಲ್ಲದೆ ನಕಲಿಸಿದ ಬ್ಲಾಕ್ ಯಾವುದಕ್ಕೂ ಹೊಂದುವುದಿಲ್ಲ.

ಷರತ್ತು ಎರಡು: ಮೆಟ್ರಿಕ್ಗಳು ಸತ್ತ ಪೂರೈಕೆದಾರರನ್ನು ಪತ್ತೆ ಮಾಡುವುದಿಲ್ಲ

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

ಕೋಷ್ಟಕ ಕಟ್ಟಿದ ನಂತರ ಆಯ್ಕೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಕರ್ನಲ್ ನೋಡುವ ರೀತಿಯಲ್ಲೇ ಪರಿಶೀಲಿಸಿ. ip -6 route get 2001:db8:100::1 ಬಳಸಲಾಗುವ ಮಾರ್ಗವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಅದರಲ್ಲಿ ಸಾಧನ ಮತ್ತು ಆಯ್ದ ಮೂಲ ವಿಳಾಸ ಸೇರಿವೆ, ಮತ್ತು ಅದು ನೀತಿ ನಿಯಮಗಳನ್ನು ಗೌರವಿಸುತ್ತದೆ. ತಪ್ಪು ಅಪ್ಲಿಂಕ್ಗೆ ಸೇರಿದ ಮೂಲ ವಿಳಾಸವು ಸಾಮಾನ್ಯವಾಗಿ ನಿಯಮವು ನೀವು ನಿರೀಕ್ಷಿಸಿದ್ದಕ್ಕಿಂತ ಮೊದಲೇ ಹೊಂದಿಕೆಯಾದ ಸೂಚನೆ.

ಷರತ್ತು ಮೂರು: ನಿರಂತರತೆಯ ಮಾಲೀಕತ್ವ ಯಾರಿಗೆ ಎಂದು ನಿರ್ಧರಿಸಿ

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

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

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

ಇತರ ಹೋಸ್ಟ್ಗಳಿಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ರೌಟರ್ನಲ್ಲಿ, ಕೋಷ್ಟಕವನ್ನು ದೂಷಿಸುವ ಮೊದಲು net.ipv6.conf.all.forwarding ಪರಿಶೀಲಿಸಿ. ಫಾರ್ವರ್ಡಿಂಗ್ ಆಫ್ ಆಗಿದ್ದರೆ, ಇನ್ನೊಂದು ನೆಟ್ವರ್ಕ್ಗೆ ವಿಳಾಸಿತ ಪ್ಯಾಕೆಟ್ಗಳು 201 ಕೋಷ್ಟಕ ಎಷ್ಟೇ ಸರಿಯಾಗಿದ್ದರೂ ಬಿಸಾಡಲ್ಪಡುತ್ತವೆ.

ಮುಂದಿನ ವ್ಯಕ್ತಿ ಆಡಿಟ್ ಮಾಡಲು ವಿನ್ಯಾಸವನ್ನು ದಾಖಲಿಸಿ

ಕೇವಲ fe80::1 ಸಂಗ್ರಹಿಸುವ ದಾಖಲೆ ಮುಖ್ಯ ಕ್ಷೇತ್ರಗಳನ್ನು ಬಿಸಾಡುತ್ತದೆ. ಗಮ್ಯಸ್ಥಾನ, ಮುಂದಿನ ಹಾಪ್, ಸಾಧನ, ಕೋಷ್ಟಕ ಮತ್ತು ಮೆಟ್ರಿಕ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ದಾಖಲಿಸಿ, ಜೊತೆಗೆ ಪ್ರತಿ ಮಾರ್ಗ ಎಲ್ಲಿಂದ ಬಂತು ಎಂಬುದನ್ನು: ಪ್ರಕಟಿತವೇ, ಮ್ಯಾನೇಜರ್ ರಚಿಸಿದ್ದೇ, ಅಥವಾ ಸ್ಥಿರವೇ. ನಂತರ ಯಾರಾದರೂ ಎರಡನೇ ಅಪ್ಲಿಂಕ್ ನಿಜವಾಗಿ ಸಂಚಾರ ಸಾಗಿಸುತ್ತಿದೆಯೇ ಎಂದು ಕೇಳಿದಾಗ, ಆ ದಾಖಲೆ ಊಹೆಯಿಲ್ಲದೆ ಉತ್ತರಿಸುತ್ತದೆ.

ಕೋಷ್ಟಕ ಮುಗಿಯಿತು ಎಂದು ಘೋಷಿಸುವ ಮೊದಲು, ನೆರೆಹೊರೆಯವರನ್ನು ip -6 neigh show dev uplink0 ನಿಂದ ದೃಢೀಕರಿಸಿ, ip -6 rule show ಅನ್ನು ಮತ್ತೆ ಓದಿ — ಕ್ರಮದ ಅನಿರೀಕ್ಷಿತಗಳಿಗಾಗಿ, ಮತ್ತು ನಿಯಮಕ್ಕೆ ಹೊಂದುವ ಸಂಚಾರದಿಂದ ಪರೀಕ್ಷಿಸಿ, ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳುವ ping ನಿಂದಲ್ಲ. ನಂತರ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಒಂದು ಅಪ್ಲಿಂಕ್ ಅನ್ನು ಆಫ್ ಮಾಡಿ ಮತ್ತು ಕರ್ನಲ್ ಯಾವ ಮಾರ್ಗಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತದೆ ಎಂದು ನೋಡಿ; ಉತ್ತರ ನೀವು ಬರೆದದ್ದಕ್ಕೆ ಹೊಂದಬೇಕು.