ಉತ್ತರ ಟನೆಲ್‌ನಿಂದಲ್ಲ, LAN ನಿಂದ ಹೊರಡುತ್ತದೆ: ಏಕೆ ಮತ್ತು ಹೇಗೆ

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

ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ನಿಜವಾಗಿ ನಿರ್ಧರಿಸುವುದು ಯಾವುದು

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

ಆದ್ದರಿಂದ ಟನೆಲ್‌ನಲ್ಲಿ ಸ್ವೀಕರಿಸಿದ ವಿನಂತಿ ಭೌತಿಕ ಇಂಟರ್‌ಫೇಸ್‌ನಿಂದ ಹೊರಹೋಗುವ ಉತ್ತರವನ್ನು ಉಂಟುಮಾಡಬಹುದು, ಮತ್ತು ಯಾವ ಸಾಧನವೂ ದೋಷ ವರದಿ ಮಾಡದೆ ಹರಿವು ಏಕಮುಖವಾಗುತ್ತದೆ. ಟನೆಲ್ ಬಗ್ಗೆ ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ತಪ್ಪು ದಿಕ್ಕಿಗೆ ಹೋಗುವ ಉತ್ತರ ಟನೆಲ್ ಕೌಂಟರ್‌ಗಳಿಂದ ಮಾಯವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಏನಾದರೂ ಕಳುಹಿಸಲಾಗಿದೆಯೇ ಎಂಬುದರಲ್ಲಿ ಎರಡು ತುದಿಗಳು ಒಪ್ಪುವುದಿಲ್ಲ. ಯಾವುದೇ ನಿಯಮಕ್ಕೆ ಮುಟ್ಟುವ ಮೊದಲು ಯಾವ ಕೌಂಟರ್ ಚಲಿಸಿತು ಎಂಬುದನ್ನು ಗಮನಿಸಿ.

ಸ್ಥಳೀಯ ಸಬ್‌ನೆಟ್ ಏಕೆ ಗೆಲ್ಲುತ್ತದೆ

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

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

ಪೀರ್ ಕವರೇಜ್ ಮತ್ತು ಸ್ಥಾಪಿತ ರೂಟ್‌ಗಳು ಒಂದೇ ಅಲ್ಲ

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

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

ಮೂಲ ವಿಳಾಸದ ಪ್ರಕಾರ ಕೋಷ್ಟಕ ಆರಿಸಿ

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

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

ಮಾರ್ಗವನ್ನು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಸೇವೆಯನ್ನು

ಕ್ಯಾಪ್ಚರ್‌ನಿಂದ ಊಹಿಸುವ ಬದಲು ಕರ್ನಲ್‌ಗೆ ಅದು ಏನು ಮಾಡುತ್ತಿತ್ತು ಎಂದು ಕೇಳಿ, ಸೇವಾ ವಿಳಾಸವನ್ನು ಮೂಲ ಆಯ್ಕೆದಾರನಾಗಿ ಬಳಸಿ. ಇಲ್ಲಿ ಸರಿಯಾದ ಉತ್ತರ ಸಂಪೂರ್ಣ ಪ್ಯಾಕೆಟ್ ಟ್ರೇಸ್ ಉಳಿಸುತ್ತದೆ.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

ಔಟ್‌ಪುಟ್ ಟನೆಲ್ ಅನ್ನು ಹೆಸರಿಸಬೇಕು. ನಂತರ ನೀವು ಮುಟ್ಟದ ಮೂಲವನ್ನು ಪರೀಕ್ಷಿಸಿ ಅದು ಇನ್ನೂ ಸ್ಥಳೀಯ ಕೊಂಡಿಯನ್ನೇ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಆಗ ಬದಲಾವಣೆ ಒಂದೇ ವಿಳಾಸಕ್ಕೆ ಸೀಮಿತವಾಗಿರುತ್ತದೆ. ಹೆಚ್ಚು ವಿಶಾಲ ಆಯ್ಕೆದಾರ ಮೂಲ ದೂರಿನ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುತ್ತಿರಲಿಲ್ಲ.

ಇದು ಏನನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ

ಗೇಟ್‌ವೇಯಲ್ಲಿ ಫಾರ್ವರ್ಡಿಂಗ್, ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳು ಮತ್ತು ICMPv6 ವರ್ತನೆಯನ್ನು ಹಿಂದಿದ್ದಂತೆಯೇ ಬಿಡಿ, ಏಕೆಂದರೆ ಮೂಲ-ರೂಟ್ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ. ಕಾಣೆಯಾದ Packet Too Big ಸಂದೇಶ ಯಾವ ಕೋಷ್ಟಕ ಗೆದ್ದರೂ ದೊಡ್ಡ ಉತ್ತರಗಳನ್ನು ಇನ್ನೂ ಮುರಿಯುತ್ತದೆ. ರೂಟಿಂಗ್ ನಿಯಮಗಳನ್ನು ಸೇರಿಸುವ ಮೊದಲು ಅದನ್ನು ಸರಿಪಡಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಬದಲಾವಣೆಯ ನಂತರವೂ ಲಕ್ಷಣ ಉಳಿಯುತ್ತದೆ.

ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಅನ್ವಯಿಸುವ ಮೊದಲು ಪ್ರಕಟಣಾ ಮಾದರಿಯನ್ನು ದೃಢೀಕರಿಸಿ. ತನ್ನದೇ ಬ್ಯಾಕೆಂಡ್ ಸಂಪರ್ಕ ತೆರೆಯುವ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ತನ್ನದೇ ಮೂಲವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ ಮತ್ತು ಕರೆಗಾರನನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಆ ವಿನ್ಯಾಸದಲ್ಲಿ ಈ ದೋಷ ಸಂಭವಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅಲ್ಲಿ ನಿಯಮ ಅನ್ವಯಿಸಿದರೆ ಏನನ್ನೂ ಪರಿಹರಿಸದ ಮತ್ತು ನಿಜ ಕಾರಣವನ್ನು ಮರೆಮಾಡುವ ರೂಟಿಂಗ್ ವಿನಾಯಿತಿ ಸೇರಿಸುತ್ತಿತ್ತು.

ಕೊನೆಯದಾಗಿ, ನಿಯಮ ಸಂಖ್ಯೆಗಳು ಮತ್ತು ಕೋಷ್ಟಕವನ್ನು ಹೋಸ್ಟ್‌ನ ಸಂರಚನಾ ನಿರ್ವಹಣೆಯಲ್ಲಿ ಬರೆಯಿರಿ. ಕೈಯಿಂದ ಸೇರಿಸಿದ ನೀತಿ ನಿಯಮ ಮುಂದಿನ ಪುನರ್ನಿರ್ಮಾಣದಲ್ಲಿ ಮಾಯವಾಗುತ್ತದೆ, ಮತ್ತು ಕಚೇರಿ ಕರೆಗಾರ ಅದೇ ದೂರಿನೊಂದಿಗೆ ಮರಳುತ್ತಾನೆ.