Posta bidalketa huts egiten du VPN-a konektatzean: aurkitu etapa

Goiz osoan funtzionatu duen posta tunela altxatzen den unean gelditzen da, eta lehen bulkada pasahitza berriro idaztea da. Bulkada horrek galdera erabilgarriagoa saihesten du: iritsi al zen bezeroa zerbitzarira, eta nahikoa urrun joan al zen kredentzialak eskaintzeko? Denbora-muga bat, ziurtagiri-errore bat eta ukapen-erantzun bat hiru hutsegite desberdin dira, eta hirugarrenak bakarrik ukitzen du kontua. Etapak ordenan zeharkatuz, VPN-a probatu dezakezun aldagai bihurtzen da, erruduntzat jotzen duzun susmagarri bat izan beharrean.

1. urratsa: sailkatu hutsa kredentzialak ukitu aurretik

Irakurri aplikazioak benetan sortu duen errorea, eta jarri hiru ontzietako batean. Denbora-muga edo konexioaren berrezarpena bada, TCP bideak huts egin du; TLS edo ziurtagiri errorea bada, bideak funtzionatu du eta eskuko keinuak ez; SMTP erantzunak kodea badakar, posta-zerbitzari batek erantzun du eta erabaki bat hartu du. Ontzi bakoitzak arduradun desberdin bat seinalatzen du.

Ontziak bereiztea merezi du, konponketak elkarren kontra daudelako. Denbora-muga luzatzeak ez du ezer konpontzen zerbitzariak bidaltzailea ukatzen duenean, eta pasahitza aldatzeak ez du ezer egiten bidea blokeatuta dagoenean. Erantzun-kodea zerrendako frogarik baliotsuena da, garraio-kate osoak funtzionatu duela eta arazoa politika edo identitatea dela frogatzen duelako. Gorde testu zehatza, edozein egoera-kode hedatu barne, berriro saiatu aurretik.

Gelditu hemen hutsegitea VPN-tik kanpo berregin ezin baduzu. Aplikazio bakarrean makina bakarrean agertzen den arazoa ez da oraindik sare-arazoa.

2. urratsa: egiaztatu muturra eta TLS modua

Mezuak bidaltzea zerbitzu propio bat da, ez da zerbitzari arteko birbidalketa bera. Egiaztatu ostalari-izena, ataka eta TLS modua hornitzailearen bidalketa-dokumentazioan, beste posta-konfigurazio batetik hartutako ataka ezagun bat ez baita froga. 587 atakak testu laueko agurra eta ondoren STARTTLS espero ditu, 465 atakak berriz TLS lehen bytetik.

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

Bi probei dagokien okerra exekutatzea da bezeroak beste modu baterako konfiguratuta dagoenean egiten duen akats zehatza. TLS inplizituaren proba 587an trabatzen bada, edo STARTTLS proba 465ean huts egiten badu, ataka eta modua ez datoz bat. Konpondu modua bezeroan, ziurtagiriaren egiaztapena desaktibatu beharrean, horrek konfigurazio-errore bat egiaztatu gabeko konexio bihurtzen baitu. Banaketa nahikoa zaharra da estandarizatuta egoteko: 465 atakako TLS inplizitua RFC 8314 agirian deskribatzen den antolamendua da.

Hemen ziurtagiri-errorea informazioa da, ez oztopoa. Zerbitzariak aurkeztu duen identitatea eta bezeroak espero zuen identitatea izendatzen ditu, eta biak konpon daitezke konexioa ahuldu gabe.

3. urratsa: konparatu bideak kontua aldatu gabe

Eduki muturra, kontua eta bezeroaren ezarpenak konstante, eta aldatu bidea soilik. Bidali behin tunela jaitsita eta behin tunela igota, eta idatzi bidea eta zerbitzariak ikusiko lukeen iturburu-helbidea. Hutsa bidea jarraitzen badu, isolatu duzu; makina jarraitzen badu, ez.

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

Tunel osoak hornitzaileak ikusten duen iturburu-helbidea aldatzen du, eta hornitzaile batzuek iturburu ezezagun bat pasahitz ezezagun bat baino zorrotzago tratatzen dute. Hori haien aldeko politika-erabakia da, eta zerrenda gris bat, abiadura-muga bat edo blokeo bat izan daiteke. Ez orokortu hornitzaile batetik denetara, eta ez pentsatu NAT arau bat falta izateak huts guztiak azaltzen dituenik. curl erregistroak zein etapa huts egin zuen erakusten du, aplikazioaren beraren erregistroak erakutsi ez arren.

Tunelak internet trafikoa eraman behar badu, bere bideratzeak eta irteera-politikak helmuga hau baimendu behar dute. Bide pribatuak soilik daramatzan tunelak posta-konexioa bide lokalean uzten du, eta hori beste konparazio bat da.

4. urratsa: bidali mezu kaltegabe bat eta idatzi erantzuna

Konpondu huts egin zuen etapa, eta gero bidali mezu kaltegabe bat aplikazio beretik, web-postako orrialde batetik beharrean. Aplikazioaren beraren bidalketa-bidea probatzen ari zara, bere ezarpen gordeak eta TLS modua barne. Web-postako saio batek ez du horren gainean ezer frogatzen.

Idatzi erantzuna, ataka, TLS modua eta erabili duzun bidea, hurrengo pertsonak emaitza berregin dezan. Funtzionatzen duen nabigatzaile bat eta VPN ikono berde bat beste gauzei buruzko oharrak dira. Mezua iristen bada, geratzen den lana konfigurazio hori kontu honetatik bidaltzen duen makina bakoitzerako lehenetsia egitea da.

Egiaztapen-zerrenda osatuta dago huts egin zuen etapa, bezeroak erabiltzen duen ataka eta TLS modua, mezuak egin zuen bidea eta zerbitzariak itzulitako erantzuna izenda ditzazunean. Lau gertaera horiek irteera-postontzi arazo lauso bat norbaiti berrikusi ahal izateko aldaketa bihurtzen dute.