ike-scan nu primește răspuns de la un gateway IPsec funcțional
Faptul că niciun host nu a răspuns înseamnă de obicei o nepotrivire a propunerii, nu un VPN lipsă. Citiți setul de transformări implicit, oferiți unul modern și interpretați tăcerea cu atenție.
Gateway-ul deservește telefoane și laptopuri în fiecare zi, totuși ike-scan raportează că niciun host nu a răspuns. Acea ieșire se citește ca dovadă că IPsec lipsește din dispozitiv. De obicei înseamnă că dispozitivul a aruncat fiecare propunere din sondă și a ales să nu răspundă nimic. Tăcerea este și ea un răspuns și este cel mai puțin informativ răspuns pe care instrumentul ți-l poate da.
Parcurge trei întrebări separate: a ajuns pachetul, s-a potrivit vreo propunere și a refuzat altceva partenerul?
Pasul 1: citește propunerea pe care o trimite instrumentul
Modul principal începe cu un payload SA care listează transformările pe care inițiatorul le va accepta, iar ike-scan completează lista dintr-un implicit compilat. Setul implicit este intenționat vechi: DES și 3DES pentru criptare, MD5 și SHA1 pentru hashing, grupurile 1 și 2 pentru schimbul de chei, chei prepartajate pentru autentificare. Niciun AES, niciun SHA-2, niciun grup 14. Un gateway configurat pentru AES-256 cu SHA-256 și modp2048 nu împărtășește nimic cu el.
Unele implementări răspund unei sonde nepotrivite cu o notificare NO-PROPOSAL-CHOSEN. Altele o aruncă pur și simplu, ceea ce este obișnuit pe aparatele care tratează partenerii necunoscuți ca zgomot. În orice caz, scanarea nu tipărește nimic, iar acel nimic este identic cu felul în care arată din exterior un UDP 500 filtrat, după cum documentația proiectului ike-scan clarifică despre setul implicit.
Pasul 2: oferă o propunere modernă
Înlocuiți setul implicit cu --trans. Forma cu atribute preia direct numerele de atribut IKE: 1 pentru criptare, 2 pentru hash, 3 pentru autentificare, 4 pentru grup și 14 pentru lungimea cheii când algoritmul o acceptă. Rezultatul este o linie pe care o poți citi cu voce tare într-o revizuire a modificărilor.
Forma pozițională transportă aceleași valori în ordine și evită parantezele, ceea ce contează când comanda trece printr-un shell.
ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10
O propunere pe pachet este lentă când enumeri, așa că parcurge valorile plauzibile: criptare 5, 7/128, 7/192, 7/256; hash 1, 2, 5, 6, 7; grupuri 1, 2, 5, 14, 15, 19, 20, 21; autentificare 1 pentru o cheie prepartajată și 3 pentru semnături RSA. Tipărește fiecare comandă înainte de a o executa, astfel încât transcrierea să arate ce s-a oferit și în ce ordine.
Pasul 3: interpretează un răspuns
Un răspuns dovedește exact două lucruri: un responder IKE este accesibil la acea adresă și o propunere oferită a fost acceptabilă. Nu spune nimic despre cheia prepartajată, stratul L2TP sau dacă există un cont de utilizator. O scanare reușită este complet compatibilă cu eșecul fiecărei etape ulterioare.
Pe un gateway pe care îl administrezi, aceasta este partea cu adevărat utilă. Scanarea îți spune ce propuneri mai acceptă dispozitivul, iar un rezultat limitat la transformări vechi este o constatare despre politica dispozitivului, nu un motiv de a slăbi clientul.
Pasul 4: interpretează tăcerea
Tăcerea este o dovadă mai slabă decât pare. Fiecare propunere poate fi fost respinsă, UDP 500 și 4500 pot fi filtrate, sursa poate fi limitată ca rată după o rafală sau serviciul poate asculta la o adresă diferită de cea scanată. Compară jurnalul IKE al gateway-ului cu un client care se conectează deja folosind acreditări valide înainte de a trage vreo concluzie despre cutie.
Comportamentul la rafală face parte din acea listă pentru că enumerarea generează multe pachete într-o fereastră scurtă. Un gateway care răspunde primelor încercări și apoi tace își descrie politica anti-DoS, nu setul de propuneri.
Pasul 5: notează ce ai dovedit
Scrie combinația acceptată lângă versiunea de firmware, apoi compară-o cu transformările pe care clienții care te interesează le oferă implicit. Diferența dintre cele două liste este problema de configurare, iar scanarea doar a făcut-o vizibilă. Dacă singurele propuneri acceptate sunt cele pe care nu le-ai alege, corectarea aparține politicii gateway-ului sau unui profil de client, niciodată sondei.
O sondă care nu a răspuns niciodată a răspuns totuși la ceva: arată ce propuneri este dispus acest dispozitiv să discute și pe care ar prefera să le lase să cadă pe podea.