ಒಂದೇ ಹೋಸ್ಟ್ನಿಂದ TCP ಮತ್ತು UDP ಮೇಲೆ OpenVPN ಸೇವೆ ನೀಡುವುದು
2.7 ಗಿಂತ ಮೊದಲು ಒಂದು ಪ್ರಕ್ರಿಯೆ ಒಂದೇ ಸಾಗಣೆಯನ್ನು ಬಂಧಿಸುತ್ತದೆ. ಸೇತುವೆಯಾದ TAP ಜೋಡಿ, ಎರಡು TUN ಉಪಜಾಲಗಳು ಮತ್ತು ಹಂಚಿದ ಪೂಲ್ ಅನ್ನು ಹೋಲಿಸಿ, ನಂತರ ಪ್ರತಿ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಅದರ ಆಲಿಸುವಿಕೆಗೆ ಹೊಂದಿಸಿ.
TCP 443 ಗೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡುವ ಜಾಲಗಳು UDP ಅನ್ನು ಸುಲಭವಾಗಿ ಹಾದುಹೋಗಲು ಬಿಡುವ ಜಾಲಗಳೊಂದಿಗೆ ಸಹಬಾಳ್ವೆ ನಡೆಸುತ್ತವೆ, ಮತ್ತು ಒಂದು ಸರ್ವರ್ ಎರಡಕ್ಕೂ ಸೇವೆ ನೀಡಬೇಕು. proto udp ಹೊಂದಿರುವ ಪ್ರೊಫೈಲ್ ಎರಡನೇ ಗುಂಪಿಗೆ ಉತ್ತರಿಸಿ ಮೊದಲನೆಯದರಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು proto tcp ಎಂದು ಹೇಳಲು ಅದೇ ಸಂರಚನೆಯನ್ನು ಸಂಪಾದಿಸಿದರೆ ಎರಡನೇ ಆಲಿಸುವಿಕೆ ಸೃಷ್ಟಿಯಾಗುವುದಿಲ್ಲ. ಈ ನಿರ್ದೇಶನವು ಒಂದು ಪ್ರಕ್ರಿಯೆಗೆ ಒಂದೇ ಸಾಗಣೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಉಳಿದೆಲ್ಲವೂ ಆ ನಿರ್ಬಂಧದಿಂದ ಬರುತ್ತದೆ.
ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಡೆಸಿ, ಅಥವಾ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಹಲವು ಸಾಕೆಟ್ಗಳನ್ನು ಬಂಧಿಸಬಲ್ಲ ಆವೃತ್ತಿಯನ್ನು ನಡೆಸಿ.
2.7 ಗಿಂತ ಮೊದಲು ಒಂದು ಪ್ರಕ್ರಿಯೆ ಒಂದೇ ಸಾಗಣೆಯನ್ನು ಬಂಧಿಸುತ್ತದೆ
ಸಮುದಾಯದ OpenVPN proto ವಿವರಿಸುವ ಸಾಕೆಟ್ ಅನ್ನು ಬಂಧಿಸುತ್ತದೆ, ಮತ್ತು ಆ ನಿರ್ದೇಶನವು ನಿದರ್ಶನಕ್ಕೆ ಒಂದೇ ಸಾಗಣೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. TCP ಮತ್ತು UDP ಪ್ರತ್ಯೇಕ ಸ್ಟ್ಯಾಕ್ಗಳು, ಆದ್ದರಿಂದ ಅದೇ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯನ್ನು ಎರಡೂ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಆಕ್ರಮಿಸಬಹುದು, ಆದರೆ ಒಂದು ಪ್ರಕ್ರಿಯೆ ಆಕ್ರಮಿಸಲಾರದು. ಆದ್ದರಿಂದ 2.6 ಸಾಲು ನಿಮಗೆ ಪ್ರತಿ ಡೀಮನ್ಗೆ ಒಂದು ಸಾಗಣೆಯನ್ನು ನೀಡುತ್ತದೆ. OpenVPN 2.7 ಸರ್ವರ್ಗಳಿಗೆ ಆ ಮಿತಿಯನ್ನು ತೆಗೆದುಹಾಕಿತು, ಅವು ಒಂದೇ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಹಲವು --local ಹೇಳಿಕೆಗಳ ಮೂಲಕ ಹಲವು ಸಾಕೆಟ್ಗಳನ್ನು ಬಂಧಿಸಬಹುದು.
ಯಾವುದೇ ಉತ್ತರದ ಸುತ್ತ ವಿನ್ಯಾಸ ಮಾಡುವ ಮೊದಲು ಆವೃತ್ತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ 2.7 ವ್ಯವಸ್ಥೆ ತನ್ನದೇ ಸಂರಚನಾ ವಾಕ್ಯರಚನೆಯನ್ನು ಹೊಂದಿರುವ ಬೇರೆ ಕಾರ್ಯಾಚರಣಾ ಮಾದರಿ. 2.6 ಗಾಗಿ ಬರೆದ ಮಾರ್ಗದರ್ಶಿ ಹಾಗೆ ಹೇಳದಿದ್ದರೂ ಎರಡು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಎರಡು ನಿದರ್ಶನಗಳನ್ನು ನಡೆಸುವ ಮೂರು ದಾರಿಗಳು
TAP ಇಂಟರ್ಫೇಸ್ಗಳೊಂದಿಗೆ, ಪ್ರತಿ ಸಾಗಣೆಗೆ ಒಂದು ನಿದರ್ಶನವನ್ನು ನಡೆಸಿ ಹೋಸ್ಟ್ನಲ್ಲಿ ಎರಡು tap ಸಾಧನಗಳನ್ನು ಸೇತುವೆ ಮಾಡಿ. ಎರಡೂ ಕ್ಲೈಂಟ್ ಗುಂಪುಗಳು ಒಂದೇ ಪ್ರಸಾರ ಕ್ಷೇತ್ರಕ್ಕೆ ಬರುತ್ತವೆ, ಇದು ಒಂದು ವಿಳಾಸ ಪೂಲ್ ಅವನ್ನು ಆವರಿಸಲು ಅನುವು ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ರಸಾರವನ್ನು ಅವಲಂಬಿಸುವ ಪ್ರೋಟೋಕಾಲ್ಗಳು ಕೆಲಸ ಮಾಡುತ್ತಿರುತ್ತವೆ. TUN ನೊಂದಿಗೆ ಸೇತುವೆ ಲಭ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಸರಳವಾದ ವಿಭಜನೆ ಪ್ರತಿ ನಿದರ್ಶನಕ್ಕೆ ತನ್ನದೇ ಉಪಜಾಲವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಮಾರ್ಗನಿರ್ದೇಶನ ಎರಡೂ ಕ್ಲೈಂಟ್ ಗುಂಪುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುತ್ತದೆ. ಮೂರನೇ ಆಯ್ಕೆ ಒಂದೇ ಪೂಲ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ: ಪ್ರತಿ ನಿದರ್ಶನವೂ learn-address ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಕರೆಯುತ್ತದೆ, ಅದು ಆ ನಿದರ್ಶನದ ಸಾಧನದ ಮೂಲಕ ಕ್ಲೈಂಟ್ಗೆ /32 ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ.
ಆ ಮೂರನೇ ವ್ಯವಸ್ಥೆಯೇ ಜನರು ಕೇಳುವ ಮತ್ತು ಹೆಚ್ಚು ಎಚ್ಚರಿಕೆ ಬೇಕಾಗುವ ವ್ಯವಸ್ಥೆ, ಏಕೆಂದರೆ ಸ್ಕ್ರಿಪ್ಟ್ ಡೇಟಾ ಮಾರ್ಗದ ಭಾಗವಾಗುತ್ತದೆ ಮತ್ತು ಸೇರಿಸು, ನವೀಕರಿಸು ಹಾಗೂ ಅಳಿಸು ಘಟನೆಗಳನ್ನು ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸಬೇಕು.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
ಎರಡು ನಿದರ್ಶನಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ
ಪ್ರತಿ ನಿದರ್ಶನಕ್ಕೂ ಪ್ರತ್ಯೇಕ ಪೋರ್ಟ್ ಅಥವಾ ವಿಳಾಸ, ಪ್ರತ್ಯೇಕ ಸ್ಥಿತಿ ಕಡತ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಲಾಗ್ ಗಮ್ಯಸ್ಥಾನ ಬೇಕು. ಒಂದೇ ಸ್ಥಿತಿ ಕಡತಕ್ಕೆ ಸೇರಿಸುವ ಎರಡು ಡೀಮನ್ಗಳು ಘಟನೆಯ ಸಮಯದಲ್ಲಿ ಓದಲಾಗದ ಔಟ್ಪುಟ್ ಉತ್ಪಾದಿಸುತ್ತವೆ, ಮತ್ತು ಅದೇ ಕ್ಷಣ ನಿಮಗೆ ಅದು ಬೇಕಾಗುತ್ತದೆ. ಎರಡನೇ ನಿದರ್ಶನವು ನಿರ್ದಿಷ್ಟ ವಿಳಾಸವನ್ನು ಬಂಧಿಸಿದರೆ, ಪ್ರಕ್ರಿಯೆ ಆರಂಭವಾಗುವಾಗ ಆ ವಿಳಾಸ ಹೋಸ್ಟ್ನಲ್ಲಿ ಇರಬೇಕು; ಇಲ್ಲದಿದ್ದರೆ ಕೀಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವ ಮೊದಲೇ ಅದು ಬಂಧನ ವೈಫಲ್ಯದೊಂದಿಗೆ ನಿರ್ಗಮಿಸುತ್ತದೆ.
ಘಟಕಗಳಿಗೂ ಪ್ರೊಫೈಲ್ಗಳಿಗೂ ಕಡತದ ಹೆಸರಿನಿಂದಲೇ ಸಾಗಣೆ ಸ್ಪಷ್ಟವಾಗುವಂತೆ ಹೆಸರಿಡಿ. ಮುಂದಿನ ನಿರ್ವಾಹಕರು ಯಾವುದು TCP ಎಂದು ತಿಳಿಯಲು ಸಂರಚನೆಯನ್ನು ತೆರೆಯಬೇಕಾಗಬಾರದು.
ಪ್ರೊಫೈಲ್ ಅನ್ನು ಆಲಿಸುವಿಕೆಗೆ ಹೊಂದಿಸಿ
proto tcp ನಡೆಸುವ ಸರ್ವರ್ proto tcp-client ಇರುವ ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ ನಿರೀಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಇನ್ನೂ proto udp ಹೊಂದಿರುವ ಪ್ರೊಫೈಲ್ ಆ ಆಲಿಸುವಿಕೆಯ ಎದುರು ಬಳಕೆದಾರರು ಕ್ರಮ ಕೈಗೊಳ್ಳಬಹುದಾದ ದೋಷವಿಲ್ಲದೆ ಸಮಯ ಮೀರಿ ನಿಲ್ಲುತ್ತದೆ. ನಿಯೋಜನೆ ಎರಡೂ ಸಾಗಣೆಗಳನ್ನು ನೀಡಿದರೆ ಎರಡು ಪ್ರೊಫೈಲ್ಗಳನ್ನು ಇರಿಸಿ, ಮತ್ತು ಯಾವುದನ್ನು ಪ್ರಯತ್ನಿಸಲಾಯಿತು ಎಂದು ಬೆಂಬಲ ತಿಳಿಯುವಂತೆ ಲೇಬಲ್ ಮಾಡಿ. ಪೋರ್ಟ್ ಸಂಖ್ಯೆ ಮಾತ್ರ ಸಾಗಣೆಯನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ.
ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು ಅದೇ ವಿಭಜನೆಯನ್ನು ಅನುಸರಿಸುತ್ತವೆ: UDP 1194 ನಿಯಮ TCP 1194 ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಒಂದು ವಿಳಾಸದ ನಿಯಮ ಇನ್ನೊಂದು ಆಲಿಸುವಿಕೆಯನ್ನು ಆವರಿಸುವುದಿಲ್ಲ.
ಮೊದಲು ಸರ್ವರ್ನ ದೃಶ್ಯವನ್ನು ಓದಿ
ಸರ್ವರ್ನಲ್ಲಿ ss -lntup ನಿಂದ ಪ್ರಾರಂಭಿಸಿ TCP ಮತ್ತು UDP ಆಲಿಸುವಿಕೆ ಎರಡೂ ಕಾಣಿಸುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ನಂತರ ಪ್ರತಿ ಬಗೆಯ ಒಂದು ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ವಿಭಿನ್ನ ವಿಳಾಸಗಳಿರುವ ಎರಡು ನಮೂದುಗಳಿಗಾಗಿ ಸ್ಥಿತಿ ಔಟ್ಪುಟ್ ಪರಿಶೀಲಿಸಿ. ಸಾಕೆಟ್ಗಳು ಇದ್ದು ಕ್ಲೈಂಟ್ ಬಾರದಿದ್ದರೆ, ಡೀಮನ್ ಅವನ್ನು ನೋಡುವ ಮೊದಲೇ ಮಾರ್ಗ ಅಥವಾ ಫೈರ್ವಾಲ್ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ತಿರಸ್ಕರಿಸುತ್ತಿವೆ.
ಎಂದೂ ಕಾಣದ ಸಾಕೆಟ್ ಸಂರಚನೆ ಅಥವಾ ಬಂಧನದ ಸಮಸ್ಯೆ, ಮತ್ತು ಕಾಣಿಸಿ ಆದರೆ ಎಂದೂ ಸಂಪರ್ಕ ದಾಖಲಿಸದ ಸಾಕೆಟ್ ಶೋಧನೆಯ ಸಮಸ್ಯೆ. ಕ್ಲೈಂಟ್ನಿಂದ ಎರಡೂ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಆದ್ದರಿಂದ ಸರ್ವರ್ನ ಸ್ವಂತ ದೃಶ್ಯ ಮೊದಲು ಬರುತ್ತದೆ. TCP ಮುಂಚೂಣಿ ತಡೆಯನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ, ಆದ್ದರಿಂದ ಅದನ್ನು ನೀಡುವುದು ಸ್ವಚ್ಛ UDP ಮಾರ್ಗವಿರುವ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ನವೀಕರಣವಲ್ಲ, ತಲುಪುವಿಕೆಯ ಕ್ರಮ.