OpenVPN ಪ್ರೊಫೈಲ್ನ ಸರ್ವರ್ ಅನ್ನು ಆಮದು ಮಾಡುವ ಮೊದಲು ಪರಿಶೀಲಿಸುವುದು ಹೇಗೆ

ಯಾರೋ ನಿಮಗೆ ಪ್ರೊಫೈಲ್ ಕಳುಹಿಸುತ್ತಾರೆ, ನೀವು ಅದನ್ನು ಆಮದು ಮಾಡುತ್ತೀರಿ, ಮತ್ತು ಮೂವತ್ತು ಸೆಕೆಂಡುಗಳ ನಂತರ ಯಾರೂ ಪರಿಶೀಲಿಸದ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಕ್ಲೈಂಟ್ ಡಯಲ್ ಮಾಡುತ್ತಿದೆ. ಮೊದಲು ಫೈಲ್ ಅನ್ನು ಪಠ್ಯ ಸಂಪಾದಕದಲ್ಲಿ ಓದಿ, ಏಕೆಂದರೆ ಮುಖ್ಯವಾದ ಎಲ್ಲವೂ ಕೆಲವು ಸೂಚನೆಗಳಲ್ಲಿ ಅಡಕವಾಗಿದೆ: remote, proto, port, ca, cert, tls-crypt ಮತ್ತು verify-x509-name. ಉಳಿದದ್ದೆಲ್ಲಾ ಡಿಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳು, ಮತ್ತು ಅಚ್ಚರಿಗಳು ಅಲ್ಲೇ ಇರುತ್ತವೆ.

ಫೈಲ್ ಬಳಸಬಹುದಾದ ಪ್ರತಿ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಪಟ್ಟಿ ಮಾಡಿ

ಎಂಡ್ಪಾಯಿಂಟ್ಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಒಂದು ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಹಲವು ಇರಬಹುದು. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn ಪ್ರತಿ ಅಭ್ಯರ್ಥಿಯನ್ನು ಫೈಲ್ ಕ್ರಮದಲ್ಲಿ ಮುದ್ರಿಸುತ್ತದೆ, ಇನ್ಲೈನ್ <connection> ಬ್ಲಾಕ್ಗಳೊಳಗೆ ಗೂಡಿಸಿದವುಗಳೂ ಸೇರಿದಂತೆ.

ಸೂಚನೆಯು ಪೋರ್ಟ್ ಬಿಟ್ಟುಬಿಟ್ಟಾಗ, ಕ್ಲೈಂಟ್ ಕೇಳುಗರ ಡಿಫಾಲ್ಟ್ಗೆ ಮರಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೇವಲ remote vpn.example.com ಎಂದರೆ ಪೋರ್ಟ್ 1194, ಫೈಲ್ನಲ್ಲಿ ನಂತರ ಯಾವ proto ಬಂದರೂ. ಹಲವು ಸಾಮಾನ್ಯ remote ಸಾಲುಗಳು ಪರ್ಯಾಯಗಳು: ಕ್ಲೈಂಟ್ ಅವುಗಳನ್ನು ಕ್ರಮದಲ್ಲಿ ಪ್ರಯತ್ನಿಸುತ್ತದೆ, remote-random ಅವುಗಳನ್ನು ಬೆರೆಸದಿದ್ದರೆ, ಮತ್ತು ಅದು ಎಂದಿಗೂ ಮತ್ತೊಬ್ಬ ಆಪರೇಟರ್ನ ಹೋಸ್ಟ್ ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬದಲಿಸುವುದಿಲ್ಲ. ಸಂಬಂಧವಿಲ್ಲದ ಡೊಮೇನ್ಗಳಲ್ಲಿ ಎರಡು remote ಸಾಲುಗಳು ನೀವು ನಿಂತು ಯಾವುದು ಉದ್ದೇಶಿಸಲಾಗಿತ್ತು ಎಂದು ಕೇಳುವ ಸ್ಥಳ.

proto ನ ಕಾಗುಣಿತವನ್ನೂ ಗಮನಿಸಿ. tcp ಕ್ಲೈಂಟ್-ಬದಿಯ tcp-client ನ ಸಮಾನಾರ್ಥಕವಾಗಿ ಸ್ವೀಕರಿಸಲ್ಪಡುತ್ತದೆ, ಆದರೆ ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ tcp-server ಸ್ವಚ್ಛವಾಗಿ ವಿಫಲವಾಗುವ ಬದಲು ನೇತಾಡುವ ಪ್ರವೃತ್ತಿ ಇರುವ ಸಂರಚನಾ ದೋಷ.

ಮೊದಲು ಹೆಸರು, ನಂತರ ಪೋರ್ಟ್ ದೃಢೀಕರಿಸಿ

dig +short vpn.example.com ಹೆಸರು ಇದೆಯೇ ಮತ್ತು ಯಾವ ವಿಳಾಸಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಬಹು-ವಿಳಾಸ ಅಥವಾ ಪ್ರಾಕ್ಸಿ ಹಿಂದಿನ ಎಂಡ್ಪಾಯಿಂಟ್ ಕಾನೂನುಬದ್ಧವಾಗಿ ಹಲವನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು. ಹೆಸರಿನ ವಿಭಜನೆ ಪೂರ್ವಭಾವಿ ಷರತ್ತು, ಮಾಲೀಕತ್ವದ ಸಾಕ್ಷ್ಯವಲ್ಲ; ಯಾರಾದರೂ ಹೆಸರನ್ನು ವಿಳಾಸಕ್ಕೆ ತೋರಿಸಬಹುದು, ಮತ್ತು ಒಂದು ವಿಳಾಸ ಅನೇಕ ಹೆಸರುಗಳಿಗೆ ಉತ್ತರಿಸಬಹುದು.

ನಂತರ ನೀವು ಕಂಡುಕೊಂಡ ಪೋರ್ಟ್ನಲ್ಲಿ ಕೇಳುಗರನ್ನು ಪರಿಶೀಲಿಸಿ, ಸಾರಿಗೆಗೆ ಹೊಂದಿಸಿ. TCP ಮೇಲೆ openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com ಸರ್ವರ್ ಪ್ರಸ್ತುತಪಡಿಸುವ ಸರಪಳಿಯನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. UDP ಮೇಲೆ ನಿಮಗೆ DTLS ಬೇಕು: openssl s_client -dtls1_2 -connect vpn.example.com:1194 ಡೇಟಾಗ್ರಾಮ್ಗಳ ಮೇಲೆ ಅದೇ ಹ್ಯಾಂಡ್ಶೇಕ್ ನಡೆಸುತ್ತದೆ. ಪೂರ್ಣಗೊಂಡ ಹ್ಯಾಂಡ್ಶೇಕ್ ಏನೋ ಕೇಳುತ್ತಿದೆ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಹೊಂದಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಇದು ping ತೋರಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮತ್ತು ಪ್ರೊಫೈಲ್ನ ಸ್ವಂತ ನಂಬಿಕೆ ಸೆಟ್ಟಿಂಗ್ಗಳು ಬೇಡುವುದಕ್ಕಿಂತ ಕಡಿಮೆ.

ಹ್ಯಾಂಡ್ಶೇಕ್ ವಿಫಲವಾಗಿ ಹೋಸ್ಟ್ ping ಗೆ ಉತ್ತರಿಸಿದಾಗ, ಪೋರ್ಟ್ ಬಹುಶಃ ತಪ್ಪಾಗಿದೆ ಅಥವಾ ಫಿಲ್ಟರ್ ಆಗಿದೆ. ಅದನ್ನು ಸರಿಯಾದ ಪೋರ್ಟ್ ಕೇಳುವ ಕಾರಣವೆಂದು ಪರಿಗಣಿಸಿ, ಹತ್ತಿರದ ಪೋರ್ಟ್ಗಳನ್ನು ಗುಡಿಸುವ ಆಹ್ವಾನವಲ್ಲ. nc -vzu ಕೂಡ ಕೆಲವು ಸ್ಟ್ಯಾಕ್ಗಳಲ್ಲಿ ಏನೂ ಕೇಳದಿದ್ದರೂ ಯಶಸ್ಸನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಹಿಂದೆ ಹ್ಯಾಂಡ್ಶೇಕ್ ಇಲ್ಲದ ಬರೀ UDP ಪ್ರಯೋಗ ಏನನ್ನೂ ಅರ್ಥೈಸುವುದಿಲ್ಲ.

ನಂಬಿಕೆ ಪಿನ್ಗಳನ್ನು ವಿಳಾಸದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಓದಿ

ವಿಳಾಸ ಕ್ಲೈಂಟ್ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ; ನಂಬಿಕೆ ಬ್ಲಾಕ್ ತಲುಪಿದ ನಂತರ ಯಾರನ್ನು ನಂಬುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ. verify-x509-name "vpn.example.com" name ವಿಷಯದ ಸಾಮಾನ್ಯ ಹೆಸರನ್ನು ಪಿನ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು remote-cert-tls server ಸರ್ವರ್ ದೃಢೀಕರಣಕ್ಕಾಗಿ ವಿಸ್ತೃತ ಕೀಲಿ ಬಳಕೆಯನ್ನು ಕಡ್ಡಾಯ ಮಾಡುತ್ತದೆ. ಆಪರೇಟರ್ ಕೊಟ್ಟ ಪ್ರೊಫೈಲ್ ಎರಡನ್ನೂ ಹೊಂದಿರಬೇಕು.

ca, ಇನ್ಲೈನ್ <ca> ಬ್ಲಾಕ್, ಮತ್ತು tls-crypt ಅಥವಾ tls-auth ಹುಡುಕಿ. tls-auth ಬಳಸುವ ಪ್ರೊಫೈಲ್ಗೆ ಕ್ಲೈಂಟ್ನಲ್ಲಿ key-direction 1 ಬೇಕು, ಸರ್ವರ್ ಬದಿ ದಿಕ್ಕು 0 ಬಳಸಿದಾಗ, ಮತ್ತು ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ ಹ್ಯಾಂಡ್ಶೇಕ್ ಪ್ರಮಾಣಪತ್ರದ ದೋಷದಂತೆ ಓದುವ TLS ದೋಷದಿಂದ ವಿಫಲವಾಗುತ್ತದೆ. ನೀವು ಈಗಷ್ಟೇ ಹೆಸರು ವಿಭಜಿಸಿದ ಆಪರೇಟರ್ನದಲ್ಲದ ಇನ್ಲೈನ್ CA ಎಂದರೆ ಫೈಲ್ ಎರಡು ಮೂಲಗಳಿಂದ ಜೋಡಿಸಲಾಗಿದೆ, ಮತ್ತು ಅದೇ ಸ್ಪಷ್ಟವಾಗಿ ನಿರಾಕರಿಸಬೇಕಾದ ಸಂದರ್ಭ.

verify-x509-name name, name-prefix ಅಥವಾ subject ಮೋಡ್ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಕೊನೆಯದು ಸರ್ವರ್ ಮುದ್ರಿಸುವ ನಿಖರ ಕ್ರಮದಲ್ಲಿ ಪೂರ್ಣ ವಿಶಿಷ್ಟ ಹೆಸರನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ. ಮೌಲ್ಯದ ಆಕಾರಕ್ಕೆ ಹೊಂದುವ ಮೋಡ್ ಆಯ್ಕೆ ಮಾಡಿ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಹತ್ತಿರದ ತಪ್ಪಿನ ಬಗ್ಗೆ ಎಚ್ಚರಿಸುವ ಬದಲು ಪ್ರತಿ ಸಂಪರ್ಕವನ್ನೂ ತಿರಸ್ಕರಿಸುತ್ತದೆ. ನೀವು ಬರೆಯದ ಫೈಲ್ಗೆ ಸರಳ ಹೋಸ್ಟ್ಹೆಸ್ಸಿನೊಂದಿಗೆ name ಅತ್ಯಂತ ಕಡಿಮೆ ಆಶ್ಚರ್ಯಕರ ಆಯ್ಕೆ.

ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುವ ಆಯ್ಕೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

OpenVPN 2.6 data-ciphers ಮೂಲಕ ಸೈಫರ್ಗಳನ್ನು ಮಾತುಕತೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಹಳೆಯ cipher AES-256-CBC ಸಾಲು ಮಾತ್ರ ಹೊಂದಿರುವ ಪ್ರೊಫೈಲ್ ನಿಯಂತ್ರಣ ಚಾನಲ್ ಪೂರ್ಣಗೊಳಿಸಿ ನಂತರ ಡೇಟಾದಲ್ಲಿ ನಿಲ್ಲಬಹುದು. ಆ ಮೌಲ್ಯವನ್ನು ಓದುವುದು ಫೈಲ್ ನೀವು ಸೇರುವ ಸರ್ವರ್ಗಿಂತ ಹಳೆಯದೇ ಎಂದು ಹೇಳುತ್ತದೆ; 2.6 ನ ಕೈಪಿಡಿ ಪುಟ ಮಾತುಕತೆಯ ಕ್ರಮವನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಆಪರೇಟರ್ಗೆ ಉಲ್ಲೇಖಿಸಬೇಕಿದ್ದರೆ.

ಫೈಲ್ಹೆಸ್ಸಿಲ್ಲದ auth-user-pass ಎಂದರೆ ಕ್ಲೈಂಟ್ ಕೇಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ವಯಂಪೂರ್ಣ ಕಾಣುವ ಪ್ರೊಫೈಲ್ಗೂ ರುಜುವಾತುಗಳು ಬೇಕು. auth-user-pass credentials.txt ಎಂದರೆ ನಿಮಗೆ ಕಳುಹಿಸದಿರಬಹುದಾದ ಫೈಲ್ ಅನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ. nobind ಮತ್ತು resolv-retry infinite ಸಾಮಾನ್ಯ ಮತ್ತು ನಿರುಪದ್ರವಿ, ಆದರೆ explicit-exit-notify UDP ಗೆ ಮಾತ್ರ ಮತ್ತು TCP ಮೇಲೆ ನಿರುಪಯುಕ್ತ.

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

ನಿರ್ಧರಿಸಿ, ನಂತರ ನಿರ್ಧರಿಸಿದ್ದನ್ನು ದಾಖಲಿಸಿ

ಈ ಓದಿನ ನಂತರ ಮೂರು ಫಲಿತಾಂಶಗಳಿವೆ, ಮತ್ತು ಒಂದೇ ಆಮದು. ಎಂಡ್ಪಾಯಿಂಟ್ ಮತ್ತು ಪಿನ್ಗಳು ಪ್ರತ್ಯೇಕ ಚಾನಲ್ ಮೂಲಕ ಬಂದ ಸೂಚನೆಗಳಿಗೆ ಹೊಂದಿದಾಗ, ಅದನ್ನು ಆಮದು ಮಾಡಿ. ಎಂಡ್ಪಾಯಿಂಟ್ ಸರಿ ಕಂಡರೂ ಪಿನ್ಗಳು ಅಥವಾ CA ಹೊಂದದಿದ್ದರೆ, ಸರಿಪಡಿಸಿದ ಫೈಲ್ ಕೇಳಿ. ಫೈಲ್ ಬೇರೆ ಬೇರೆ ಮೂಲಗಳ ಎಂಡ್ಪಾಯಿಂಟ್ಗಳನ್ನು ಅಥವಾ CA ವಸ್ತುವನ್ನು ಬೆರೆಸಿದರೆ, ಅದನ್ನು ಅಳಿಸಿ ಹೊಸ ಪ್ರತಿ ಕೇಳಿ.

ನೀವು ಪರಿಶೀಲಿಸಿದ ಹ್ಯಾಶ್ ಅನ್ನು ದಾಖಲಿಸಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ಫೈಲ್ ಬದಲಾಗಿದೆಯೇ ಎಂದು ತಿಳಿಯಲು: sha256sum profile.ovpn, ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಎಂಡ್ಪಾಯಿಂಟ್ ಪಕ್ಕದಲ್ಲಿ ಅಂಟಿಸಿ. ಪ್ರೊಫೈಲ್ ವಿಳಾಸಗಳ ಪಟ್ಟಿಯಲ್ಲ, ಒಂದು ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ remote ಅನ್ನು ಬೇರೊಬ್ಬರ ನಂಬಿಕೆ ಬ್ಲಾಕ್ಗೆ ಅವರ ರುಜುವಾತುಗಳನ್ನು ಉಳಿಸಿಕೊಂಡು ಎಂದಿಗೂ ಸೇರಿಸಬೇಡಿ.

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

ನೀವು ಅದನ್ನು ಆಮದು ಮಾಡಿ ಮೊದಲ ಪ್ರಯತ್ನ ವಿಫಲವಾದರೆ, ಕ್ಲೈಂಟ್ ಅನ್ನು --verb 3 ಜೊತೆಗೆ ಚಲಾಯಿಸಿ ಮತ್ತು ಮೊದಲ ಹತ್ತು ಸಾಲುಗಳನ್ನು ಓದಿ: ವಿಭಜಿಸಿದ remote ವಿಳಾಸ, ಮಾತುಕತೆ ಮಾಡಿದ proto ಮತ್ತು TLS ದೋಷ ಅದೇ ಕ್ರಮದಲ್ಲಿ ಬರುತ್ತವೆ, ಇದು ಮೇಲಿನ ಯಾವ ಪರಿಶೀಲನೆ ತಪ್ಪಿಸಿದಿರಿ ಎಂದು ಹೇಳುತ್ತದೆ.