VPN ಸಂಪರ್ಕಗೊಂಡಾಗ ಮೇಲ್ ಸಲ್ಲಿಕೆ ವಿಫಲವಾಗುತ್ತದೆ: ಹಂತವನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ

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

ಹಂತ 1: ರುಜುವಾತುಗಳನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ವೈಫಲ್ಯವನ್ನು ವರ್ಗೀಕರಿಸಿ

ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ಉತ್ಪಾದಿಸಿದ ದೋಷವನ್ನು ಓದಿ, ನಂತರ ಅದನ್ನು ಮೂರು ಬುಟ್ಟಿಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಹಾಕಿ. ಟೈಮೌಟ್ ಅಥವಾ ಸಂಪರ್ಕ ಮರುಹೊಂದಿಕೆ ಎಂದರೆ TCP ಮಾರ್ಗ ವಿಫಲವಾಯಿತು; TLS ಅಥವಾ ಪ್ರಮಾಣಪತ್ರ ದೋಷ ಎಂದರೆ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡಿತು ಮತ್ತು ಹ್ಯಾಂಡ್ಶೇಕ್ ಮಾಡಲಿಲ್ಲ; ಕೋಡ್ನೊಂದಿಗೆ SMTP ಪ್ರತಿಕ್ರಿಯೆ ಎಂದರೆ ಮೇಲ್ ಸರ್ವರ್ ಉತ್ತರಿಸಿ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಂಡಿತು. ಪ್ರತಿ ಬುಟ್ಟಿ ಬೇರೆ ಜವಾಬ್ದಾರರ ಕಡೆ ತೋರಿಸುತ್ತದೆ.

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

VPN ಹೊರಗೆ ವೈಫಲ್ಯವನ್ನು ಪುನರುತ್ಪಾದಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಇಲ್ಲಿಯೇ ನಿಲ್ಲಿಸಿ. ಒಂದು ಯಂತ್ರದಲ್ಲಿ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ ಕಾಣುವ ಸಮಸ್ಯೆ ಇನ್ನೂ ನೆಟ್ವರ್ಕ್ ಸಮಸ್ಯೆ ಅಲ್ಲ.

ಹಂತ 2: ಎಂಡ್ಪಾಯಿಂಟ್ ಮತ್ತು TLS ಮೋಡ್ ಖಚಿತಪಡಿಸಿ

ಸಂದೇಶ ಸಲ್ಲಿಕೆ ಪ್ರತ್ಯೇಕ ಸೇವೆ, ಸರ್ವರ್-ನಿಂದ-ಸರ್ವರ್ ರಿಲೇಗೆ ಸಮಾನವಲ್ಲ. ಸಲ್ಲಿಕೆಗಾಗಿ ಪೂರೈಕೆದಾರರ ದಾಖಲೆಗಳಿಂದ ಹೋಸ್ಟ್ಹೆಸರು, ಪೋರ್ಟ್ ಮತ್ತು TLS ಮೋಡ್ ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಇನ್ನೊಂದು ಮೇಲ್ ಸೆಟಪ್ನಿಂದ ಎರವಲು ಪಡೆದ ಪರಿಚಿತ ಪೋರ್ಟ್ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಪೋರ್ಟ್ 587 ಸರಳ ಪಠ್ಯದ ಅಭಿವಾದನೆ ಮತ್ತು ನಂತರ STARTTLS ನಿರೀಕ್ಷಿಸುತ್ತದೆ, ಆದರೆ ಪೋರ್ಟ್ 465 ಮೊದಲ ಬೈಟ್ನಿಂದಲೂ TLS ನಿರೀಕ್ಷಿಸುತ್ತದೆ.

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

ಎರಡರಲ್ಲಿ ತಪ್ಪಾದ ಪರೀಕ್ಷೆಯನ್ನು ಚಲಾಯಿಸುವುದು ಕ್ಲೈಂಟ್ ಇನ್ನೊಂದು ಮೋಡ್ಗೆ ಸಂರಚಿಸಲಾಗಿರುವಾಗ ಮಾಡುವ ನಿಖರ ತಪ್ಪು. ಇಂಪ್ಲಿಸಿಟ್-TLS ಪರೀಕ್ಷೆ 587ರಲ್ಲಿ ನೇತಾಡಿದರೆ, ಅಥವಾ STARTTLS ಪರೀಕ್ಷೆ 465ರಲ್ಲಿ ವಿಫಲವಾದರೆ, ಪೋರ್ಟ್ ಮತ್ತು ಮೋಡ್ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಬದಲು ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಮೋಡ್ ಸರಿಪಡಿಸಿ, ಏಕೆಂದರೆ ಅದು ಸಂರಚನಾ ದೋಷವನ್ನು ಪರಿಶೀಲಿಸದ ಸಂಪರ್ಕವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಈ ವಿಭಜನೆ ಪ್ರಮಾಣೀಕರಿಸಲ್ಪಡುವಷ್ಟು ಹಳೆಯದು: ಪೋರ್ಟ್ 465ರಲ್ಲಿ ಇಂಪ್ಲಿಸಿಟ್ TLS RFC 8314 ನಲ್ಲಿ ವಿವರಿಸಿದ ವ್ಯವಸ್ಥೆ.

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

ಹಂತ 3: ಖಾತೆ ಬದಲಾಯಿಸದೆ ಮಾರ್ಗಗಳನ್ನು ಹೋಲಿಸಿ

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

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

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

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

ಹಂತ 4: ಒಂದು ನಿರುಪದ್ರವ ಸಂದೇಶ ಕಳುಹಿಸಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ದಾಖಲಿಸಿ

ವಿಫಲವಾದ ಹಂತವನ್ನು ಸರಿಪಡಿಸಿ, ನಂತರ ವೆಬ್ಮೇಲ್ ಪುಟದ ಬದಲು ಅದೇ ಅಪ್ಲಿಕೇಶನ್ ಮೂಲಕ ಒಂದು ನಿರುಪದ್ರವ ಸಂದೇಶ ಸಲ್ಲಿಸಿ. ನೀವು ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ಕಳುಹಿಸುವ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದೀರಿ, ಅದರ ಸಂಗ್ರಹಿತ ಸೆಟ್ಟಿಂಗ್ಗಳು ಮತ್ತು TLS ಮೋಡ್ ಸೇರಿದಂತೆ. ವೆಬ್ಮೇಲ್ ಅಧಿವೇಶನ ಅದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಪ್ರತಿಕ್ರಿಯೆ, ಪೋರ್ಟ್, TLS ಮೋಡ್ ಮತ್ತು ನೀವು ಬಳಸಿದ ಮಾರ್ಗವನ್ನು ದಾಖಲಿಸಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ಫಲಿತಾಂಶವನ್ನು ಪುನರುತ್ಪಾದಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ. ಕೆಲಸ ಮಾಡುವ ಬ್ರೌಸರ್ ಮತ್ತು ಹಸಿರು VPN ಐಕಾನ್ ಬೇರೆ ವಿಷಯಗಳ ಬಗ್ಗೆ ಅವಲೋಕನಗಳು. ಸಂದೇಶ ತಲುಪಿದರೆ, ಉಳಿದ ಕೆಲಸ ಆ ಸಂರಚನೆಯನ್ನು ಈ ಖಾತೆಯ ಮೂಲಕ ಕಳುಹಿಸುವ ಪ್ರತಿ ಯಂತ್ರಕ್ಕೂ ಡಿಫಾಲ್ಟ್ ಮಾಡುವುದು.

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