ike-scan får inget svar från en fungerande IPsec-gateway

Gatewayen betjänar telefoner och bärbara datorer varje dag, men ike-scan rapporterar att inga värdar svarade. Den utskriften läses som bevis för att IPsec saknas på enheten. Vanligtvis betyder det att enheten kastade bort varje förslag i sonden och valde att inte svara något. Tystnad är också ett svar, och det är det minst informativa svaret verktyget kan ge dig.

Gå igenom tre separata frågor: kom paketet fram, matchade något förslag, och avvisade något annat motparten?

Steg 1: läs förslaget som verktyget skickar

Huvudläget börjar med en SA-nyttolast som listar de transformeringar som initiativtagaren accepterar, och ike-scan fyller listan från en kompilerad standard. Standarduppsättningen är medvetet gammal: DES och 3DES för kryptering, MD5 och SHA1 för hashning, grupper 1 och 2 för nyckelutbyte, fördelade nycklar för autentisering. Ingen AES, ingen SHA-2, ingen grupp 14. En gateway konfigurerad för AES-256 med SHA-256 och modp2048 delar ingenting med den.

Vissa implementeringar svarar en icke-matchande sond med en NO-PROPOSAL-CHOSEN-avisering. Andra släpper den bara, vilket är vanligt på apparater som behandlar okända motparter som brus. Hur som helst skriver skanningen ingenting, och det ingenting är identiskt med hur en filtrerad UDP 500 ser ut utifrån, som ike-scan-projektets dokumentation gör klart om standarduppsättningen.

Steg 2: erbjud ett modernt förslag

Ersätt standarduppsättningen med --trans. Attributformen tar IKE-attributnummer direkt: 1 för kryptering, 2 för hash, 3 för autentisering, 4 för gruppen och 14 för nyckellängd när algoritmen tar en. Det som kommer ut är en rad du kan läsa högt i en ändringsgranskning.

Positionsformen bär samma värden i ordning och undviker parenteser, vilket spelar roll när kommandot går genom ett skal.

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

Ett förslag per paket är långsamt när du räknar upp, så loopa över de troliga värdena: kryptering 5, 7/128, 7/192, 7/256; hash 1, 2, 5, 6, 7; grupper 1, 2, 5, 14, 15, 19, 20, 21; autentisering 1 för en fördelad nyckel och 3 för RSA-signaturer. Skriv ut varje kommando innan du kör det, så att transkriptet visar vad som erbjöds och i vilken ordning.

Steg 3: tolka ett svar

Ett svar bevisar exakt två saker: en IKE-responder är nåbar på den adressen, och ett erbjudet förslag var acceptabelt. Det säger ingenting om den fördelade nyckeln, L2TP-lagret eller om ett användarkonto finns. En lyckad skanning är helt förenlig med att varje senare steg misslyckas.

På en gateway du driftar är detta den verkligt användbara delen. Skanningen berättar vilka förslag enheten fortfarande accepterar, och ett resultat begränsat till äldre transformeringar är ett fynd om enhetens policy, inte ett skäl att försvaga klienten.

Steg 4: tolka tystnaden

Tystnad är svagare bevis än det ser ut som. Varje förslag kan ha avvisats, UDP 500 och 4500 kan vara filtrerade, källan kan vara hastighetsbegränsad efter en burst, eller tjänsten kan lyssna på en annan adress än den du skannade. Jämför gatewayens IKE-logg med en klient som redan ansluter med giltiga uppgifter innan du drar någon slutsats om boxen.

Burstbeteende hör till den listan eftersom uppräkning genererar många paket i ett kort fönster. En gateway som svarar på de första försöken och sedan tystnar beskriver sin anti-DoS-policy snarare än sin förslaguppsättning.

Steg 5: skriv ned vad du bevisade

Skriv den accepterade kombinationen bredvid firmwareversionen och jämför den sedan med de transformeringar som klienterna du bryr dig om erbjuder som standard. Gapet mellan de två listorna är konfigurationsproblemet, och skanningen gjorde det bara synligt. Om de enda accepterade förslagen är sådana du inte skulle välja, hör rättelsen hemma i gatewaypolicyn eller i en klientprofil, aldrig i sonden.

En sond som aldrig svarade har ändå svarat på något: den visar vilka förslag den här enheten är villig att diskutera, och vilka den hellre skulle tappa på golvet.