ike-scan krijgt geen antwoord van een werkende IPsec-gateway

De gateway bedient dagelijks telefoons en laptops, toch meldt ike-scan dat geen hosts hebben geantwoord. Die uitvoer leest als bewijs dat IPsec op het apparaat ontbreekt. Meestal betekent het dat het apparaat elk voorstel in de probe verwierp en ervoor koos niets te antwoorden. Stilte is ook een antwoord, en het is het minst informatieve antwoord dat de tool je kan geven.

Werk drie afzonderlijke vragen door: is het pakket aangekomen, paste een voorstel, en weigerde iets anders de peer?

Stap 1: lees het voorstel dat de tool stuurt

Hoofdmodus begint met een SA-payload die de transformaties opsomt die de initiator accepteert, en ike-scan vult die lijst vanuit een gecompileerde standaard. De standaardset is bewust oud: DES en 3DES voor versleuteling, MD5 en SHA1 voor hashing, groepen 1 en 2 voor sleuteluitwisseling, vooraf gedeelde sleutels voor authenticatie. Geen AES, geen SHA-2, geen groep 14. Een gateway die is geconfigureerd voor AES-256 met SHA-256 en modp2048 deelt er niets mee.

Sommige implementaties antwoorden een niet-passende probe met een NO-PROPOSAL-CHOSEN-melding. Andere laten hem gewoon vallen, wat gebruikelijk is op apparaten die onbekende peers als ruis behandelen. Hoe dan ook drukt de scan niets af, en dat niets is identiek aan hoe een gefilterde UDP 500 er van buiten uitziet, zoals de documentatie van het ike-scan-project duidelijk maakt over de standaardset.

Stap 2: bied één modern voorstel aan

Vervang de standaardset door --trans. De attribuutvorm neemt IKE-attribuutnummers rechtstreeks: 1 voor versleuteling, 2 voor hash, 3 voor authenticatie, 4 voor de groep en 14 voor sleutellengte wanneer het algoritme er een neemt. Wat eruit komt is een regel die je hardop kunt voorlezen in een wijzigingsreview.

De positionele vorm draagt dezelfde waarden in volgorde en vermijdt haakjes, wat telt zodra de opdracht door een shell gaat.

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

Eén voorstel per pakket is traag wanneer je opsomt, dus loop over de plausibele waarden: versleuteling 5, 7/128, 7/192, 7/256; hash 1, 2, 5, 6, 7; groepen 1, 2, 5, 14, 15, 19, 20, 21; authenticatie 1 voor een vooraf gedeelde sleutel en 3 voor RSA-handtekeningen. Print elk commando voordat je het uitvoert, zodat het transcript laat zien wat werd aangeboden en in welke volgorde.

Stap 3: interpreteer een antwoord

Een antwoord bewijst precies twee dingen: er is een IKE-responder bereikbaar op dat adres, en één aangeboden voorstel was aanvaardbaar. Het zegt niets over de vooraf gedeelde sleutel, de L2TP-laag of het bestaan van een gebruikersaccount. Een geslaagde scan is volledig verenigbaar met het falen van elke volgende fase.

Op een gateway die je beheert, is dit het echt nuttige deel. De scan vertelt welke voorstellen het apparaat nog accepteert, en een resultaat dat beperkt blijft tot legacy-transformaties is een bevinding over het apparaatbeleid, geen reden om de client te verzwakken.

Stap 4: interpreteer stilte

Stilte is zwakker bewijs dan het lijkt. Elk voorstel kan zijn afgewezen, UDP 500 en 4500 kunnen gefilterd zijn, de bron kan na een burst zijn geratelimiteerd, of de dienst luistert misschien op een ander adres dan het adres dat je scande. Vergelijk de IKE-log van de gateway met een client die al verbinding maakt met geldige inloggegevens voordat je iets over het apparaat concludeert.

Burstgedrag hoort in die lijst omdat opsomming veel pakketten in een kort venster genereert. Een gateway die de eerste pogingen beantwoordt en daarna stil wordt, beschrijft zijn anti-DoS-beleid in plaats van zijn voorstellenset.

Stap 5: leg vast wat je hebt bewezen

Schrijf de geaccepteerde combinatie naast de firmwareversie en vergelijk die vervolgens met de transformaties die de clients die je belangrijk vindt standaard aanbieden. De kloof tussen die twee lijsten is het configuratieprobleem, en de scan maakte het alleen zichtbaar. Als de enige geaccepteerde voorstellen degene zijn die je niet zou kiezen, hoort de correctie in het gatewaybeleid of in een cliëntprofiel, nooit in de probe.

Een probe die nooit antwoordde, heeft toch iets beantwoord: hij laat zien welke voorstellen dit apparaat wil bespreken, en welke het liever op de grond laat vallen.