VPN ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ ಆದರೆ LAN ಸಾಧನಗಳನ್ನು ತಲುಪುವುದಿಲ್ಲ: ಏನನ್ನು ಪರಿಶೀಲಿಸಬೇಕು
ಗೇಟ್‌ವೇ ತನ್ನದೇ ವಿಳಾಸಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ ಆದರೆ ಅದರ ಹಿಂದೆ ಯಾವುದೂ ಉತ್ತರಿಸುವುದಿಲ್ಲ. ವಿಫಲವಾಗುವ ಗಡಿಯನ್ನು ಹುಡುಕಲು ಕ್ಲೈಂಟ್ ಹರಿವನ್ನು ಹೆಜ್ಜೆ ಹೆಜ್ಜೆಯಾಗಿ ಅನುಸರಿಸಿ.
ಸಂಚಾರವು ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ, ಗೇಟ್‌ವೇ ತನ್ನದೇ ವಿಳಾಸಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಹಿಂದೆ ಯಾವುದೂ ಉತ್ತರಿಸುವುದಿಲ್ಲ. ಈ ಮಾದರಿ ಸಾಮಾನ್ಯವಾಗಿದೆ ಮತ್ತು ಇದು ವಿರೋಧಾಭಾಸವಲ್ಲ: ಗೇಟ್‌ವೇಯಿಂದ ಬರುವ ಉತ್ತರವು ಸುರಂಗವು ಮುಗಿದಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಅದರಾಚೆ ವಿಳಾಸಗೊಳಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಎರಡೂ ಪರೀಕ್ಷೆಗಳು ಒಂದೇ ಯಂತ್ರದಲ್ಲಿ ವಿಭಿನ್ನ ಕೋಡ್ ಮಾರ್ಗಗಳನ್ನು ಬಳಸುತ್ತವೆ.
ಇನ್ನು ಮುಂದೆ ಗೇಟ್‌ವೇಯ ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಏನನ್ನಾದರೂ ಪರೀಕ್ಷಿಸಿ. ಫಾರ್ವರ್ಡಿಂಗ್ ಎಷ್ಟೇ ಮುರಿದಿದ್ದರೂ ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ವಿಳಾಸವು ಉತ್ತರಿಸುತ್ತಲೇ ಇರುತ್ತದೆ.
ಗೇಟ್‌ವೇ ತನ್ನದೇ ಸ್ಟ್ಯಾಕ್‌ನಿಂದ ಉತ್ತರಿಸುತ್ತದೆ
ಗೇಟ್‌ವೇಗೆ ವಿಳಾಸಗೊಳಿಸಿದ ಪ್ಯಾಕೆಟ್ ಅದರ ಸ್ಥಳೀಯ ಇನ್‌ಪುಟ್ ಮಾರ್ಗಕ್ಕೆ ತಲುಪಿಸಲಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಕರ್ನಲ್ ಕೇಳುತ್ತಿರುವ ಸಾಕೆಟ್ ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. ಗೇಟ್‌ವೇಯ ಹಿಂದಿನ ಹೋಸ್ಟ್‌ಗೆ ವಿಳಾಸಗೊಳಿಸಿದ ಪ್ಯಾಕೆಟ್ ಬದಲಿಗೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗಕ್ಕೆ ತಲುಪಿಸಲಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಬೇರೆ ಪರಿಶೀಲನೆಗಳ ಗುಂಪು ಅನ್ವಯಿಸುತ್ತದೆ. ಫಾರ್ವರ್ಡಿಂಗ್ ಸಂಪೂರ್ಣವಾಗಿ ನಿಷ್ಕ್ರಿಯವಾಗಿರಬಹುದು, ಅಥವಾ ಕರ್ನಲ್ ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ ನಂತರ ಸುರಂಗವನ್ನು ಎಂದಿಗೂ ಉಲ್ಲೇಖಿಸದ ಫಿಲ್ಟರ್ ನಿಯಮವು ಅದನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ಉತ್ತರವನ್ನು ಪ್ರಭಾವಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಈ ಲಕ್ಷಣವು ಎಷ್ಟು ನಂಬಲರ್ಹವಾಗಿ ದಾರಿತಪ್ಪಿಸುತ್ತದೆ.
ಸುರಂಗದ ಮೂಲಕ ತಲುಪುವ ಆಡಳಿತ ಪುಟಗಳೂ ಮೊದಲ ವರ್ಗಕ್ಕೆ ಸೇರುತ್ತವೆ. ಅವು ಸುರಂಗದ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯ, ಅದರ ಹಿಂದಿನ ಜಾಲದ ಬಗ್ಗೆ ಅಲ್ಲ.
ಹರಿವನ್ನು ಅದನ್ನು ಬೀಳಿಸುವ ಮೊದಲ ಗಡಿಯವರೆಗೆ ಅನುಸರಿಸಿ
ಕ್ಲೈಂಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಹರಿವು ಬಳಸುವ ಮಾರ್ಗ ಹಾಗೂ ಮೂಲ ವಿಳಾಸವನ್ನು ದೃಢೀಕರಿಸಿ. ನಂತರ ಗೇಟ್‌ವೇಯಲ್ಲಿ ಅದೇ ನಿಖರ ಹರಿವು ಬರುತ್ತಿರುವುದನ್ನು, ಮತ್ತು ಮತ್ತೆ ಅದೇ ಹರಿವು LAN ಕಡೆಗೆ ಹೋಗುತ್ತಿರುವುದನ್ನು ಗಮನಿಸಿ. ಅದು ಎಂದಿಗೂ ಬರದಿದ್ದರೆ, ಸಮಸ್ಯೆ ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿದೆ ಅಥವಾ ಸುರಂಗದ ಅನುಮತಿಸಲಾದ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳಲ್ಲಿದೆ. ಅದು ಬಂದು ಎಂದಿಗೂ ಹೋಗದಿದ್ದರೆ, ಸಮಸ್ಯೆ ಫಾರ್ವರ್ಡಿಂಗ್‌ನಲ್ಲಿದೆ ಅಥವಾ ಮುಂದಿನ ಮಾರ್ಗದ ಫಿಲ್ಟರ್‌ನಲ್ಲಿದೆ, ಮತ್ತು ಸೆರೆಹಿಡಿಯುವಿಕೆ ಈಗಾಗಲೇ ಯಾವುದೆಂದು ಹೇಳಿದೆ.
ಅದೇ ಪರೀಕ್ಷೆಯನ್ನು ಗೇಟ್‌ವೇಯಿಂದ ನಡೆಸುವುದು ಆಸಕ್ತಿದಾಯಕ ಅರ್ಧವನ್ನು ಮರೆಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಗೇಟ್‌ವೇಯಿಂದ ಹುಟ್ಟಿದ ಪ್ಯಾಕೆಟ್‌ಗೆ ಬೇರೆ ಮೂಲ ಮತ್ತು ಬೇರೆ ಮರಳುವ ಅಗತ್ಯವಿರುತ್ತದೆ. ಪ್ರತಿ ಹೆಜ್ಜೆಯಲ್ಲೂ ಕ್ಲೈಂಟ್‌ನ ಹರಿವನ್ನು ಅದರ ಸ್ವಂತ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಬಳಸಿ. ತಪ್ಪು ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ತೆಗೆದ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಆತ್ಮವಿಶ್ವಾಸದ ಅಸಂಬದ್ಧತೆಯನ್ನು ನೀಡುತ್ತದೆ.
ಮರಳುವ ಮಾರ್ಗಗಳು ಮತ್ತು ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್‌ಗಳು ಪ್ರತ್ಯೇಕವಾಗಿ ವಿಫಲವಾಗುತ್ತವೆ
ಪ್ಯಾಕೆಟ್ ಹೋಸ್ಟ್ ಅನ್ನು ತಲುಪಿದ ನಂತರ ಇನ್ನೂ ಮೂರು ವಿಷಯಗಳು ನಿಜವಾಗಿರಬೇಕು. ಸೇವೆಯು ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸಿದ ವಿಳಾಸದಲ್ಲಿ ಕೇಳುತ್ತಿರಬೇಕು, ಹೋಸ್ಟ್ ಫೈರ್‌ವಾಲ್ ಅದನ್ನು ಸ್ವೀಕರಿಸಬೇಕು, ಮತ್ತು ಉತ್ತರಕ್ಕೆ ಕ್ಲೈಂಟ್ ಪೂಲ್‌ನ ಕಡೆಗೆ ಮರಳುವ ಮಾರ್ಗವಿರಬೇಕು. ಕೊನೆಯದು ಹೆಚ್ಚಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಹೋಸ್ಟ್‌ನ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವು ಸುರಂಗದ ವ್ಯಾಪ್ತಿಯ ಬಗ್ಗೆ ಎಂದಿಗೂ ಕೇಳದ ರೌಟರ್‌ಗೆ ತೋರಿಸುತ್ತದೆ. ಫಲಿತಾಂಶವೆಂದರೆ ಹೋಸ್ಟ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ ಸ್ಥಾಪನೆಯಾಗಿ ಇನ್ನೊಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಸದ್ದಿಲ್ಲದೆ ಸಾಯುವ ಸಂಪರ್ಕ.
ಕ್ಲೈಂಟ್‌ನಿಂದ ಕಳುಹಿಸಿ ಮರಳುವಿಕೆಯನ್ನು ಗಮನಿಸುವ ಮೂಲಕ ಮರಳುವ ಮಾರ್ಗವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ. ಏಕಮುಖ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಒಂದು ಗಂಟೆಯ ಊಹೆ ಪರಿಹರಿಸದ್ದನ್ನು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಪರಿಹರಿಸುತ್ತದೆ.
ಕ್ಲೈಂಟ್‌ನ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಪ್ರತಿ ಹಾಪ್ ದೃಢೀಕರಿಸಿ
ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮದಲ್ಲಿ ಚಲಾಯಿಸಿ ಮತ್ತು ಪ್ರತಿ ಔಟ್‌ಪುಟ್ ಉಳಿಸಿ, ಏಕೆಂದರೆ ಮೌಲ್ಯವು ಹೋಲಿಕೆಯಲ್ಲಿದೆ, ಒಂದೇ ಸಾಲಿನಲ್ಲಿಲ್ಲ. ಕೆಳಗಿನ ಆದೇಶಗಳು ಮೂಲ ವಿಳಾಸವನ್ನು ಸ್ಥಿರಪಡಿಸುತ್ತವೆ, ಆಯ್ಕೆಮಾಡಿದ ಮಾರ್ಗವನ್ನು ತೋರಿಸುತ್ತವೆ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್‌ನ ಎರಡೂ ಬದಿಗಳನ್ನು ಸೆರೆಹಿಡಿಯುತ್ತವೆ. ನಿಮ್ಮ ಸ್ವಂತ LAN ಹೋಸ್ಟ್ ಮತ್ತು ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ ಬದಲಾಯಿಸಿ.
ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20ಮಾರ್ಗ ಪ್ರಶ್ನೆಯು ಕ್ಲೈಂಟ್ ಆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ping ಹೋಸ್ಟ್ನಿಂದ ಏನಾದರೂ ಮರಳಿ ಬಂದಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಎರಡೂ ಸೆರೆಹಿಡಿಯುವಿಕೆಗಳನ್ನು ಹೋಲಿಸುವುದು ಆಗಮನವನ್ನು ನಿರ್ಗಮನದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಸುರಂಗ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿರುವ ಚೌಕಟ್ಟಿಗೆ LAN ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಸಮಾನವಿಲ್ಲದಿದ್ದರೆ ಅದು ಸೇವಾ ವೈಫಲ್ಯವಲ್ಲ, ಫಾರ್ವರ್ಡಿಂಗ್ ನಿರ್ಧಾರ. ಎರಡೂ ಸೆರೆಹಿಡಿಯುವಿಕೆಗಳು ವಿನಂತಿಯನ್ನು ತೋರಿಸಿ ಕೇವಲ ಒಂದು ಉತ್ತರವನ್ನು ತೋರಿಸಿದಾಗ, ಉಳಿದ ಶಂಕಿತ ಮರಳುವ ಮಾರ್ಗ.
ಯಾವ ವಿಳಾಸ ಉತ್ತರಿಸಿತು ಮತ್ತು ಯಾವ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಗಮ್ಯಸ್ಥಾನ ವಿಫಲವಾಯಿತು ಎಂದು ದಾಖಲಿಸಿ. ಆ ವಾಕ್ಯವೇ ವರದಿಯನ್ನು ಸರ್ವರ್ ತಲುಪಲಾಗದು ಎಂಬ ಹೇಳಿಕೆಯ ಬದಲು ಕ್ರಿಯಾತ್ಮಕವಾಗಿಸುತ್ತದೆ.