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 பயன்முறை, செய்தி சென்ற பாதை மற்றும் சேவையகம் திருப்பியளித்த பதில் ஆகியவற்றைக் கூற முடிந்தால் சரிபார்ப்புப் பட்டியல் முழுமையடைகிறது. அந்த நான்கு உண்மைகள் தெளிவற்ற வெளியேற்றப் பெட்டிப் பிரச்சினையை யாராவது மதிப்பாய்வு செய்யக்கூடிய மாற்றமாக மாற்றுகின்றன.