VPN ಮೂಲಕ ping: ಪ್ರತಿಧ್ವನಿ ಉತ್ತರದ ನಿಯಮಗಳು ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಏಕೆ ತಪ್ಪುತ್ತವೆ

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

ಪ್ಯಾಕೆಟ್ ಪೋರ್ಟ್ ಅಲ್ಲ, ಪ್ರಕಾರ ಬದಲಾಗುತ್ತದೆ

ಪ್ರತಿಧ್ವನಿ ವಿನಂತಿ ICMP ಪ್ರಕಾರ 8, ಕೋಡ್ 0, ಮತ್ತು ಅದು ಗುರುತಿಸುವಿಕೆ ಹಾಗೂ ಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಒಯ್ಯುತ್ತದೆ. ಉತ್ತರ ಪ್ರಕಾರ 0, ಕೋಡ್ 0, ಅದೇ ಗುರುತಿಸುವಿಕೆ ಮತ್ತು ಕ್ರಮದೊಂದಿಗೆ, ಮತ್ತು IP ತುದಿಗಳು ಬದಲಾಗಿವೆ. ಆ ಕ್ಷೇತ್ರಗಳನ್ನು RFC 792 ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಮತ್ತು ಗುರುತಿಸುವಿಕೆಯೇ ಕಳುಹಿಸುವವನಿಗೆ ಉತ್ತರಗಳನ್ನು ತನ್ನ ವಿನಂತಿಗಳೊಂದಿಗೆ ಹೊಂದಿಸಲು ಅವಕಾಶ ಕೊಡುತ್ತದೆ.

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

ಮೂರು ಸಂದರ್ಭಗಳು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ

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

ಈ ಮೂರು ಸಂದರ್ಭಗಳಿಗೆ ಬೇರೆ ಬೇರೆ ನಿಯಮ ಸರಪಳಿಗಳು ಮತ್ತು ಕೌಂಟರ್‌ಗಳಿವೆ, ಮತ್ತು ಅವನ್ನು ಒಂದೇ ಎಂದು ಪರಿಗಣಿಸುವುದೇ «ಫೈರ್‌ವಾಲ್ ICMP ಗೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ» ಎಂದರೂ ping ವಿಫಲವಾಗುವ ಕಾರಣ. ಹೊರಗಿನ ಸುರಂಗ ನಾಲ್ಕನೇ ಸಂದರ್ಭ: VPN ಶ್ರೋತೃಕ್ಕೆ ಅನುಮತಿ ನೀಡುವುದು ಡಿಕ್ಯಾಪ್ಸುಲೇಟ್ ಆದ ಒಳಗಿನ ವಿನಂತಿಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಒಳಗಿನ ಅನುಮತಿ ಹೊರಗಿನ ಸುರಂಗ ಕೆಲಸ ಮಾಡುತ್ತಿದೆಯೇ ಎಂಬ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ.

ಸ್ಟೇಟ್‌ಫುಲ್ ಮತ್ತು ಸ್ಟೇಟ್‌ಲೆಸ್ ಫಿಲ್ಟರ್‌ಗಳು ಉತ್ತರವನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ನಿಭಾಯಿಸುತ್ತವೆ

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

ಏನನ್ನಾದರೂ ಬರೆಯುವ ಮೊದಲು ಉತ್ಪನ್ನವು ನಿಜವಾಗಿ ಯಾವ ಮಾದರಿಯನ್ನು ಅಳವಡಿಸಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಪ್ರತಿಧ್ವನಿ ವಿನಂತಿಗೆ ಇರುವ ನಿಯಮ ಪ್ರತಿಧ್ವನಿ ಉತ್ತರವನ್ನು ಕಡ್ಡಾಯವಾಗಿ ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು ICMP ಪ್ರಶ್ನೆಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವ ಉತ್ಪನ್ನವೂ ಇನ್ನೊಂದು ಇಂಟರ್ಫೇಸ್‌ಗೆ ಬರುವ ಉತ್ತರಗಳಿಗೆ ಬೇರೆ ನೀತಿ ಅನ್ವಯಿಸಬಹುದು.

ನೀವು ಅನುಮತಿಸುವುದರ ವ್ಯಾಪ್ತಿಯನ್ನು ಮಿತಿಗೊಳಿಸಿ. ಎಲ್ಲಿಂದಲಾದರೂ ಪ್ರತಿ ಪ್ರತಿಧ್ವನಿ ಉತ್ತರಕ್ಕೆ ಅನುಮತಿ ನೀಡುವುದು ಸ್ಟೇಟ್‌ಫುಲ್ ಸಂಬಂಧವನ್ನು ಪೂರ್ಣಗೊಳಿಸುವುದಕ್ಕೆ ಸಮವಲ್ಲ, ಮತ್ತು ಪ್ರಕಾರ ಸಂಖ್ಯೆ ಕಳುಹಿಸುವವನನ್ನು ದೃಢೀಕರಿಸುವುದಿಲ್ಲ.

ಅನುವಾದವು ಗುರುತಿಸುವಿಕೆಯನ್ನೂ ಬದಲಿಸುತ್ತದೆ

ಮೂಲ ಅನುವಾದವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿದ್ದರೆ, ದೂರದ ತುದಿಯಲ್ಲಿನ ಟ್ಯುಪಲ್ ಕ್ಲೈಂಟ್ ಕಳುಹಿಸಿದ್ದಕ್ಕೆ ಹೊಂದುವುದಿಲ್ಲ. NAT ICMP ಪ್ರಶ್ನೆಯ ಗುರುತಿಸುವಿಕೆಯನ್ನು ವಿಳಾಸಗಳ ಜೊತೆಗೆ ಅನುವಾದಿಸಬಹುದು, ಆದ್ದರಿಂದ ಎರಡೂ ಕಡೆ ಅದೇ ಸಂಖ್ಯೆ ಕಾಣಬೇಕೆಂದು ಒತ್ತಾಯಿಸುವುದು ಸುಳ್ಳು ಹೊಂದಾಣಿಕೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

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

ICMP ದೋಷಗಳನ್ನು ಪ್ರತಿಧ್ವನಿ ನೀತಿಗೆ ಸೇರಿಸಬೇಡಿ

ಮಾರ್ಗದ MTU ಅನ್ವೇಷಣೆ ಬಳಸುವ «ಖಂಡೀಕರಣ ಬೇಕು» ಸಂದೇಶ ಪ್ರತಿಧ್ವನಿ ಉತ್ತರವಲ್ಲ, ಮತ್ತು ಅದರ ಪೇಲೋಡ್ ಅದನ್ನು ಪ್ರಚೋದಿಸಿದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ. ಪ್ರತಿಧ್ವನಿಗೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡುವ ನಿಯಮ ಆ ದೋಷಗಳನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಟ್ಟುಬಿಟ್ಟರೆ ಗಾತ್ರದ ಸಮಸ್ಯೆ ನೇತಾಡುವ ಸಂಪರ್ಕವಾಗುತ್ತದೆ, ಅದು ಸಹಾಯಕವಾಗುವುದಕ್ಕೆ ವಿರುದ್ಧ.

ಅದೇ ಎಚ್ಚರ ವಿಳಾಸ ಕುಟುಂಬಗಳಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ. ICMPv6 ಬೇರೆ ಸಂದೇಶ ಪ್ರಕಾರಗಳನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು IPv4 ಹೊಂದಿಲ್ಲದ ಅಗತ್ಯ ಕಾರ್ಯಗಳನ್ನು ಒಯ್ಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಈ ಸಂಖ್ಯೆಗಳನ್ನು IPv6 ನಿಯಮಕ್ಕೆ ನಕಲಿಸುವುದು ನೇರವಾಗಿ ತಪ್ಪು.

ಪ್ರತಿಧ್ವನಿ ವಿನಿಮಯ ಕೆಲಸ ಮಾಡಿದಾಗ ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ. ಯಶಸ್ವಿ ping ಒಂದು ಪ್ರೋಟೋಕಾಲ್ ಒಂದು ಗಾತ್ರದಲ್ಲಿ ಒಂದು ಗಮ್ಯಕ್ಕೆ ಹೋಗಿ ಬರುವುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು HTTPS, SMB ಅಥವಾ ಬೇರೆ ಯಾವುದೇ ಹರಿವಿಗೆ ಅನುಮತಿ ಇದೆ ಎಂದು ಊಹಿಸುವ ಪರವಾನಗಿ ಅಲ್ಲ.