IKEv2 bedieneradres vs identiteit: wat die kliënt eintlik kontroleer

'n Hek wat van adres verander, kan aanhou werk terwyl dieselfde poort agter 'n nuwe sertifikaat stop, en die omgekeerde gebeur ook. Die adres vertel die kliënt waarheen om pakkies te stuur; die geverifieerde identiteit vertel die kliënt of die eweknie-antwoord die een is wat hy moet vertrou. IKEv2 hou dit as twee aparte velde, wat nuttig is sodra jy ophou om hulle as een string te behandel. Hulle is ook op verskillende plekke gekonfigureer, so een kan korrek wees terwyl die ander verkeerd is.

Kontroleer hulle in hierdie volgorde en stop by die eerste wanpassing, want die latere tjeks neem aan dat die voriges geslaag is.

Eerstens, watter waarde is die adres

Die verbindingsadres is wat die kliënt ook al skakel: 'n IP, 'n DNS naam wat na een oplos, of 'n lasgebalanseerde voorkant. Dit is vervoerinligting en niks meer nie. Die identiteit ry in die IKEv2 ID-loonvrag en word dan met die eweknie se sertifikaat gekoppel. 'n DNS naam in die adreskassie word nie die verwagte identiteit nie, en 'n rou IP word nie die identiteit net omdat die sok daaraan gekoppel is nie.

In strongSwan terme is die adres right of left, en die verwagte identiteit is rightid of leftid, en dit is wat die IKEv2 konfigurasiedokumentasie beskryf. As jy net ooit die adres gewysig het, het jy die helfte van die paar gekonfigureer.

Tweedens, wat die sertifikaat kan bewys

Die identiteit het 'n tipe, en die sertifikaat moet 'n bypassende naam dra. 'n DNS identiteit word bevredig deur 'n dNSName inskrywing in die onderwerp alternatiewe naamuitbreiding; 'n IP-identiteit benodig 'n iPAddress-inskrywing. 'n Sertifikaat uitgereik vir vpn.example.com bewys niks oor die letterlike adres 203.0.113.10, en een wat vir daardie adres uitgereik is bewys niks oor die naam nie. Heruitreiking vir 'n ander naam is dus nie 'n inloop-vervanging nie, selfs wanneer dieselfde sleutel en CA hergebruik word.

Moderne kliënte ignoreer die algemene naam wanneer 'n onderwerp alternatiewe naam bestaan, en baie ignoreer dit heeltemal. As die SAN lys nie die waarde bevat wat die kliënt nagaan nie, misluk die handdruk nadat die sertifikaat reeds as betroubaar aanvaar is, en daarom lees die log soos 'n identiteitsfout eerder as 'n vertrouensfout.

Derdens, hoe elke kliënt die verwagting stel

Windows neem die bedienernaam of adres wat jy getik het en vereis dat die sertifikaat daarby pas, dus skep 'n IP-verwagting 'n IP-verwagting. Android se IKEv2 kliënt tree op dieselfde manier op, en albei verwerp 'n geldige, publiek vertroude sertifikaat wat 'n ander gasheer benoem. 'n Profiel kan begin misluk bloot omdat iemand die gasheernaam met sy adres vervang het tydens 'n migrasie. Kyk wat die kliënt gevra het voordat jy kyk wat die sertifikaat bevat.

Op strongSwan is die verwagting eksplisiet: stel rightid op die identiteit wat die bediener werklik aanbied, wat van regs kan verskil. As jy dit op %any stel, word alles aanvaar wat die eweknie bied en verwyder presies die tjek wat jy probeer hou.

Vierdens, skei gebruikersaanmelding van eweknie-identiteit

EAP verifikasie en die bedieneridentiteit beantwoord verskillende vrae. 'n EAP identiteit soos [email protected] sê wie die gebruiker is, nadat die kliënt besluit het dat die bediener die regte een is. Om daardie wagwoord te draai, kan nie 'n eweknie-identiteit-wanpassing regstel nie, want die verbinding bereik nooit die gebruiker-aanmeldstadium nie.

'n Gesaneerde verslag moet beide noem: die identiteit wat die kliënt verwag het, die identiteit wat die bediener aangebied het, en die sertifikaat se SAN inskrywings.

Vyfdens, verander dit deur 'n geverifieerde kanaal

Wanneer die poort regmatig beweeg, werk eers die adres op en laat die identiteit uit, want dit is die geval IKEv2 hanteer goed. Wanneer die identiteit self verander, hanteer dit as 'n vertrouensgebeurtenis en kry die nuwe waarde van 'n bron wat jy reeds vertrou, nie van die eindpunt wat tans misluk nie. 'n Boodskap wat oor die verbinding gelewer word wat jy probeer valideer, is nie 'n bewys oor daardie verbinding nie.

Teken die finale adres, identiteit en SAN lys saam in die profielnotas aan. Die volgende persoon wat aan die sertifikaat raak, sal dan sien wie van die drie mag beweeg.