ike-scan ne ricevas respondon de funkcianta IPsec-pordego

La pordego ĉiutage servas telefonojn kaj tekkomputilojn, tamen ike-scan raportas, ke neniu gastiganto respondis. Tiu eligo aspektas kiel pruvo, ke IPsec mankas en la aparato. Kutime tio signifas, ke la aparato forĵetis ĉiun proponon en la sondado kaj elektis respondi nenion. Silento estas respondo, kaj ĝi estas la plej malinforma, kiun la ilo povas doni al vi.

Trairu tri apartajn demandojn: ĉu la paketo alvenis, ĉu iu propono kongruis, kaj ĉu io alia rifuzis la partneron?

Paŝo 1: legu la proponon, kiun la ilo sendas

Ĉefa reĝimo komenciĝas per SA ŝarĝo, kiu listigas la transformojn, kiujn la iniciatinto akceptos, kaj ike-scan plenigas tiun liston el kompilita defaŭlta aro. La defaŭlta aro estas intence malnova: DES kaj 3DES por ĉifrado, MD5 kaj SHA1 por hakado, grupoj 1 kaj 2 por la ŝlosilinterŝanĝo, antaŭe dividitaj ŝlosiloj por aŭtentigo. Neniu AES, neniu SHA-2, neniu grupo 14. Pordego agordita por AES-256 kun SHA-256 kaj modp2048 dividas nenion kun ĝi.

Kelkaj realigoj respondas al neakordigita sondado per sciigo NO-PROPOSAL-CHOSEN. Aliaj simple forĵetas ĝin, kio oftas ĉe aparatoj, kiuj traktas nekonatajn partnerojn kiel bruon. Ĉiel ajn la skanado presas nenion, kaj tiu nenio identas al tio, kiel filtrata UDP 500 aspektas de ekstere, kiel la dokumentaro de la projekto ike-scan klare montras pri la defaŭlta aro.

Paŝo 2: proponu unu modernan proponon

Anstataŭigu la defaŭltan aron per --trans. La atributa formo prenas la numerojn de IKE-atributoj rekte: 1 por ĉifrado, 2 por hako, 3 por aŭtentigo, 4 por la grupo, kaj 14 por ŝlosillongo kiam la algoritmo prenas unu. Tio, kio eliras, estas linio, kiun vi povas laŭtlegi en ŝanĝa revizio.

La pozicia formo portas la samajn valorojn en ordo kaj evitas krampojn, kio gravas kiam la komando vojas tra ŝelo.

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

Unu propono por paketo estas malrapida kiam vi listigas, do trairu la verŝajnajn valorojn: ĉifrado 5, 7/128, 7/192, 7/256; hako 1, 2, 5, 6, 7; grupoj 1, 2, 5, 14, 15, 19, 20, 21; aŭtentigo 1 por antaŭe dividita ŝlosilo kaj 3 por RSA-subskriboj. Presu ĉiun komandon antaŭ ol ruli ĝin, por ke la protokolo montru, kion kaj en kiu ordo oni proponis.

Paŝo 3: interpretu respondon

Respondo pruvas precize du aferojn: IKE-respondanto atingeblas ĉe tiu adreso, kaj unu proponita propono estis akceptebla. Ĝi diras nenion pri la antaŭe dividita ŝlosilo, la L2TP-tavolo, aŭ ĉu ekzistas uzantkonto. Sukcesa skanado tute kongruas kun la malsukceso de ĉiu posta etapo.

Sur pordego, kiun vi administras, ĉi tio estas la vere utila parto. La skanado diras al vi, kiujn proponojn la aparato ankoraŭ akceptas, kaj rezulto limigita al malnovaj transformoj estas konstato pri aparatpolitiko, ne kialo malfortigi la klienton.

Paŝo 4: interpretu silenton

Silento estas pli malforta pruvo ol ĝi aspektas. Ĉiu propono eble estis rifuzita, UDP 500 kaj 4500 eble estas filtritaj, la fonto eble estas rapidlimigita post eksplodo, aŭ la servo eble aŭskultas ĉe alia adreso ol tiu, kiun vi skanis. Komparu la IKE-protokolon de la pordego kun kliento, kiu jam konektiĝas per validaj legitimiloj, antaŭ ol vi konkludos ion pri la skatolo.

Eksploda konduto apartenas al tiu listo, ĉar listigo generas multajn paketojn en mallonga fenestro. Pordego, kiu respondas la unuajn provojn kaj poste silentas, priskribas sian kontraŭ-DoS politikon anstataŭ sian proponaron.

Paŝo 5: notu, kion vi pruvis

Skribu la akceptitan kombinaĵon apud la firmvara versio, poste komparu ĝin kun la transformoj, kiujn la klientoj, kiuj gravas al vi, proponas defaŭlte. La breĉo inter tiuj du listoj estas la agorda problemo, kaj la skanado nur igis ĝin videbla. Se la solaj akceptitaj proponoj estas tiaj, kiujn vi ne elektus, la korekto apartenas al la pordega politiko aŭ al klienta profilo, neniam al la sondado.

Sondado, kiu neniam respondis, tamen respondis ion: ĝi montras, pri kiuj proponoj ĉi tiu aparato pretas diskuti, kaj kiujn ĝi prefere lasus fali sur la plankon.