VPN ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ತಪ್ಪು ರೂಟ್ ಬಳಸುತ್ತದೆ

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

ಈ ರನ್‌ಬುಕ್‌ನ ಉಳಿದ ಭಾಗವು ನಾನು ಬಳಸುವ ಪರಿಶೀಲನಾ ಕ್ರಮ, ಪ್ರತಿ ವೀಕ್ಷಣೆಯನ್ನು ನೀಡುವ ಆಜ್ಞೆಯೊಂದಿಗೆ.

ಬೈಂಡ್ ನಿಜವಾಗಿ ಏನನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ

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

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

Linux IP ಸಾಕೆಟ್ ಉಲ್ಲೇಖ ಬೈಂಡ್‌ನ ಅರ್ಥವನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ರೂಟಿಂಗ್ ಅರ್ಧಭಾಗ ip-rule ಮತ್ತು ip-route ನಲ್ಲಿದೆ, ಮತ್ತು ಅವು ಒಂದು ಕಾರಣಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕ ಕೈಪಿಡಿಗಳು.

ವಿಳಾಸವು ಈ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗೆ ಸೇರಿದ್ದು ಎಂದು ಖಚಿತಪಡಿಸಿ

ನೀವು ಬದ್ಧ ಮಾಡಬಹುದಾದ ವಿಳಾಸವು ಅಪ್ಲಿಕೇಶನ್ ಚಲಿಸುವ ನೆಟ್‌ವರ್ಕ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ನೊಳಗಿನ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಇರಬೇಕು. ಪೀರ್ ವಿಳಾಸ, ಗೇಟ್‌ವೇ ವಿಳಾಸ, ಅಥವಾ ಬೇರೆ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಮಾತ್ರ ಇರುವ ವಿಳಾಸವನ್ನು ಬದ್ಧ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಕರೆ EADDRNOTAVAIL ನೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

ಆ ಮೂರನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನಂತೆಯೇ ಅದೇ ಸಂದರ್ಭದಲ್ಲಿ ಚಲಾಯಿಸಿ: ಅದೇ ನೇಮ್‌ಸ್ಪೇಸ್, ಮತ್ತು ಸಿಗುತ್ತಿದ್ದರೆ ಅದೇ ಬಳಕೆದಾರ. ಹಳೆಯ net30 ರೇಖಾಚಿತ್ರವು ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಟೋಪಾಲಜಿ ಕ್ಲೈಂಟ್‌ಗೆ ಯಾವ ವಿಳಾಸ ನೀಡಿತು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ. ನಿಜವಾಗಿ ಸಕ್ರಿಯವಾಗಿರುವ ಇಂಟರ್‌ಫೇಸ್ ಓದಿ.

ಆ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಲುಕಪ್ ಓದಿ

ಒಂದು ಆಜ್ಞೆ ಬೈಂಡ್ ಉತ್ತರಿಸದ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

ನಂತರ ip rule show ಯಾವುದಾದರೂ ನಿಯಮ ಬೇರೆ ಕೋಷ್ಟಕ ಆಯ್ಕೆ ಮಾಡುತ್ತಿತ್ತಾ ಎಂದು ಹೇಳುತ್ತದೆ. ಇಲ್ಲಿ ಆದ್ಯತೆಗಳು ಮುಖ್ಯ, ಏಕೆಂದರೆ ಮೊದಲು ಹೊಂದುವ ನಿಯಮ ಗೆಲ್ಲುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ನಿಯಮದ ಮೇಲಿರುವ ಎಲ್ಲವನ್ನೂ ಹಿಡಿಯುವ ನಿಯಮ ನಿಮ್ಮ ನಿಯಮವನ್ನು ಅಗೋಚರವಾಗಿಸುತ್ತದೆ.

ಅದೇ ವಿನ್ಯಾಸವಾಗಿದ್ದರೆ ಮಾತ್ರ ನೀತಿ ನಿಯಮ ಸ್ಥಾಪಿಸಿ

ಮೂಲ-ಆಧಾರಿತ ರೂಟಿಂಗ್ ಉದ್ದೇಶಪೂರ್ವಕ ವಿನ್ಯಾಸ, ಒಂದು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ದುರಸ್ತಿ ಅಲ್ಲ. ನೀತಿ ಮಾಲೀಕರು ಟನೆಲ್ ಸಬ್‌ನೆಟ್‌ನ ಸಂಚಾರ ಟನೆಲ್ ಬಳಸಬೇಕೆಂದು ಬಯಸಿದರೆ, ನಿಯಮ ಅವರ ಸಂರಚನೆಗೆ ಸೇರುತ್ತದೆ, ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿನ ಒಂದುಬಾರಿಯ ಆಜ್ಞೆಗೆ ಅಲ್ಲ.

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

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

ip rule del ಮತ್ತು ip route flush table 100 ಮೂಲಕ ಹಿಂಪಡೆಯಿರಿ. ಈ ರೀತಿ ಸೇರಿಸಿದ ಎಲ್ಲವೂ ಮರುಬೂಟ್‌ನಲ್ಲಿ ಮಾಯವಾಗುತ್ತದೆ, ಒಬ್ಬ ಮ್ಯಾನೇಜರ್ ಅದನ್ನು ಬರೆಯದಿದ್ದರೆ; ಇದು ಒಂದು ಭದ್ರತಾ ಗುಣವೂ ಮತ್ತು ಏಕೈಕ ಪ್ರತಿಯನ್ನು ನಿಮ್ಮ ಶೆಲ್ ಇತಿಹಾಸದಲ್ಲಿ ಇಡದಿರುವ ಕಾರಣವೂ ಆಗಿದೆ.

ಮೂರು ವೀಕ್ಷಣೆಗಳಿಂದ ಪರಿಶೀಲಿಸಿ

ಅಪ್ಲಿಕೇಶನ್ ಕೇಳಿದ ಮೂಲ, ಲುಕಪ್ ಆಯ್ಕೆ ಮಾಡಿದ ರೂಟ್, ಮತ್ತು ಸರ್ವರ್ ನಿಜವಾಗಿ ನೋಡಿದ ಮೂಲವನ್ನು ದಾಖಲಿಸಿ.

ಈ ಮೂರು ಭಿನ್ನವಾಗಬಹುದು, ಮತ್ತು ಪ್ರತಿ ಭಿನ್ನತೆ ಬೇರೆಡೆಗೆ ಸೂಚಿಸುತ್ತದೆ. ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವುದು ಪ್ಯಾಕೆಟ್ ಸರಿಯಾದ ಮೂಲದೊಂದಿಗೆ ಹೊರಟಿದೆ ಎಂದು ಸಾಬೀತು ಮಾಡುತ್ತದೆ. ಭೌತಿಕ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವುದು ಅದು ತಪ್ಪು ದಾರಿಯಲ್ಲಿ ಹೊರಟಿದೆ ಎಂದು ಸಾಬೀತು ಮಾಡುತ್ತದೆ. ಸರ್ವರ್-ಬದಿಯ ನೋಟವೊಂದೇ ಮಾರ್ಗವನ್ನು ತುದಿಯಿಂದ ತುದಿಗೆ ಸಾಬೀತು ಮಾಡುತ್ತದೆ.

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