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 મોડ, સંદેશે લીધેલો પથ અને સર્વરે પાછો આપેલો પ્રતિસાદ નામ આપી શકો. તે ચાર તથ્યો અસ્પષ્ટ આઉટબોક્સ સમસ્યાને એવા ફેરફારમાં ફેરવે છે જે કોઈ સમીક્ષા કરી શકે.