ಸಾಮಾನ್ಯ Linux ಅಪ್ಲಿಕೇಶನ್ TUN ಮುಟ್ಟದೆ VPN ಬಳಸುತ್ತದೆ

ಸ್ಥಾಪಿತ Linux VPN ಬಳಸುವ ಬ್ರೌಸರ್ /dev/net/tun ತೆರೆಯುವುದಿಲ್ಲ. ಅದು ಸಾಕೆಟ್ ತೆರೆಯುತ್ತದೆ, ಮತ್ತು ಆ ಸಾಕೆಟ್‌ನ ಪ್ಯಾಕೆಟ್‌ಗಳು ಯಾವ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೊರಡುತ್ತವೆ ಎಂಬುದನ್ನು ಕರ್ನಲ್ ನಿರ್ಧರಿಸುತ್ತದೆ. ಸುರಂಗವನ್ನು ರಚಿಸಿದ ಪ್ರಕ್ರಿಯೆ, ಅದು ಸಾಗಿಸುವ ಸಂಚಾರದ ಪ್ರಕ್ರಿಯೆಗಿಂತ ಬೇರೆ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ. ಆ ಎರಡು ಪಾತ್ರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸುವುದು ಹೆಚ್ಚಿನ ಅನುಮತಿ ಪ್ರಶ್ನೆಗಳಿಗೆ ಅವು ಕೇಳುವ ಮೊದಲೇ ಉತ್ತರ ನೀಡುತ್ತದೆ.

ಸಾಕೆಟ್‌ನಿಂದ ಸುರಂಗದವರೆಗೆ ಒಂದು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅನುಸರಿಸಿ

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

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

ಎರಡು ಭಾಗಗಳನ್ನು ಒಮ್ಮೆ ಬಿಡಿಸಿ, ಆಗ ಅನುಮತಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಇಡುವುದು ಸುಲಭವಾಗುತ್ತದೆ. ಮೇಲಿನ ಭಾಗ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಜಗತ್ತು, ಕೆಳಗಿನ ಭಾಗ ಡೀಮನ್‌ಗೆ ಸೇರಿದೆ.

ಸಾಧನ ಯಾರಿಗೆ ಬೇಕು ಮತ್ತು ಯಾರಿಗೆ ಬೇಡ ಎಂದು ನಿರ್ಧರಿಸಿ

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

ಮಾರ್ಗ ಮತ್ತು ನೀತಿ ಸಿದ್ಧವಾದ ನಂತರ, ಸಾಮಾನ್ಯ ಪ್ರಕ್ರಿಯೆ ತನ್ನ ಸಾಮಾನ್ಯ ಸಾಕೆಟ್ ಕರೆಗಳ ಮೂಲಕ ಉಂಟಾದ ಮಾರ್ಗವನ್ನು ಬಳಸುತ್ತದೆ. ಅದಕ್ಕೆ ಸಾಧನ ನೋಡ್ ಬೇಕಿಲ್ಲ, root ಕೂಡ ಬೇಕಿಲ್ಲ.

ಸಾಧನ ಅನುಮತಿಗಳನ್ನು ಬದಲಿಸುವುದು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಗಮ್ಯಸ್ಥಾನ ಪ್ರವೇಶ ನೀಡುವ ದಾರಿಯಲ್ಲ. ಅದು ಸಾಧನದ ಗಡಿಯನ್ನು ಬೇರೆಡೆಗೆ ಸರಿಸುತ್ತದೆ ಅಷ್ಟೇ.

ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ಯಾವ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

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

ಅದನ್ನು ip netns list ಮತ್ತು ip -n NAME route ಮೂಲಕ ಅಥವಾ ಪ್ರಕ್ರಿಯೆಯ ನೇಮ್‌ಸ್ಪೇಸ್ ಲಿಂಕ್ ಪರಿಶೀಲಿಸಿ ತಿಳಿಯಿರಿ. ಉತ್ತರ ಸಾಮಾನ್ಯವಾಗಿ ಒಂದೇ ಆಜ್ಞೆಯಲ್ಲಿ ಕಾಣುತ್ತದೆ.

ಒಂದೇ ಹೋಸ್ಟ್‌ನ ಇಬ್ಬರು ಬಳಕೆದಾರರಿಗೆ ನೀತಿಯ ಮೂಲಕ ಬೇರೆ ಬೇರೆ ಮಾರ್ಗಗಳನ್ನು ನೀಡಬಹುದು. ಅದು ನೆಟ್‌ವರ್ಕ್ ನಿರ್ಧಾರ, ಸಾಧನ ಮಾಲೀಕತ್ವದ ಸಾಕ್ಷ್ಯವಲ್ಲ.

ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನೆಟ್‌ವರ್ಕ್ ನೀತಿಯಿಂದ ಬೇರ್ಪಡಿಸಿ

ಕೆಲವು ಸಾಧನಗಳಿಗೆ ಸಾಕೆಟ್‌ಗಿಂತ ಹೆಚ್ಚು ಬೇಕು. ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಹಿಡಿಯಲು ಕಚ್ಚಾ ಸಾಕೆಟ್ ಬೇಕು, ಮತ್ತು ಮಾರ್ಗಗಳನ್ನು ಬದಲಿಸಲು ಆಡಳಿತ ಅಧಿಕಾರ ಬೇಕು. ಇವು ಬೇರೆ ಬೇರೆ ಅನುಮತಿಗಳಿರುವ ಬೇರೆ ಬೇರೆ ಕಾರ್ಯಾಚರಣೆಗಳು, ಮತ್ತು ಒಂದನ್ನು ನೀಡುವುದನ್ನು VPN ಬಳಕೆಗೆ ಸಾಮಾನ್ಯ ಅಗತ್ಯವೆಂದು ಓದಬಾರದು.

ತನ್ನದೇ ಸುರಂಗವನ್ನು ಅಳವಡಿಸುವ ಕಾರ್ಯಕ್ರಮ ಮೂರನೇ ಪ್ರಕರಣ. ಅದು ಡೀಮನ್ ಪಾತ್ರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದರಿಂದ ನಿಜವಾಗಿಯೂ TUN ತೆರೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದಕ್ಕೆ ಡೀಮನ್‌ನ ಸವಲತ್ತುಗಳು ಬೇಕು.

ಸವಲತ್ತಿನ ಹೆಸರು ಹೇಳುವ ಮೊದಲು ಕಾರ್ಯಾಚರಣೆಯ ಹೆಸರು ಹೇಳಿ. ಎರಡನ್ನೂ ಬೇರ್ಪಡಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಕಾಣುವುದಕ್ಕಿಂತ ಸುಲಭ.

ಎರಡು ಖಾತೆಗಳೊಂದಿಗೆ ವಿಭಜನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ

ಸುರಂಗವನ್ನು ಸೇವೆಯಾಗಿ ಸಂಪರ್ಕಿಸಿ, ನಂತರ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರಾಗಿ ಚಲಾಯಿಸಿ ಮತ್ತು ಅದು ಖಾಸಗಿ ಸಂಪನ್ಮೂಲವನ್ನು ತಲುಪುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ಆ ಬಳಕೆದಾರರ ಶೆಲ್‌ನಿಂದ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ip route get ಪರಿಶೀಲಿಸಿ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಆಯ್ಕೆಯಾಯಿತು ಎಂದು ನೋಡಿ. ಮಾರ್ಗ ಸರಿಯಾಗಿದ್ದು ಸಂಪರ್ಕ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಸಮಸ್ಯೆ ನೀತಿಯಲ್ಲಿ, ಸವಲತ್ತಿನಲ್ಲ.

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