ICMP ಮರುನಿರ್ದೇಶನಗಳು ಮತ್ತು ನಿಮ್ಮ VPN ಮಾರ್ಗಗಳು: ವಾಸ್ತವವಾಗಿ ಏನು ಬದಲಾಗುತ್ತದೆ

ಸುರಂಗದ ಮೂಲಕ ಹೋಗಬೇಕಾದ ಹರಿವು ಬೇರೆ ಮುಂದಿನ ಹಾಪ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಯಾರೋ ಕ್ಯಾಪ್ಚರ್ನಲ್ಲಿ ICMP ಮರುನಿರ್ದೇಶನವನ್ನು ಕಾಣುತ್ತಾರೆ. ಅದು ಊಹೆ, ರೋಗನಿರ್ಣಯವಲ್ಲ. ಮರುನಿರ್ದೇಶನವು ಉತ್ತಮ ಮುಂದಿನ ಹಾಪ್ ಬಗ್ಗೆ ರೌಟರ್ನ ಸಲಹೆ, ಮತ್ತು ಹೋಸ್ಟ್ ಅದರ ಮೇಲೆ ಕ್ರಿಯೆ ನಡೆಸುತ್ತದೆಯೇ ಎಂಬುದು ವೇದಿಕೆ, ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ವಿಳಾಸ ಕುಟುಂಬದಿಂದ ಭಿನ್ನವಾಗುವ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಅವಲಂಬಿಸಿದೆ.

ಮರುನಿರ್ದೇಶನವು ರೌಟರ್ನಿಂದ ಬರುವ ಸಲಹೆ

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

ಕಳುಹಿಸುವವರು ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಸ್ವಾತಂತ್ರ್ಯ ಹೊಂದಿದ್ದಾರೆ. ಪ್ರೋಟೋಕಾಲ್ ಹೋಸ್ಟ್ ತನ್ನ ಕೋಷ್ಟಕ ಬದಲಿಸಬೇಕೆಂದು ಒತ್ತಾಯಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸೆರೆಹಿಡಿದ ಮರುನಿರ್ದೇಶನವು ರೌಟರ್ ಒಂದನ್ನು ಕಳುಹಿಸಿದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.

ಬಹುಪಾಲು ಮರುನಿರ್ದೇಶನ ತನಿಖೆಗಳು ತಪ್ಪಾಗುವುದು ಈ ವ್ಯತ್ಯಾಸದಲ್ಲಿಯೇ.

IPv4 ಮತ್ತು IPv6 ಅದನ್ನು ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ತಲುಪಿಸುತ್ತವೆ

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

ನೀತಿ ಸೆಟ್ಟಿಂಗ್ಗಳೂ ಪ್ರತ್ಯೇಕ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ IPv4 ಮರುನಿರ್ದೇಶನಗಳನ್ನು ಸ್ವೀಕರಿಸಿ IPv6 ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು, ಅಥವಾ ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ.

ಪ್ರಶ್ನೆಯಲ್ಲಿರುವ ಹರಿವು ಎರಡನ್ನೂ ಬಳಸಬಹುದಾದರೆ ಎರಡೂ ಕುಟುಂಬಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

ಸ್ವೀಕಾರವು ಹೋಸ್ಟ್ ನೀತಿ, ಜಾಲದ ಸತ್ಯವಲ್ಲ

Linux ನಲ್ಲಿ ಮರುನಿರ್ದೇಶನ ಸ್ವೀಕಾರವು ಇಂಟರ್ಫೇಸ್ ಪ್ರಕಾರ ಮತ್ತು ಜಾಗತಿಕವಾಗಿ ನಿಯಂತ್ರಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳು ಹೋಸ್ಟ್ ಮತ್ತು ರೌಟರ್ ಪಾತ್ರಗಳಲ್ಲಿ ಭಿನ್ನವಾಗಿವೆ. ಮರುನಿರ್ದೇಶನಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ ವಿಚಿತ್ರ ವಿನ್ಯಾಸ, ಏಕೆಂದರೆ ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಸುರಂಗದೊಳಗೆ ಅದೇ ಲಿಂಕ್ನ ಪರ್ಯಾಯ ಮುಂದಿನ ಹಾಪ್ಗೆ ಅರ್ಥವಿಲ್ಲ. ಆದ್ದರಿಂದ ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಊಹಿಸುವ ಬದಲು ಓದುವುದು ಯೋಗ್ಯ.

ಸುರಕ್ಷಿತ ಮರುನಿರ್ದೇಶನ ಸೆಟ್ಟಿಂಗ್ಗಳು ಯಾವ ಗೇಟ್ವೇಗಳನ್ನು ನಂಬಬಹುದು ಎಂಬುದನ್ನು ಇನ್ನಷ್ಟು ನಿರ್ಬಂಧಿಸುತ್ತವೆ.

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

ಮರುನಿರ್ದೇಶನ ವಿವರಿಸಲಾಗದ್ದು

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

ಹಳೆಯ ಕ್ಯಾಪ್ಚರ್ ಇನ್ನೊಂದು ಬಲೆ, ಏಕೆಂದರೆ ಜಾಲ ಬದಲಿಸಿದ ಕ್ಲೈಂಟ್ಗೆ ಬೇರೆ ಸ್ಥಳೀಯ ಗೇಟ್ವೇ ಇರುತ್ತದೆ.

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

ಸುರಂಗವನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

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

ರಕ್ಷಿತ ಮಾರ್ಗವು ಮೌನವಾಗಿ ಅರಕ್ಷಿತವಾಗುವುದಕ್ಕೆ ಮರುನಿರ್ದೇಶನ ಕಾರಣವಾಗಬಾರದು, ಆದ್ದರಿಂದ ಸ್ವೀಕಾರ ನೀತಿ ವಿನ್ಯಾಸ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಇರಬೇಕು. RFC 792 ವ್ಯಾಖ್ಯಾನ IPv4 ಸಂದೇಶ ಏನು ಹೇಳಬಹುದು ಎಂಬುದಕ್ಕೆ ಮಾನದಂಡವಾಗಿ ಉಳಿಯುತ್ತದೆ.

ಮಾರ್ಗ ಹುಡುಕಾಟದ ಫಲಿತಾಂಶ ಮತ್ತು ಕ್ಯಾಪ್ಚರ್ ಸಮಯವನ್ನು ಒಟ್ಟಿಗೆ ಬರೆಯಿರಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ನಿಮ್ಮ ತೀರ್ಮಾನವನ್ನು ಪುನರಾವರ್ತಿಸಬಹುದು.