proto udp ಅಥವಾ tcp-client: ನಿಮ್ಮ ಸರ್ವರ್ ಯಾವುದನ್ನು ಕೇಳುತ್ತದೆ?

ಕಳೆದ ತಿಂಗಳು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಪ್ರೊಫೈಲ್ ಈಗ ಸಮಯ ಮೀರಿಕೆಗೆ ಬರುತ್ತಿದೆ, ಮತ್ತು ಯಾರೋ proto udp ಅನ್ನು proto tcp-client ನಿಂದ ಬದಲಾಯಿಸಲು ಸೂಚಿಸುತ್ತಾರೆ. ಕೆಲವೊಮ್ಮೆ ಅದು ಸರಿಯಾದ ಹೆಜ್ಜೆ, ಕೆಲವೊಮ್ಮೆ ಯಾವುದೂ ಕೇಳದ ಪೋರ್ಟ್ಗೆ ಸಂಪರ್ಕಿಸುವ ಕ್ಲೈಂಟ್ ಉಂಟಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಸರ್ವರ್ ಎಂದೂ ಇನ್ನೊಂದು ಸಾಗಣೆಗೆ ಸಂರಚಿಸಲ್ಪಟ್ಟಿಲ್ಲ. ಈ ನಿರ್ದೇಶನವು ನಿಮ್ಮ ಬದಿ ಹೇಗೆ ಮಾತನಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ; ಅದು ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಶ್ರೋತೃವನ್ನು ಸೃಷ್ಟಿಸಲಾರದು. ಎರಡನ್ನೂ ಬದಲಾಯಿಸುವ ಮೊದಲು ಪ್ರೊಫೈಲ್ ಮತ್ತು ಸರ್ವರ್ ಅನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ.

ಆಯ್ಕೆಮಾಡಿದ ಸಂಪರ್ಕವು ಬಳಸುವ ಸಾಗಣೆಯನ್ನು ಓದಿ

ಪ್ರೊಫೈಲ್ ಹಲವು remote ನಮೂದುಗಳನ್ನು ಹೊಂದಿರಬಹುದು, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಸಾಗಣೆಯನ್ನು ಹೆಸರಿಸಬಹುದು. ಕ್ಲೈಂಟ್ ಅವುಗಳನ್ನು ಕ್ರಮದಲ್ಲಿ ಸಾಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಮೊದಲು ಕಾಣುವ ಸಾಲು ಅನ್ವಯವಾಗುವ ಸಾಲೇ ಆಗಿರಬೇಕೆಂದಿಲ್ಲ.

ನಿಜವಾಗಿ ಪ್ರಯತ್ನಿಸಲ್ಪಡುತ್ತಿರುವ ನಮೂದನ್ನು ಹುಡುಕಿ, ನಂತರ ಅದರ ಸಾಗಣೆಯನ್ನು ಓದಿ. ಕ್ರಮ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಮೌನವಾಗಿ ಮುಂದೆ ಹೋಗುವುದಿಲ್ಲ. ಕೆಲವು ಬಿಲ್ಡ್ಗಳು ಮುಂದಿನ ನಮೂದನ್ನು ಸಮಯ ಮೀರಿದ ನಂತರವೇ ಪ್ರಯತ್ನಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಕಡತದ ಕೆಳಭಾಗದಲ್ಲಿರುವ ಕೆಲಸ ಮಾಡುವ ಪರ್ಯಾಯವು ನೀವು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಂತರ ತಲುಪುತ್ತದೆ. ಮೊದಲ ಸಾಲು ಗೆದ್ದಿತು ಎಂದು ಊಹಿಸುವ ಬದಲು ಲಾಗ್ನಲ್ಲಿ ಪ್ರಯತ್ನಿಸಲ್ಪಡುತ್ತಿರುವ ಅಂತ್ಯಬಿಂದುವನ್ನು ಗಮನಿಸಿ.

ಕಡತದಲ್ಲಿ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಒಂದು proto ಸಾಲು ಮತ್ತು ಕೆಳಗೆ ಹಲವು remote ನಮೂದುಗಳಿದ್ದರೆ, ಆ ಸಾಲು ಅದನ್ನು ಮೀರಿಸದ ಯಾವುದೇ remote ಗೆ ಡೀಫಾಲ್ಟ್ ಆಗಿದೆ. ಡೀಫಾಲ್ಟ್ಗೆ ಸ್ಥಳೀಯ ಬದಲಾವಣೆಯು ತನ್ನದೇ ಸಾಗಣೆಯನ್ನು ಹೆಸರಿಸುವ remote ನಮೂದಿಗೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.

grep -nE '^(remote|proto)\b' client.ovpn

UDP ಮತ್ತು TCP ವೇಗದ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ

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

ಇದು ತಲುಪುವಿಕೆಯ ವಿನಿಮಯ, ಸಾರ್ವತ್ರಿಕ ಶ್ರೇಣಿ ಅಲ್ಲ. ಸರಿಯಾದ ಆಯ್ಕೆ ಎಂದರೆ ಕ್ಲೈಂಟ್ನ ಮುಂದಿನ ಜಾಲವು ಅನುಮತಿಸುವುದು. VPN ಪೋರ್ಟ್ನಲ್ಲಿ UDP ಅನ್ನು ಬೀಳಿಸುವ ಮಾರ್ಗವು ಎಂದಿಗೂ ಮಾತುಕತೆ ನಡೆಸುವುದಿಲ್ಲ, ಪ್ರೊಫೈಲ್ ಎಷ್ಟೇ ಚೆನ್ನಾಗಿ ಬರೆಯಲ್ಪಟ್ಟಿದ್ದರೂ. ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಸಾಗಣೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿ.

ಅವುಗಳ ನಡುವೆ ಕೇವಲ ಮಾಪನದ ಆಧಾರದಲ್ಲಿ ಆಯ್ಕೆ ಮಾಡುವುದು ತಪ್ಪು, ಏಕೆಂದರೆ ಉತ್ತರವು ನಿಮ್ಮ ಮುಂದಿನ ಜಾಲ ಏನನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ. ಹೋಟೆಲ್ ಅಥವಾ ಕಾರ್ಪೊರೇಟ್ ಪ್ರಾಕ್ಸಿ 443 ನಲ್ಲಿ ಹೊರಹೋಗುವ TCP ಮಾತ್ರ ಅನುಮತಿಸಬಹುದು, ಆದ್ದರಿಂದ ಪೂರೈಕೆದಾರರು ಆ ರೂಪಾಂತರವನ್ನು ನೀಡುತ್ತಾರೆ. ಪೋರ್ಟ್ ಸಂಖ್ಯೆ ಪರಿಚಿತವಾಗಿದ್ದರೂ ಅದು ಆ ಪೋರ್ಟ್ನಲ್ಲಿ OpenVPN ಸಂಪರ್ಕವೇ, HTTPS ಅಧಿವೇಶನವಲ್ಲ.

tcp-client ನಿಜವಾಗಿ ಏನನ್ನು ಅರ್ಥೈಸುತ್ತದೆ

ಕ್ಲೈಂಟ್ ಬದಿಯ ನಿರ್ದೇಶನವು TCP ಸಂಪರ್ಕವನ್ನು ಪ್ರಾರಂಭಿಸುವ ತುದಿಯನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಸರ್ವರ್ ಬದಿಯು ತನ್ನದೇ ಆಲಿಸುವ ರೂಪವನ್ನು ಬಳಸುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ನ ಪದವನ್ನು ಸರ್ವರ್ ಸಂರಚನೆಗೆ ನಕಲಿಸುವುದು ಕರೆ ಮಾಡಲ್ಪಡುವುದನ್ನು ನಿರೀಕ್ಷಿಸುವ ಶ್ರೋತೃವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಸ್ವೀಕರಿಸುವಂತಹದ್ದಲ್ಲ.

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

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

ಪ್ರೊಫೈಲ್ ತಪ್ಪು ಎಂದು ಊಹಿಸುವ ಮೊದಲು ಸರ್ವರ್ ಏನನ್ನು ಆಲಿಸುತ್ತಿದೆ ಎಂದು ಕೇಳಿ. UDP ಶ್ರೋತೃ TCP ಸಾಕೆಟ್ ಪಟ್ಟಿಯಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ, ಮತ್ತು ವ್ಯತ್ಯಯವೂ ನಿಜ, ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯ ದೃಶ್ಯದ ಬದಲು ಪ್ರೋಟೋಕಾಲ್-ನಿರ್ದಿಷ್ಟ ದೃಶ್ಯವನ್ನು ನೋಡಿ.

ಪ್ರೊಫೈಲ್ ಆಮದಾದರೂ ಎಂದೂ ಸಂಪರ್ಕಿಸದಿದ್ದಾಗ

ತಕ್ಷಣ ಸಮಯ ಮೀರುವ ಆಮದಾದ ಪ್ರೊಫೈಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದೇ ದೃಢೀಕರಣಕ್ಕೂ ಮೊದಲು ವಿಫಲವಾಗುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ಶ್ರೋತೃವಿಲ್ಲದ ಪೋರ್ಟ್ಗೆ ಹೋಗುತ್ತದೆ, ಅಥವಾ ಜಾಲವು ಅದನ್ನು ಮೌನವಾಗಿ ಬೀಳಿಸುತ್ತದೆ.

ಮಾರ್ಗವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳವಾಗಿ ಪರೀಕ್ಷಿಸಿ: ವಿಫಲವಾಗುತ್ತಿರುವ ಕ್ಲೈಂಟ್ನಂತೆಯೇ ಅದೇ ಜಾಲದಿಂದ, ಪ್ರೊಫೈಲ್ ಹೇಳಿಕೊಳ್ಳುವ ಸಾಗಣೆಯೊಂದಿಗೆ ಅದೇ ಹೋಸ್ಟ್ ಮತ್ತು ಪೋರ್ಟ್ಗೆ ಸಂಪರ್ಕಿಸಿ.

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

ಕೆಲಸ ಮಾಡುವ ಸಾಗಣೆಯನ್ನು ದಾಖಲಿಸಿ

ಸಂಯೋಜನೆ ಕೆಲಸ ಮಾಡಿದಾಗ, ಅದನ್ನು ಸರ್ವರ್, ಪೋರ್ಟ್ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ನೊಂದಿಗೆ ಬರೆಯಿರಿ, ಮತ್ತು ಯಾವ ಜಾಲದಿಂದ ಪರೀಕ್ಷಿಸಲಾಯಿತು ಎಂದು ಗುರುತಿಸಿ.

ಇಲ್ಲದಿದ್ದರೆ, ಸಮಯ ಮೀರಿಕೆ ಎದುರಿಸುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅದೇ ಪ್ರಯೋಗವನ್ನು ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ಪುನರಾವರ್ತಿಸುತ್ತಾರೆ, ಮತ್ತು ಬಹುಶಃ ಸರಿಯಾಗಿದ್ದ ಸರ್ವರ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತಾರೆ.

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