ಟ್ರಾಫಿಕ್ ನಿಜವಾಗಿಯೂ VPN ಮೂಲಕ ಹೋಗುತ್ತಿದೆಯೇ? ಅದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಹೇಗೆ
ರೂಟ್ ಹುಡುಕಾಟ, ಮೊದಲ ಹಾಪ್, ಭೌತಿಕ ಅಡಾಪ್ಟರ್‌ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಮತ್ತು ಹೊರಗಿನಿಂದ ವಿಳಾಸ ಪರಿಶೀಲನೆ ಪ್ರಶ್ನೆಯ ಬೇರೆ ಬೇರೆ ಭಾಗಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ.
ಟ್ರೇ ಐಕಾನ್‌ನಿಂದ ಎರಡು ವೈಫಲ್ಯಗಳು ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ: ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸುವ ಟ್ರಾಫಿಕ್ ಮತ್ತು ಅದನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಳಸಿಕೊಂಡು ಹೋಗುವ ಟ್ರಾಫಿಕ್. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಕ್ಲೈಂಟ್ Connected ತೋರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ Connected ಎಂದರೆ ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್ ಇದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ತನಗೆ ಬೇಕಾದ ರೂಟ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸಿದೆ ಎಂಬುದಷ್ಟೇ. ಒಂದು ಅಪ್ಲಿಕೇಶನ್‌ನ ಒಂದು ಪ್ಯಾಕೆಟ್ ಆ ರೂಟ್‌ಗಳನ್ನು ಬಳಸಿತೇ ಎಂಬುದು ಬೇರೆ ಪ್ರಶ್ನೆ, ಅದಕ್ಕೆ ಸ್ಟ್ಯಾಕ್‌ನ ಬೇರೆಡೆ ಉತ್ತರ ಸಿಗುತ್ತದೆ. ನಾಲ್ಕು ಅಳತೆಗಳು ಅದರ ಬಹುಪಾಲನ್ನು ಪರಿಹರಿಸುತ್ತವೆ — ರೂಟ್ ಹುಡುಕಾಟ, ಮೊದಲ ಹಾಪ್, ಭೌತಿಕ ಅಡಾಪ್ಟರ್‌ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಮತ್ತು ಹೊರಗಿನಿಂದ ವೀಕ್ಷಣೆ — ಮತ್ತು ಸರ್ವರ್‌ನ ಸ್ವಂತ ಸೆಷನ್ ನೋಟ ಉಳಿದದ್ದನ್ನು ಆವರಿಸುತ್ತದೆ.
ಪ್ಯಾಕೆಟ್ ತೆಗೆದುಕೊಳ್ಳುವ ರೂಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ
ರೂಟಿಂಗ್ ಟೇಬಲ್ ಎಂಬುದೇ ನಿರ್ಧಾರ, ಆದ್ದರಿಂದ ಇಡೀ ಟೇಬಲ್ ಓದಿ ಊಹಿಸುವ ಬದಲು ಒಂದು ಗಮ್ಯಸ್ಥಾನದ ಬಗ್ಗೆ ಕೇಳಿ. Linux ನಲ್ಲಿ, ip route get ಕರ್ನಲ್ ಆಯ್ಕೆ ಮಾಡಿದ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮೂಲ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ:
ip route get 203.0.113.10
ip route get 10.20.5.7Windows ನಲ್ಲಿ, Find-NetRoute -RemoteIPAddress 203.0.113.10 route print -4 ಗಿಂತ ಹೆಚ್ಚು ಉಪಯುಕ್ತ, ಅದೇ ಕಾರಣಕ್ಕೆ: ಅದು ಗೆದ್ದ ರೂಟ್ ಅನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಇರುವ ಎಲ್ಲಾ ರೂಟ್‌ಗಳನ್ನಲ್ಲ. ಹಾಗಿದ್ದರೂ 0.0.0.0 ಸಾಲಿಗಾಗಿ ಟೇಬಲ್ ಅನ್ನು ಒಮ್ಮೆ ಓದಿ. ಅಲ್ಲಿ /1 ಜೋಡಿ ಇದ್ದರೆ ಪೂರ್ಣ ಸುರಂಗ ಕ್ಲೈಂಟ್ ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಅನ್ನು ಮತ್ತೆ ಬರೆದಿದೆ ಎಂದರ್ಥ: OpenVPN ನ redirect-gateway def1 ಆಯ್ಕೆ ಸುರಂಗದ ಮೂಲಕ 0.0.0.0/1 ಮತ್ತು 128.0.0.0/1 ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಅದು ಭೌತಿಕ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಅಳಿಸದೆ ದೀರ್ಘ ಪೂರ್ವಪದ ಹೊಂದಾಣಿಕೆಯಲ್ಲಿ ಇರುವ 0.0.0.0/0 ಅನ್ನು ಸೋಲಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಎರಡು ಡೀಫಾಲ್ಟ್ ರೂಟ್‌ಗಳು ಜೊತೆಯಾಗಿರಬಹುದು, ಎಲ್ಲವೂ ಇನ್ನೂ ಸುರಂಗಕ್ಕೆ ಹೋಗುತ್ತಿರುವಾಗ.
ಎರಡು ವಿವರಗಳು ಟೇಬಲ್ ಅನ್ನು ಸುಳ್ಳುಗೊಳಿಸುತ್ತವೆ. ಮೊದಲನೆಯದಾಗಿ, ಡೀಫಾಲ್ಟ್ ರೂಟ್‌ಗಳ ಸಂಖ್ಯೆಯಲ್ಲ, ಹೊಂದಿದ ಪೂರ್ವಪದವನ್ನು ನೋಡಿ, ಏಕೆಂದರೆ ಇಂಟರ್ಫೇಸ್ ಮೆಟ್ರಿಕ್ ಅಥವಾ /1 ಜೋಡಿ ವಿಜೇತರನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ, ಈಗಾಗಲೇ ಇರುವ ಸಂಪರ್ಕವು ತಾನು ಸ್ಥಾಪಿತವಾದ ಮಾರ್ಗವನ್ನೇ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ; ಸುರಂಗ ಏರಿದ ನಂತರ, ತೆರೆದ ಸೆಷನ್ ಮರುಹೊಂದಿಸುವವರೆಗೆ ಹಳೆಯ ರೂಟ್ ಬಳಸುತ್ತಿರಬಹುದು, ಆದ್ದರಿಂದ ಮರುಸಂಪರ್ಕ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಿದಂತೆ ಕಾಣುತ್ತದೆ. ಚಾಲನೆಯಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ — ps ax | grep openvpn — ಪ್ರಕ್ರಿಯೆ ಪ್ರಾರಂಭವಾಯಿತು ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತು ಮಾಡುತ್ತದೆ.
ಒಂದು ಆಂತರಿಕ ಮತ್ತು ಒಂದು ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಜಾಡಿಸಿ
ರೂಟ್ ಹುಡುಕಾಟ ಉದ್ದೇಶವನ್ನು ತೋರಿಸುತ್ತದೆ; ಮಾರ್ಗ ವಿತರಣೆಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಸಂಪರ್ಕದಲ್ಲಿರುವಾಗ ಆಂತರಿಕವಾಗಿರಬೇಕಾದ ಹೆಸರು ಮತ್ತು ಇರಬಾರದ ಹೆಸರನ್ನು ಜಾಡಿಸಿ, ಮೊದಲ ಹಾಪ್ ಅನ್ನು ಹೋಲಿಸಿ:
traceroute intranet.corp.example
traceroute 1.1.1.1ಎರಡಕ್ಕೂ ಒಂದೇ ಮೊದಲ ಹಾಪ್ ಎಂದರೆ ಆಂತರಿಕ ಹೆಸರು ಎಂದೂ ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸಲಿಲ್ಲ ಮತ್ತು ದೋಷ ಅದರ ಮೇಲಿದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುವ ಹೆಸರು ಅಥವಾ ಎಂದೂ ಸ್ಥಾಪಿಸದ ರೂಟ್. ಆಂತರಿಕ ಟ್ರಾಫಿಕ್ 10.8.0.1 ಮೂಲಕ ಹೊರಟು ಸಾರ್ವಜನಿಕ ಟ್ರಾಫಿಕ್ 192.168.1.1 ಮೂಲಕ ಹೊರಟರೆ, ವಿಭಜಿತ ಸುರಂಗ ನಿಖರವಾಗಿ ತನಗೆ ಸಂರಚಿಸಿದ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಿದೆ. VPN ಗೇಟ್‌ವೇ ತಲುಪಿ ನಂತರ ಕೇವಲ ಸಮಯ ಮೀರುವಿಕೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸುವ ಜಾಡು ಸಾಮಾನ್ಯವಾಗಿ ಹಿಂತಿರುಗು ಮಾರ್ಗ ಅಥವಾ ಸರ್ವರ್ ಫೈರ್‌ವಾಲ್ ಸಮಸ್ಯೆ, ಕಾಣೆಯಾದ ಫಾರ್ವರ್ಡ್ ರೂಟ್ ಅಲ್ಲ.
ಫಿಲ್ಟರ್ ಮಾಡಿದ ICMP ಈ ಪರಿಶೀಲನೆಯನ್ನು ಸುಳ್ಳುಗೊಳಿಸುತ್ತದೆ: ಎರಡೂ ಜಾಡುಗಳಲ್ಲಿ ನಕ್ಷತ್ರಗಳು ಸತ್ತ ಸುರಂಗದಂತೆ ಕಾಣುತ್ತವೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಅದು ಫೈರ್‌ವಾಲ್. ಸಾಧ್ಯವಿರುವಲ್ಲಿ TCP ಪೋರ್ಟ್ ಪರೀಕ್ಷಿಸಿ — Linux ನಲ್ಲಿ traceroute -T -p 443 — ಮತ್ತು ಜಾಡು ಯಾವ ಪರಿಹಾರಕ ಉತ್ತರಿಸಿತು ಎಂದು ಹೇಳುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ: ಹೆಸರು ಸ್ಥಳೀಯವಾಗಿ ಪರಿಹರಿಸಿ ಸುರಂಗದ ಮೂಲಕವೂ ತಲುಪಬಹುದು.
ಸುರಂಗದಲ್ಲಿ ಅಲ್ಲ, ಭೌತಿಕ ಅಡಾಪ್ಟರ್‌ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ
ನೆಟ್‌ವರ್ಕ್ ನಿಜವಾಗಿ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುವ ಏಕೈಕ ಸ್ಥಳ ಭೌತಿಕ ಕೊಂಡಿ. ಸುರಂಗ ಏರಿದಾಗ, ಕಚೇರಿಗೆ ಹೋಗುವ ಸೆಷನ್ VPN ಸರ್ವರ್‌ಗೆ ಉದ್ದೇಶಿಸಿದ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಪೇಲೋಡ್ ಆಗಿ ಕಾಣಬೇಕು, 10.20.5.7 ಗೆ ಸಂಪರ್ಕವಾಗಿ ಅಲ್ಲ:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5ಮೊದಲ ಫಿಲ್ಟರ್ ಸ್ಥಳೀಯವಾಗಿ ಹೊರಹೋಗುವ ಹೆಸರು ಪರಿಹಾರವನ್ನು ಹಿಡಿಯುತ್ತದೆ, ಅದು ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಮತ್ತು ಅತ್ಯಂತ ಮೌನ ಸೋರಿಕೆ — ಪುಟ ಇನ್ನೂ ಲೋಡ್ ಆಗುತ್ತದೆ, ಪರಿಹಾರಕ ಕ್ವೆರಿಯನ್ನು ನೋಡಿತು ಅಷ್ಟೇ. ಎರಡನೆಯದು ಸುರಂಗದ ಒಳಗೆ ಮಾತ್ರ ಇರಬೇಕಾದ ಆಂತರಿಕ ವಿಳಾಸಕ್ಕೆ ಸಾಮಾನ್ಯ ಟ್ರಾಫಿಕ್ ಹಿಡಿಯುತ್ತದೆ. Windows ನಲ್ಲಿ, pktmon ಡ್ರೈವರ್ ಇಲ್ಲದೆ ಅದೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ: pktmon filter add -p 53, ನಂತರ pktmon start --capture --pkt-size 128, ನಂತರ pktmon stop ಮತ್ತು pktmon format pktmon.etl -o capture.txt. ಈ ಫ್ಲ್ಯಾಗ್‌ಗಳು Windows ಆವೃತ್ತಿಗಳ ನಡುವೆ ಸ್ವಲ್ಪ ಭಿನ್ನ, ಆದ್ದರಿಂದ ಸಿಂಟ್ಯಾಕ್ಸ್ ನಂಬುವ ಮೊದಲು pktmon filter add /? ಪರಿಶೀಲಿಸಿ.
ಸೋರಿಕೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಸೆರೆಹಿಡಿಯಿರಿ; ಸುರಂಗದಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವುದು ಅಲ್ಲಿ ಇವೆ ಎಂದು ನೀವು ಈಗಾಗಲೇ ನಂಬುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಮತ್ತು ಸರ್ವರ್‌ನಲ್ಲಿ ಮೂಲ ಗೇಟ್‌ವೇ ಆಗಿರುವ ಓದಲಾಗದ ಹೊರ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಯಾವುದೇ ಇಂಟರ್ಫೇಸ್‌ನ ಬೈಟ್ ಕೌಂಟರ್‌ಗಳು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ, ಪ್ರೋಗ್ರಾಮ್‌ಗಳನ್ನಲ್ಲ; ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೆ ಆರೋಪಿಸಲು ಸಾಕೆಟ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ನಕ್ಷೆ ಮಾಡುವ ಮಾನಿಟರ್ ಬೇಕು.
ಹೊರಗಿನ ಸೇವೆಯನ್ನು ಕೇಳಿ, ನಂತರ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೂ ಮತ್ತೆ ಕೇಳಿ
ನಿರ್ಗಮನವನ್ನು ಸಾಬೀತು ಮಾಡುವ ಏಕೈಕ ಪರಿಶೀಲನೆ ಹೊರಗಿನಿಂದ ಬರುವ ಉತ್ತರ: ತಾನು ನೋಡಿದ ಮೂಲ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸುವ ಸೇವೆ. ಇಂಟರ್ಫೇಸ್ ಆಯ್ಕೆ ಮಾಡಬಹುದಾದ ಶೆಲ್‌ನಿಂದ ಅದನ್ನು ಚಲಾಯಿಸಿ, ಮತ್ತು ಎರಡು ಬಾರಿ ಚಲಾಯಿಸಿ:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipಬೇರೆ ಬೇರೆ ಉತ್ತರಗಳು ಎರಡೂ ಮಾರ್ಗಗಳ ಪುರಾವೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್ ಪರೀಕ್ಷಿಸುವ ದಾರಿ ಕೊಡುತ್ತವೆ: ಅದನ್ನು ಬೈಂಡ್ ಮಾಡಿ, ಅಥವಾ ಒಂದೇ ರೂಟ್ ಇರುವ ನೆಟ್‌ವರ್ಕ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಚಲಾಯಿಸಿ, ದೂರದ ತುದಿ ಯಾವ ವಿಳಾಸವನ್ನು ದಾಖಲಿಸುತ್ತದೆ ಎಂದು ನೋಡಿ. ಒಂದೇ ರೀತಿಯ ಉತ್ತರಗಳು ಕುತೂಹಲಕರ ವೈಫಲ್ಯ: ಬೈಂಡಿಂಗ್ ಪರಿಣಾಮ ಬೀರಲಿಲ್ಲ, ಅಥವಾ ಹೋಸ್ಟ್ ಮತ್ತು ದೂರದ ತುದಿಯ ನಡುವೆ ಏನೋ ತಲುಪುವ ಮೊದಲು ಮೂಲ ವಿಳಾಸವನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ. Windows ನಲ್ಲಿ, curl --interface ಅಡಾಪ್ಟರ್‌ನ ಹೆಸರಲ್ಲ, ವಿಳಾಸವನ್ನು ಬಯಸುತ್ತದೆ.
VPN ವಿಳಾಸವನ್ನು ವರದಿ ಮಾಡುವ ಬ್ರೌಸರ್ ಬ್ರೌಸರ್ ಅನ್ನು ಸಾಬೀತು ಮಾಡುತ್ತದೆ. ಮೇಲ್ ಕ್ಲೈಂಟ್, ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್, ಬ್ಯಾಕಪ್ ಏಜೆಂಟ್ ಅಥವಾ ಎರಡನೇ ಬ್ರೌಸರ್ ಪ್ರೊಫೈಲ್ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ವಿಶೇಷವಾಗಿ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ಅಥವಾ ವಿಭಜಿತ ಸುರಂಗ ರೂಟ್ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಆವರಿಸಿದಾಗ. ವಿಳಾಸ ಬದಲಾವಣೆ ತಾನೇ ಸೋರಿಕೆಯ ಪುರಾವೆ ಅಲ್ಲ: ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ತಾನು ನೋಡಿದ ನಿರ್ಗಮನದ ಪ್ರಕಾರ ಬೇರೆ ರೀತಿ ಉತ್ತರಿಸಬಹುದು, ಆದ್ದರಿಂದ ಪುಟವಲ್ಲ, ದಾಖಲಾದ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೋಲಿಸಿ.
ಪೀರ್ ಅನ್ನು ದೃಢೀಕರಿಸಲು ಸರ್ವರ್ ನೋಟ ಬಳಸಿ
ಸರ್ವರ್ ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಪೀರ್ ಸಂಪರ್ಕದಲ್ಲಿದೆಯೇ, ಎಷ್ಟು ಸಾಗಿಸಿದೆ ಮತ್ತು ಸೆಷನ್ ಮರುಪ್ರಾರಂಭವಾಯಿತೇ. ಸರ್ವರ್‌ನಲ್ಲಿ ಪೀರ್ ಸಕ್ರಿಯವಾಗಿದ್ದು ಕ್ಲೈಂಟ್ ಕೌಂಟರ್‌ಗಳು ಬಹುತೇಕ ಚಲಿಸದಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಟೇಬಲ್ ಏನೇ ಹೇಳಿದರೂ ಅಪ್ಲಿಕೇಶನ್ ಟ್ರಾಫಿಕ್ ಸುರಂಗಕ್ಕೆ ಪ್ರವೇಶಿಸುತ್ತಿಲ್ಲ ಎಂದರ್ಥ. ಏನೂ ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲ ಎಂದು ಹೇಳುವ ಬಳಕೆದಾರರಿಗೆ ಸಾಕಷ್ಟು ಡೇಟಾ ಸಾಗಿಸುವ ಪೀರ್ ಬೇರೆ ತನಿಖೆ.
ಇಲ್ಲಿ ಎರಡು ಬಲೆಗಳಿವೆ. ಮಸ್ಕರೇಡ್ ಮಾಡಿದ ಸುರಂಗ ಪ್ರತಿ ಹರಿವನ್ನೂ ಗೇಟ್‌ವೇಯಿಂದ ಬಂದಂತೆ ತೋರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಲಾಗ್‌ಗಳು ಮತ್ತು ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಲೆಕ್ಕಾಚಾರ ಒಂದೇ ವಿಳಾಸದಲ್ಲಿ ಕುಸಿಯುತ್ತವೆ. ಮತ್ತು ಕ್ಲೈಂಟ್ ಅನ್ನು ಸ್ಥಳೀಯ ಹೋಸ್ಟ್ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾರಾದರೂ VPN ಮೂಲಕ ಫೈಲ್‌ಗಳನ್ನು ನಕಲಿಸುತ್ತಿದ್ದಾರೆಯೇ ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಸರ್ವರ್‌ನಲ್ಲಿ ಫೈಲ್ ಹಂಚಿಕೆ ಟ್ರಾಫಿಕ್ ಅಥವಾ ಸರ್ವರ್‌ನಲ್ಲಿ ಹೋಸ್ಟ್ ಆಡಿಟ್ ಉತ್ತರಿಸುತ್ತದೆ — ಸುರಂಗವನ್ನು ಗಮನಿಸುವುದು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು ಮತ್ತು ಪ್ರಮಾಣ ಕೊಡುತ್ತದೆ, ಫೈಲ್ ಹೆಸರುಗಳಲ್ಲ.
ವಿನ್ಯಾಸ ನಿರ್ಧಾರವನ್ನು ಸೋರಿಕೆಯಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ
ಸುರಂಗದ ಹೊರಗಿನ ಎಲ್ಲವೂ ಸೋರಿಕೆ ಅಲ್ಲ. ಲಿಂಕ್-ಲೋಕಲ್ ಮತ್ತು ಪ್ರಸಾರ ಟ್ರಾಫಿಕ್ ವಿನ್ಯಾಸದ ಪ್ರಕಾರ ಸ್ಥಳೀಯವಾಗಿ ಉಳಿಯುತ್ತದೆ, ಮಲ್ಟಿಕಾಸ್ಟ್ ಮೂಲಕ ಕಂಡುಬಂದ ಮುದ್ರಕ LAN ನಲ್ಲಿ ಘೋಷಣೆ ಮುಂದುವರಿಸುತ್ತದೆ, ಮತ್ತು DHCP ಸ್ಥಳೀಯವಾಗಿ ಹೊರಬರಬೇಕು. ನಿರ್ದಿಷ್ಟ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಬದ್ಧವಾದ ಅಪ್ಲಿಕೇಶನ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ರೂಟಿಂಗ್ ಟೇಬಲ್ ಬಳಸಿಕೊಂಡು ಹೋಗುತ್ತದೆ, ಅದನ್ನು ಫೈರ್‌ವಾಲ್ ನಿಯಮ, ನೇಮ್‌ಸ್ಪೇಸ್ ಅಥವಾ ಪಾಲಿಸಿ ರೂಟ್ ಮಾತ್ರ ಬದಲಿಸುತ್ತದೆ.
IPv6 ಚೆಕ್‌ಲಿಸ್ಟ್‌ನಲ್ಲಿ ತನ್ನದೇ ಸಾಲಿಗೆ ಅರ್ಹ. IPv4 ಮಾತ್ರ ಸಾಗಿಸುವ ಸುರಂಗ ದ್ವಿ-ಸ್ಟ್ಯಾಕ್ ಹೋಸ್ಟ್‌ಗೆ ಎರಡನೇ ಬಳಸಬಹುದಾದ ಮಾರ್ಗ ಬಿಡುತ್ತದೆ, ಮತ್ತು ದ್ವಿ-ಸ್ಟ್ಯಾಕ್ ಗಮ್ಯಸ್ಥಾನ ಅದನ್ನೇ ಆದ್ಯತೆ ನೀಡುತ್ತದೆ — DNS ಸೇರಿದಂತೆ, ಪರಿಹಾರಕ IPv6 ಮೂಲಕ ತಲುಪಬಹುದಾದರೆ. IPv4 ಫಲಿತಾಂಶವನ್ನು ಪೂರ್ಣ ಎಂದು ಪರಿಗಣಿಸುವ ಮೊದಲು ಅಡಾಪ್ಟರ್‌ನಲ್ಲಿ IPv6 ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ ಅಥವಾ ಸುರಂಗ ಅದನ್ನು ಸಾಗಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
ಪರಿಶೀಲನೆಗಳು ಒಂದಕ್ಕೊಂದು ಹೊಂದಿಕೆಯಾಗದಿದ್ದಾಗ, ವ್ಯತ್ಯಾಸವೇ ಸಾಮಾನ್ಯವಾಗಿ ದೋಷವನ್ನು ಹೆಸರಿಸುತ್ತದೆ:
| What you see | What it means | Next step |
|---|---|---|
| The route picks tun0 but the capture shows cleartext to 10.20.5.7 | Something bypassed the table: a bound app, a policy route or a session older than the tunnel | Reset the flow, check the app bind, check the ip rule list |
| The route picks eth0 for an internal name | The name resolves to a public address, or the route was never installed | Compare the resolved address with the routes the server pushes |
| The capture shows DNS to the LAN resolver | Resolver leak: data is tunneled, lookups are not | Point the resolver inside, or push it from the server |
| All four checks agree and one app still fails | Path selection is fine; suspect MTU, a per-app proxy or the far end | Test the same destination from a known-good client |
ಕೆಲಸ ಮಾಡುವ ಕ್ರಮ: ಸಂಪರ್ಕಕ್ಕೆ ಮೊದಲು ಮತ್ತು ನಂತರ ರೂಟಿಂಗ್ ಟೇಬಲ್ ಉಳಿಸಿ, ಒಂದು ಆಂತರಿಕ ಮತ್ತು ಒಂದು ಸಾರ್ವಜನಿಕ ಹೆಸರು ಜಾಡಿಸಿ, ಭೌತಿಕ ಅಡಾಪ್ಟರ್‌ನಲ್ಲಿ DNS ಸೆರೆಹಿಡಿಯಿರಿ, ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ಶೆಲ್‌ನಿಂದ ನಿರ್ಗಮನ ವಿಳಾಸ ಹಿಂತಿರುಗಿಸಿ, ನಂತರ ಪ್ರಮಾಣಕ್ಕಾಗಿ ಸರ್ವರ್ ಓದಿ. ಮೊದಲ ನಾಲ್ಕು ಹೊಂದಿಕೆಯಾದರೆ, ಸುರಂಗ ನೀವು ಭಾವಿಸುವುದನ್ನು ಸಾಗಿಸುತ್ತಿದೆ ಮತ್ತು ಉಳಿದ ಸಮಸ್ಯೆ ಅದರ ಮೇಲಿದೆ. ಅವುಗಳಲ್ಲಿ ಎರಡು ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಹೊಂದಿಕೆಯಾಗದ ಜೋಡಿಯೇ ದೋಷ, ಐಕಾನ್ ಅಲ್ಲ.