OpenVPN TUN ಮತ್ತು TAP: ನಿರ್ಧರಿಸುವ ಮೂರು ಷರತ್ತುಗಳು

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

ಪ್ರಾಯೋಗಿಕವಾಗಿ ಮೂರು ಷರತ್ತುಗಳು ಇದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. ಅವನ್ನು ಕ್ರಮವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಮೊದಲನೆಯದು ಸಾಮಾನ್ಯವಾಗಿ ಚರ್ಚೆಯನ್ನು ಮುಗಿಸುತ್ತದೆ.

ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ ನಿಜವಾಗಿ ಏನನ್ನು ಸಾಗಿಸುತ್ತದೆ

TUN ಸಾಧನವು ಲೇಯರ್-3 ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಇಂಟರ್ಫೇಸ್: ಕರ್ನಲ್ ಅದಕ್ಕೆ IP ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಸುರಂಗ ಅವನ್ನು ಪೀರ್ ವಿಳಾಸಕ್ಕೆ ಒಯ್ಯುತ್ತದೆ. TAP ಸಾಧನವು Ethernet ಫ್ರೇಮ್ಗಳನ್ನು ಸಾಗಿಸುವ ಲೇಯರ್-2 ಇಂಟರ್ಫೇಸ್, ಮತ್ತು ಬ್ರಿಜಿಂಗ್ ಸಾಧ್ಯವಾಗಿಸುವುದೇ ಇದು, ಕರ್ನಲ್ ದಾಖಲೆಗಳು ವಿವರಿಸುವಂತೆ. ಎರಡೂ ಪೇಲೋಡ್ ಅನ್ನು ಹೇಗೆ ಗೂಢಲಿಪೀಕರಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಎರಡೂ ಶಕ್ತಿಯ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ. ಆಯ್ಕೆಯು ತುದಿಗಳು ಏನನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬೇಕು ಎಂಬುದರ ಬಗ್ಗೆ, ಸಂಚಾರ ಎಷ್ಟು ಚೆನ್ನಾಗಿ ರಕ್ಷಿಸಲ್ಪಟ್ಟಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಅಲ್ಲ.

ಒಂದು ಪರಿಣಾಮ ತಕ್ಷಣ ಬರುತ್ತದೆ: ಎರಡೂ ತುದಿಗಳು ಒಪ್ಪಬೇಕು. ಒಂದು ಸಾಧನ ಪ್ರಕಾರಕ್ಕೆ ಸಂರಚಿಸಲಾದ ಕ್ಲೈಂಟ್ ಇನ್ನೊಂದಕ್ಕೆ ಸಂರಚಿಸಲಾದ ಸರ್ವರ್ಗೆ ಸೇರಲು ಸಾಧ್ಯವಿಲ್ಲ, ಉಳಿದದ್ದು ಎಷ್ಟೇ ಹೊಂದಿಕೆಯಾದರೂ.

ಮೊದಲ ಷರತ್ತು: ಯಾವುದಕ್ಕಾದರೂ ಲೇಯರ್ ಎರಡು ಬೇಕೇ?

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

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

ಎರಡನೇ ಷರತ್ತು: ಕ್ಲೈಂಟ್ಗಳು ಇದನ್ನು ಮಾಡಬಲ್ಲವೇ?

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

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

ಮೂರನೇ ಷರತ್ತು: ಇದು ನಿಜವಾಗಿಯೂ ಇಂಟರ್ಫೇಸ್ ಪ್ರಶ್ನೆಯೇ?

ಇಂಟರ್ಫೇಸ್ ಸಮಸ್ಯೆಗಳಿಗೆ ಪಕ್ಕದ ಎರಡು ಆಯ್ಕೆಗಳನ್ನು ದೂಷಿಸಲಾಗುತ್ತದೆ. ವರ್ಚುವಲ್ ಸಾಧನ ಸುರಂಗಕ್ಕೆ ಏನು ಪ್ರವೇಶಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದರೆ UDP ಅಥವಾ TCP ಹೊರಗಿನ ಸಾಗಣೆ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡೂ ನಿಲ್ಲುವ ವರ್ಗಾವಣೆಗಳನ್ನು ಗುಣಪಡಿಸುವುದಿಲ್ಲ. ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳು ನೇತಾಡುತ್ತಿರುವಾಗ ಸಣ್ಣವು ಯಶಸ್ವಿಯಾದರೆ, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರ ಮತ್ತು MTU ಗೆ ಗಮನ ಕೊಡಬೇಕು.

ಸಂಪರ್ಕಿಸಿ ನಂತರ ಒಂದು ಆಂತರಿಕ ಹೋಸ್ಟ್ ತಲುಪಲಾಗದ ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ ರೂಟಿಂಗ್, ಫೈರವಾಲ್ ನಿಯಮ ಅಥವಾ ಕಾಣೆಯಾದ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ನೋಡುತ್ತಿರುತ್ತದೆ.

ನಿರ್ವಹಿತ ಸೇವೆಗಾಗಿ ನಿರ್ವಾಹಕರ ಪ್ರೊಫೈಲ್ ಸೂಚಿಸುವ ಇಂಟರ್ಫೇಸ್ ಜೋಡಣೆಯನ್ನು ಬಳಸಿ, ಏಕೆಂದರೆ ಸರ್ವರ್ ಭಾಗ ಈಗಾಗಲೇ ಅದರ ಸುತ್ತ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಖಾಸಗಿ ನಿಯೋಜನೆಗಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾದ ಅಗತ್ಯದಿಂದ ಆರಿಸಿ ಮತ್ತು ಆಯ್ಕೆಯ ಪಕ್ಕದಲ್ಲಿ ಕಾರಣ ಬರೆಯಿರಿ.

ಪ್ರಶ್ನೆ ಯಾವ ಆಯ್ಕೆ ಬಲಶಾಲಿ ಎಂಬುದಲ್ಲ. ಸಂಚಾರಕ್ಕೆ ನಿಜವಾಗಿ ಯಾವುದು ಬೇಕು ಎಂಬುದು.