Jūsų sertifikatas susietas su patikima CA, datos tvarkingos, o partneris vis tiek atsisako užbaigti 1 etapą su tapatybės klaida. Pasiekiamumas ir galiojantis parašas yra tik pusė to, ką tikrina IKEv2 klientas. Kita pusė – ar laukiama tapatybė sertifikate rodoma tinkamame lauke, ir tą lūkestį nustato profilis, o ne sertifikato failo pavadinimas.

Simptomas visada tos pačios formos

Ryšio profilis pakeičiamas iš prieglobos vardo į IP adresą arba atnaujinamas iš sertifikato, kuriame buvo DNS vardas, į sertifikatą, kuriame yra tik adresai, irtunelis nustoja derėtis. Tinklo kelyje niekas nepasikeitė. Klientas pasiekia partnerį, gauna sertifikatą ir atmeta partnerio tapatybę, nes identifikatorius, kurio buvo liepta laukti, nėra pavaizduotas lauke, kurį jis priima. Atnaujinimai yra įprasta priežastis, nes pakeitimo sertifikatas dažnai gaunamas iš kitokio šablono nei tas, kurį jis pakeičia.

Tada abi pusės įrašo ką nors nenaudingo, todėl gedimas paprastai pateikiamas kaip sertifikato problema. Kliento žurnale gali būti nurodyta norima tapatybė, ir tas vardas yra užuomina, kurios jums reikia, o ne galiojimo pabaigos data.

Suderinkite identifikatoriaus tipą, ne tik reikšmę

dNSName SAN ir iPAddress SAN yra skirtingi laukai su skirtingomis atitikimo taisyklėmis, todėl sertifikatas, kuriame 203.0.113.10 yra DNS eilutė, netenkina kliento, laukiančio IP tapatybės. Šiuolaikiniai tikrintuvai iš esmės nepaiso bendrojo vardo, todėl draugiška etiketė sertifikato informacijoje nieko neįrodo apie tai, kas atitiks. Jei trikčių šalinimo metu prieglobos vardas buvo pakeistas adresu, manykite, kad laukiama tapatybė persikėlė kartu su juo, kol nepatikrinote. Palyginkite profilio eilutę su SAN eilute po ženklą, nes baigiamasis taškas ar atsitiktinis tarpas yra pakankami.

Pakaitos simboliai yra tik DNS patogumas ir laikosi savo atitikimo taisyklių, o tai dar viena priežastis, kodėl IP pagrįstas profilis niekada neturėtų jais pasikliauti.

Raskite, kur kiekvienas klientas saugo lūkestį

strongSwan atveju reikšmė, lyginama su sertifikatu, gaunama iš partnerio tapatybės nustatymo: rightid klasikinėje konfigūracijoje, arba id nuotolinio ryšio sekcijos id swanctl. Jo dokumentacija apie Apple IKEv2 sąveiką čia naudinga, nes išdėsto tapatybės konvencijas, kurias naudoja profilio valdomas klientas, ir šios konvencijos paaiškina neatitikimų klasę, kuri tinkle atrodo atsitiktinė.

Apple konfigūracijos profiliuose yra nuotolinio identifikatoriaus laukas, ir būtent ten esančią reikšmę klientas tikrina, o ne serverio adresą ryšio nustatymuose. Windows ir įrenginių klientai turi savo lauką su savo numatytąja reikšme, o numatytoji dažnai seka jūsų įvestą adresą. Kai du laukai nesutaria, laimi tas, kurį klientas iš tikrųjų skaito, ir tai retai būna tas, kurį redagavote.

Taisykite profilį arba sertifikatą, sąmoningai

Prieš ką nors keisdami, patikrinkite partnerio sertifikatą patvirtintais įrankiais ir išvardykite SAN įrašus su jų tipais. Šiai patikrai nereikia privataus rakto ir įkėlimo, ir ji per kelias sekundes išsprendžia klausimą. Jei diegimas numato vieną DNS tapatybę, sertifikatas turi ją turėti kaip dNSName įrašą, o jei diegimas numato adresą, sertifikatui reikia iPAddress įrašo būtent tam adresui.

Kai sertifikatas neteisingas, paprašykite operatoriaus pataisyto su konkrečiu laukiamu identifikatoriumi. Kai profilis neteisingas, pataisykite profilį ir palikite sertifikatą ramybėje. Išjungus tapatybės tikrinimą klaida išnyksta ir pašalinama patikra, kad tunelis kalba su numatytu partneriu.

Dokumentuokite laukiamą tapatybę kiekvienai kliento platformai, nes reikšmę, kurią vienas klientas išveda automatiškai, kitame gali reikėti nurodyti aiškiai.

Pateikite atnaujinimo prašymui keturis faktus

Užrašykite laukiamą identifikatorių ir jo tipą, SAN įrašus, kuriuos dabartinis sertifikatas iš tikrųjų turi, klientą ir versiją, atliekančius patikrą, ir tikslų klaidos tekstą. Iš šių keturių eilučių sudarytas atnaujinimo prašymas pirmą kartą gauna tinkamą sertifikatą, o ne dar vieną su tuo pačiu pažįstamu failo pavadinimu.

Susiję straipsniai