ike-scan får intet svar fra en fungerende IPsec-gateway

Gatewayen betjener telefoner og bærbare computere hver dag, og alligevel rapporterer ike-scan, at ingen værter svarede. Det output ser ud som bevis for, at IPsec mangler på enheden. Normalt betyder det, at enheden kasserede hvert forslag i sonden og valgte ikke at svare noget. Tavshed er et svar, og det er det mindst informative, værktøjet kan give dig.

Gå gennem tre separate spørgsmål: nåede pakken frem, passede noget forslag, og afviste noget andet peer'en?

Trin 1: læs det forslag, værktøjet sender

Hovedtilstand begynder med en SA-nyttelast, der lister de transformationer, initiativtageren vil acceptere, og ike-scan fylder listen fra et kompileret standardudvalg. Standardsættet er med vilje gammelt: DES og 3DES til kryptering, MD5 og SHA1 til hashing, gruppe 1 og 2 til nøgleudvekslingen, foruddelte nøgler til godkendelse. Ingen AES, ingen SHA-2, ingen gruppe 14. En gateway konfigureret til AES-256 med SHA-256 og modp2048 deler intet med det.

Nogle implementeringer svarer på en uoverensstemmende sonde med en NO-PROPOSAL-CHOSEN-notifikation. Andre dropper den bare, hvilket er almindeligt på apparater, der behandler ukendte peers som støj. Uanset hvad udskriver scanningen intet, og det intet er identisk med, hvordan en filtreret UDP 500 ser ud udefra, som ike-scan-projektets dokumentation gør klart om standardsættet.

Trin 2: tilbyd et moderne forslag

Erstat standardsættet med --trans. Attributformen tager IKE-attributnumre direkte: 1 til kryptering, 2 til hash, 3 til godkendelse, 4 til gruppen og 14 til nøglelængde, når algoritmen tager en. Det, der kommer ud, er en linje, du kan læse højt i en ændringsgennemgang.

Positionsformen bærer de samme værdier i rækkefølge og undgår parenteser, hvilket betyder noget, når kommandoen går gennem en shell.

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

Et forslag pr. pakke er langsomt, når du opregner, så løb gennem de sandsynlige værdier: kryptering 5, 7/128, 7/192, 7/256; hash 1, 2, 5, 6, 7; grupper 1, 2, 5, 14, 15, 19, 20, 21; godkendelse 1 for en forudelt nøgle og 3 for RSA-signaturer. Udskriv hver kommando, før du kører den, så udskriften viser, hvad der blev tilbudt, og i hvilken rækkefølge.

Trin 3: fortolk et svar

Et svar beviser præcis to ting: en IKE-svarer kan nås på den adresse, og et tilbudt forslag var acceptabelt. Det siger intet om den foruddelte nøgle, L2TP-laget eller om der findes en brugerkonto. En vellykket scanning er fuldt ud forenelig med, at hvert senere trin fejler.

På en gateway, du driver, er dette den virkeligt nyttige del. Scanningen fortæller dig, hvilke forslag enheden stadig accepterer, og et resultat begrænset til forældede transformationer er en konstatering om enhedens politik, ikke en grund til at svække klienten.

Trin 4: fortolk tavshed

Tavshed er svagere bevis, end det ser ud. Hvert forslag kan være blevet afvist, UDP 500 og 4500 kan være filtreret, kilden kan være hastighedsbegrænset efter en byge, eller tjenesten kan lytte på en anden adresse end den, du scannede. Sammenlign gatewayens IKE-log med en klient, der allerede forbinder med gyldige legitimationsoplysninger, før du konkluderer noget om boksen.

Bygeadfærd hører på den liste, fordi opregning genererer mange pakker i et kort vindue. En gateway, der svarer på de første forsøg og derefter bliver tavs, beskriver sin anti-DoS-politik snarere end sit forslagssæt.

Trin 5: noter, hvad du beviste

Skriv den accepterede kombination ved siden af firmwareversionen, og sammenlign den derefter med de transformationer, de klienter, du bryder dig om, tilbyder som standard. Gabet mellem de to lister er konfigurationsproblemet, og scanningen gjorde det bare synligt. Hvis de eneste accepterede forslag er nogle, du ikke ville vælge, hører rettelsen til i gatewaypolitikken eller i en klientprofil, aldrig i sonden.

En sonde, der aldrig svarede, har alligevel svaret noget: den viser, hvilke forslag denne enhed er villig til at drøfte, og hvilke den hellere vil tabe på gulvet.