ಸ್ಪ್ಲಿಟ್ ಟನೆಲಿಂಗ್ ಯಾವ ಸಂಚಾರವು VPN ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ಹೇಗೆ ನಿರ್ಧರಿಸುತ್ತದೆ

ಸ್ಪ್ಲಿಟ್ ಟನೆಲಿಂಗ್ ಎಂಬುದು ನಿಯಮಗಳ ಗುಂಪಾಗಿ ವ್ಯಕ್ತವಾಗುವ ರೂಟಿಂಗ್ ನೀತಿ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಅವುಗಳನ್ನು ಸ್ಥಾಪಿಸುವ ವಸ್ತು ಮಾತ್ರ। ಬೇರ್ಪಡುವಿಕೆ ಎರಡು ಕಡೆ ನಡೆಯುತ್ತದೆ: ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ಗೆ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆಮಾಡುವ ಹೊಂದಿಕೆ ನಿಯಮಗಳು, ಮತ್ತು ಟೇಬಲ್ ಏನೇ ಹೇಳಲಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಒಂದು ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಹಿಡಿದಿಡುವ ಬೈಂಡಿಂಗ್ಗಳು। ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಯಾವ ಯಾಂತ್ರಿಕೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ ಎಂಬುದು ಜನರು ವರದಿ ಮಾಡುವ ಹೆಚ್ಚಿನ ಆಶ್ಚರ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ।

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

ಕ್ಲೈಂಟ್ ನಿಯಮಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಕರ್ನಲ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ

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

ಅದಕ್ಕಾಗಿಯೇ ಸ್ಪ್ಲಿಟ್ ಟನೆಲ್ ನಿರಂಕುಶವಾಗಿ ಕಾಣಬಹುದು। ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್ನ ಎರಡು ಗಮ್ಯಸ್ಥಾನಗಳು ಬೇರೆ ಬೇರೆ ಮಾರ್ಗಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಕೇವಲ ಒಂದು ಪ್ರಿಫಿಕ್ಸ್ ಇನ್ನೊಂದಕ್ಕಿಂತ ಸಣ್ಣದಾಗಿರುವುದರಿಂದ।

ಅದೇ ಆಯ್ಕೆ ಪ್ರತಿ ಪ್ಲಾಟ್ಫಾರ್ಮ್ನಲ್ಲೂ ಇದೆ, ಹೆಸರುಗಳು ಬದಲಾದರೂ। Windows ತನ್ನ ಫಿಲ್ಟರ್ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗೆ ನಿರ್ಧಾರವನ್ನು ತಳ್ಳುತ್ತದೆ, Android ತನ್ನ VPN ಸೇವೆಯ ಮೂಲಕ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಅನುಮತಿ ಪಟ್ಟಿಯನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ, ಮತ್ತು macOS ರೂಟಿಂಗ್ ಟೇಬಲ್ ಅನ್ನು ಇನ್ನೂ ಪಾಲಿಸುವ ಸಾಧನಕ್ಕೆ ಟನೆಲ್ ಅನ್ನು ಜೋಡಿಸುತ್ತದೆ। Microsoftನ ರೂಟಿಂಗ್ ಟಿಪ್ಪಣಿಗಳು Windows ಪ್ರಕರಣಕ್ಕೆ ಓದಲು ಯೋಗ್ಯವಾಗಿವೆ, ಮತ್ತು ಒಂದು ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಾಗಿ ಬರೆದ ಮಾರ್ಗದರ್ಶಿ ಅಪರೂಪವಾಗಿ ಬದಲಾವಣೆಯಿಲ್ಲದೆ ಇನ್ನೊಂದಕ್ಕೆ ವರ್ಗಾವಣೆಯಾಗುತ್ತದೆ।

ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಬೈಂಡಿಂಗ್ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಬೇರೆ ಬೇರೆ ಸಾಧನಗಳು

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

ಹೆಸರು ಆಧಾರಿತ ನೀತಿಯನ್ನು ಯಾವುದೇ ವಿಧಾನವೂ ಸಹಾಯವಿಲ್ಲದೆ ತಡೆದುಕೊಳ್ಳುವುದಿಲ್ಲ। ದೊಡ್ಡ ಸೈಟ್ಗಳ ವಿಳಾಸಗಳು ವಿಷಯ ಜಾಲಗಳ ನಡುವೆ ತಿರುಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ನಾಮ್ ಅನ್ನು ಕೆಲವು ಪ್ರಿಫಿಕ್ಸ್ಗಳಿಗೆ ಪಿನ್ ಮಾಡುವುದು ಮೌನವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸುವ ನಿಯಮವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ। ಹೆಸರುಗಳನ್ನು ಅನುಸರಿಸಬೇಕಾದ ನೀತಿಗೆ ಸ್ಥಿರ ಮಾರ್ಗದ ಬದಲು ರೆಸಾಲ್ವರ್-ಅರಿವಿನ ಘಟಕ ಬೇಕು।

DNS ಮತ್ತು ಕಿಲ್ ಸ್ವಿಚ್ ತಮ್ಮ ಸ್ವಂತ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸುತ್ತವೆ

ಹೆಸರಿನ ವಿಭಜನೆ ಪ್ಯಾಕೆಟ್ ರೂಟಿಂಗ್ನಿಂದ ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರ, ಮತ್ತು ಸ್ಪ್ಲಿಟ್ ಟನೆಲ್ಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ರೆಸಾಲ್ವರ್ಗಳು ಬೇಕು: ಒಳಗಿನ ಹೆಸರುಗಳಿಗೆ ಕಂಪನಿಯದು, ಉಳಿದ ಎಲ್ಲದಕ್ಕೂ ಸ್ಥಳೀಯದು। ಕ್ಲೈಂಟ್ ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ DNS ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಸ್ಥಾಪಿಸಬಹುದು, ಪ್ರಶ್ನೆಗಳನ್ನು ಮಧ್ಯವರ್ತಿ ರೆಸಾಲ್ವರ್ಗೆ ನೀಡಬಹುದು, ಅಥವಾ ಸಿಸ್ಟಮ್ ಡಿಫಾಲ್ಟ್ ಅನ್ನು ಮುಟ್ಟದೆ ಬಿಡಬಹುದು। ತನ್ನದೇ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ರೆಸಾಲ್ವರ್ ಹೊಂದಿರುವ ಬ್ರೌಸರ್ ಮೂರೂ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡುತ್ತದೆ। ರೆಸಾಲ್ವರ್ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಿದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಒಂದು ಹುಡುಕಾಟವನ್ನು ಪರೀಕ್ಷಿಸಿ।

ಕಿಲ್ ಸ್ವಿಚ್ ಮೇಲೆ ಫಿಲ್ಟರ್ ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಫಿಲ್ಟರ್ ಉದ್ದೇಶಿತ ಹೊರಗಿಡುವಿಕೆಯನ್ನು ಆಕಸ್ಮಿಕ ಸೋರಿಕೆಯಿಂದ ಯಾವಾಗಲೂ ಪ್ರತ್ಯೇಕಿಸುವುದಿಲ್ಲ। ಕೆಲವು ಕ್ಲೈಂಟ್ಗಳು ಟನೆಲ್ನ ಹೊರಗಿನ ಎಲ್ಲವನ್ನೂ ಬ್ಲಾಕ್ ಮಾಡುತ್ತವೆ, ಇನ್ನು ಕೆಲವು ನೀತಿ ಘೋಷಿಸಿದ ಹೊರಗಿಡುವಿಕೆಗಳನ್ನು ಅನುಮತಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಯಾವುದನ್ನೂ ಅವಲಂಬಿಸುವ ಮೊದಲು ನಿಮ್ಮದು ಯಾವ ವರ್ತನೆಯನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುತ್ತದೆ ಎಂದು ಓದಿ।

ಎರಡೂ ಕಡೆಗಳಿಂದ ವಿಭಜನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ

ಸೇರಿಸಿದ ಮಾರ್ಗ ಮತ್ತು ಹೊರಗಿಡಲಾದ ಮಾರ್ಗವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಸಾರ್ವಜನಿಕ ವಿಳಾಸದಿಂದ ಅಲ್ಲ, ಇಂಟರ್ಫೇಸ್ ಹೆಸರಿನಿಂದ ನಿರ್ಣಯಿಸಿ। ಈ ಆದೇಶಗಳು ಟನೆಲ್ ಸಾಧನವು ಈಗಾಗಲೇ ಮೇಲಿರುವ Linux ಹೋಸ್ಟ್ ಅನ್ನು ಊಹಿಸುತ್ತವೆ। 203.0.113.10 ಅನ್ನು ನಿಮ್ಮ ನೀತಿ ಒಳಕ್ಕೆ ರೂಟ್ ಮಾಡುವ ಗಮ್ಯಸ್ಥಾನದಿಂದ, ಮತ್ತು 198.51.100.25 ಅನ್ನು ಅದು ಹೊರಕ್ಕೆ ಕಳುಹಿಸುವ ಒಂದರಿಂದ ಬದಲಾಯಿಸಿ।

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

ಮೊದಲ ಎರಡು ಉತ್ತರಗಳನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದರಲ್ಲೂ ಹೆಸರಿಸಿದ ಇಂಟರ್ಫೇಸ್ ಆ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಟನೆಲ್ಗೆ ಇರಿಸಲಾಗಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ। ರೆಸಾಲ್ವರ್ ಪ್ರಶ್ನೆ ಒಳಗಿನ ಹೆಸರಿಗೆ ಯಾವ ಸರ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಕೊನೆಯ ಆದೇಶ ಟನೆಲ್ ಸಾಧನವು ವಿನಂತಿಯನ್ನು ಸಾಗಿಸಬಲ್ಲದು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ। ಮೊದಲ ಸಾಲು ಯಶಸ್ವಿಯಾದಾಗ ಎರಡನೇ ಸಾಲಿನಲ್ಲಿ ವೈಫಲ್ಯ ಎಂದರೆ ನೀತಿ ತನಗೆ ಹೇಳಿದ್ದನ್ನು ನಿಖರವಾಗಿ ಮಾಡುತ್ತಿದೆ।

ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಮತ್ತು ಜಾಲಬಂಧ ಬದಲಾದ ನಂತರ ಗುಂಪನ್ನು ಪುನರಾವರ್ತಿಸಿ। ಲೀಜ್ ನವೀಕರಣ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ಗಳ ಚಲನೆ ಎಂಬುದು ವಿಭಜನೆಯು ತಾನು ನಿರ್ಮಿಸಿದ ಉದ್ದೇಶಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸುವ ಸ್ಥಳಗಳು, ಮತ್ತು ಪ್ರತಿ ರನ್ನ ಉಳಿಸಿದ ಔಟ್ಪುಟ್ ವಿಚಲನೆಯನ್ನು ಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ।