Sut mae dilysu hybrid IKEv1 yn troi'n ddilysu defnyddwyr IKEv2

Mae pob proffil VPN hen sy'n gofyn am dystysgrif gweinydd ac wedyn am enw defnyddiwr yn cario dau ddigwyddiad dilysu mewn un cyfnewidiad, ac mae'r siâp hwnnw'n byw'n hirach na'r protocol a'i cyflwynodd. Adeiladwyd modd hybrid IKEv1 yn union ar gyfer hyn: mae'r porth yn profi ei hun gyda allwedd gyhoeddus tra bod y defnyddiwr yn profi ei hun yn ddiweddarach trwy XAuth. Mae IKEv2 yn mynegi'r un syniad dau gam gyda mecanwaith gwahanol, ac yn y gwahaniaethau hynny y mae mudo yn methu. Nid oes unrhyw rif fersiwn yn troi'r naill yn y llall, ac mae copïo'r hen enwau opsiynau i broffil newydd yn rhoi cleient sy'n trafod ac wedyn yn dilysu dim.

Beth wnaeth y modd hybrid y tu mewn i IKEv1

Mewn proffil hybrid mae'r ochr sy'n ateb yn llofnodi cyfnewidiad y cam cyntaf gyda'i thystysgrif tra nad yw'r cychwynnydd yn cyflwyno'r un o gwbl o fwriad. Mae prawf hunaniaeth felly'n anghymesur, a dyna a alluogodd borth i gadw ei PKI presennol tra bod defnyddwyr yn cadw eu cyfrineiriau cyfeiriadur. Pan fydd y cam cyntaf wedi'i gwblhau, mae XAuth yn rhedeg fel cais ac ateb sy'n cario priodoleddau enw defnyddiwr a chyfrinair y tu mewn i sianel ISAKMP sydd bellach wedi'i hamgryptio.

Sylwch ble mae'r ymddiriedaeth yn glanio. Mae'r dystysgrif yn ateb pa borth y cyrhaeddodd y cleient; mae XAuth yn ateb pa ddefnyddiwr sydd eisiau mynediad. Nid yw'r naill yn disodli'r llall, ac mae cleient sydd wedi'i osod i dderbyn unrhyw dystysgrif gweinydd wedi taflu'r ateb cyntaf yn dawel. Defnyddir y label hybrid hefyd ar gyfer modd ymosodol ag allwedd a rannwyd ymlaen llaw ynghyd ag XAuth, trefniant arall gyda'r un profiad defnyddiwr, felly darllenwch y proffil ac nid yr enw. Daw'r ddau amrywiolyn o ddrafftiau na ddaethant yn safonau erioed, a dyna pam y gall dau wneuthurwr weithredu modd hybrid a pheidio â rhyngweithio ag unrhyw un.

Sut mae IKEv2 yn cyrraedd yr un ddau brawf

Mae IKEv2 yn rhannu'r gwaith rhwng IKE_SA_INIT ac IKE_AUTH. Mae'r cyfnewidiad cyntaf yn cytuno ar gynigion ac allweddi heb unrhyw hunaniaeth o gwbl; mae'r ail yn cario IDi, IDr a llwythi AUTH. O dan EAP mae llwyth AUTH cyntaf y cychwynnydd yn mynd allan yn wag, mae'r ochr sy'n ateb yn dilysu ei hun yn gyntaf gyda'i thystysgrif a'i llofnod, ac wedyn mae'r sgwrs EAP yn mynd rhagddi y tu mewn i negeseuon IKE_AUTH.

Y mecanwaith sy'n gwneud hyn yn ddiogel yw deunydd allwedd. Mae dull EAP llwyddiannus yn allforio allwedd sesiwn, ac mae llwyth AUTH olaf y cychwynnydd yn cael ei gyfrifo ohoni, felly mae prawf y defnyddiwr ac allweddi'r twnnel wedi'u clymu. Nid oes gan XAuth gyfwerth: mae ei briodoleddau'n cyrraedd ar ôl y cam cyntaf ac nid ydynt yn cyfrannu dim at yr allweddi. Y bwlch hwnnw yn union y cafodd fframwaith IKEv2 ei gynllunio i'w gau, a dyna pam mae mewngofnod IKEv2 sy'n gweithio yn dilysu tystysgrif y gweinydd cyn gofyn am unrhyw beth.

Mae'r drefn hon hefyd yn ddiagnosis defnyddiol. Pan fydd cleient yn cwyno am gymwysterau cyn dangos tystysgrif i chi, nid yw'n gwneud cyfnewidiad EAP IKEv2 o gwbl.

Cadwch dri hunaniaeth ar wahân

Mae mudo yn mynd o'i le pan fydd tair hunaniaeth yn cwympo i mewn i un maes. Mae hunaniaeth y porth y mae'r cleient yn ei dilysu, fel arfer enw DNS yn subject neu SAN y dystysgrif. Mae hunaniaeth y defnyddiwr a gyflwynir yn EAP, efallai mewngofnod parth, cyfeiriad neu linyn hunaniaeth EAP penodol. Ac mae ffynhonnell yr awdurdodiad sy'n mapio'r defnyddiwr hwnnw i rwydweithiau a llwybrau.

Mae cystrawen swanctl strongSwan yn gwneud y gwahanu yn weladwy: mae'r cysylltiad yn gosod remote { auth = pubkey } ar gyfer y porth a local { auth = eap-mschapv2 } ar gyfer y defnyddiwr, gyda'r hunaniaeth EAP yn cael ei chario ar wahân.

Pan fydd hunaniaeth y defnyddiwr yn y proffil newydd yn wahanol i briodoleddau XAuth yr hen, er enghraifft UPN yn lle enw byr, mae'r gweinydd dilysu yn gweld defnyddiwr anhysbys ac mae'r methiant yn edrych fel cyfrinair anghywir. Gwiriwch y llinyn hunaniaeth cyn gwirio'r cymwysterau.

Mapio'r opsiynau ac wedyn disgwyl y trapiau

Mae'r mapio yn fyr ac mae gan bob rhes drap sy'n ymddangos yn unig adeg dilysu.

Nid oes yr un o'r rhesi hynny yn ddim ond ailenwi. Mae llwyth y ffurfweddiad yn danfon cyfeiriadau a datryswyr trwy restr briodoleddau teipiedig, tra bod gofod priodoleddau XAuth yn ddyfais ei hun; eu trin fel rhai cyfnewidiadwy yw'r ffordd y mae proffil yn gorffen gofyn am osodiad na fydd y porth byth yn ei anfon.

Mae'r dewiswyr traffig yn haeddu eu rhybudd eu hunain. Roedd IKEv1 yn mynegi traffig o ddiddordeb trwy IDau dirprwy wedi'u clymu i gyfnewidiad quick mode, tra bod IKEv2 yn trafod y dewiswyr yn ystod IKE_AUTH a gall yr ochr sy'n ateb eu culhau. Mae anghydweddiad yn cynhyrchu IKE SA wedi'i sefydlu heb child SA, y mae rhai cleientiaid yn ei ddangos yn llawen fel un cysylltiedig.

Triniwch yr hen gysylltiad fel ffin

Mae RFC 9395 yn datgan IKEv1 yn hen ffasiwn, felly mae hen gysylltiad hybrid yn ffin gydnaws â dyddiad, nid sylfaen. Rhedwch y ddau broffil ochr yn ochr yn ystod y newid, oherwydd nid y prawf sy'n cyfrif yw a yw'r proffil newydd yn codi ond a yw'r un defnyddiwr ar yr un ddyfais yn cyrraedd yr un adnoddau.

Cadwch ddilysu tystysgrifau yn llym trwy'r amser. Unwaith y bydd y cleient yn rhoi'r gorau i gyflwyno ei dystysgrif ei hun, y temtasiwn yw lleddfu gwiriad y gweinydd nes bod yr ysgwyd llaw wedi gorffen, ac mae hynny'n cyfnewid yr unig brawf sydd ar ôl am eicon gwyrdd.

Ysgrifennwch bedair peth cyn ymddeol y hen broffil: y dull EAP, y llinyn hunaniaeth, ffynhonnell yr awdurdodiad a'r dyddiad y daw'r gefnogaeth i ben.