IKEv2 cyfeiriad gweinydd yn erbyn hunaniaeth: yr hyn y mae'r cleient yn ei wirio mewn gwirionedd
Mae'r cyfeiriad yn dweud ble i ddeialu; mae'r hunaniaeth yn dweud pa gyfoed i'w dderbyn. Eu cymysgu yw pam mae porth wedi'i symud neu dystysgrif newydd yn torri IKEv2.
Gall porth sy'n newid cyfeiriad barhau i weithio tra bod yr un porth y tu ôl i dystysgrif newydd yn dod i ben, ac mae'r gwrthwyneb yn digwydd hefyd. Mae'r cyfeiriad yn dweud wrth y cleient ble i anfon pecynnau; mae'r hunaniaeth ddilys yn dweud wrth y cleient ai'r ateb gan gymheiriaid yw'r un y dylai ymddiried ynddo. Mae IKEv2 yn cadw'r rhain fel dau faes ar wahân, sy'n ddefnyddiol unwaith y byddwch yn rhoi'r gorau i'w trin fel un llinyn. Maent hefyd wedi'u ffurfweddu mewn gwahanol leoedd, felly gall un fod yn gywir tra bod y llall yn anghywir.
Gwiriwch nhw yn y drefn hon a stopiwch ar yr anghydweddiad cyntaf, oherwydd mae'r gwiriadau diweddarach yn tybio bod y rhai cynharach wedi'u pasio.
Yn gyntaf, pa werth yw'r cyfeiriad
Y cyfeiriad cysylltiad yw beth bynnag mae'r cleient yn ei ddeialu: IP, enw DNS sy'n cydbwyso i un, neu ben blaen sy'n gytbwys o ran llwyth. Gwybodaeth am drafnidiaeth yw hynny a dim byd arall. Mae'r hunaniaeth yn rhedeg yn y llwyth tâl ID IKEv2 ac yna'n cael ei baru â thystysgrif y cymar. Nid yw enw DNS yn y blwch cyfeiriad yn dod yn hunaniaeth ddisgwyliedig, ac nid yw IP crai yn dod yn hunaniaeth dim ond oherwydd bod y soced yn gysylltiedig ag ef.
Yn nhermau strongSwan, y cyfeiriad yw right neu left, a'r hunaniaeth ddisgwyliedig yw rightid neu leftid, a dyna mae dogfennaeth ffurfweddu IKEv2 yn ei ddisgrifio. Os mai dim ond y cyfeiriad rydych chi erioed wedi'i olygu, rydych chi wedi ffurfweddu hanner y pâr.
Yn ail, yr hyn y gall y dystysgrif ei brofi
Mae gan yr hunaniaeth fath, ac mae'n rhaid i'r dystysgrif gynnwys enw cyfatebol. Mae hunaniaeth DNS yn cael ei bodloni gan gofnod dNSName yn yr estyniad enw amgen gwrthrychol; mae angen cofnod iPAddress ar hunaniaeth IP. Nid yw tystysgrif a roddwyd ar gyfer vpn.example.com yn profi dim am y cyfeiriad llythrennol 203.0.113.10, ac nid yw un a roddwyd ar gyfer y cyfeiriad hwnnw yn profi dim am yr enw. Felly nid yw ailgyhoeddi ar gyfer enw gwahanol yn rhywbeth galw heibio, hyd yn oed pan fydd yr un allwedd a CA yn cael eu hailddefnyddio.
Mae cleientiaid modern yn anwybyddu'r enw cyffredin pan fo enw amgen pwnc yn bodoli, ac mae llawer yn ei anwybyddu'n llwyr. Os nad yw'r rhestr SAN yn cynnwys y gwerth y mae'r cleient yn ei wirio, mae'r ysgwyd llaw yn methu ar ôl i'r dystysgrif gael ei derbyn eisoes fel un y gellir ymddiried ynddi, a dyna pam mae'r log yn darllen fel gwall hunaniaeth yn hytrach na gwall ymddiried.
Yn drydydd, sut mae pob cleient yn datgan y disgwyliad
Mae Windows yn cymryd enw'r gweinydd neu'r cyfeiriad a deipiwyd gennych ac mae angen y dystysgrif i gyd-fynd ag ef, felly mae teipio IP yn creu disgwyliad IP. Mae cleient Android IKEv2 yn ymddwyn yr un ffordd, ac mae'r ddau yn gwrthod tystysgrif ddilys y gellir ymddiried ynddi'n gyhoeddus sy'n enwi gwesteiwr gwahanol. Gall proffil ddechrau methu dim ond oherwydd bod rhywun wedi disodli'r enw gwesteiwr gyda'i gyfeiriad yn ystod mudo. Edrychwch ar yr hyn y gofynnodd y cleient amdano cyn i chi edrych ar gynnwys y dystysgrif.
Ar strongSwan mae'r disgwyliad yn eglur: gosodwch rightid i'r hunaniaeth y mae'r gweinydd yn ei gyflwyno mewn gwirionedd, a all fod yn wahanol i'r dde. Mae ei osod i %any yn derbyn beth bynnag mae'r cyfoed yn ei gynnig ac yn dileu'r union siec rydych chi'n ceisio'i chadw.
Yn bedwerydd, mewngofnodi defnyddiwr ar wahân i hunaniaeth cyfoedion
EAP dilysu a hunaniaeth y gweinydd yn ateb cwestiynau gwahanol. Mae hunaniaeth EAP fel [email protected] yn dweud pwy yw'r defnyddiwr, ar ôl i'r cleient benderfynu mai'r gweinydd yw'r un cywir. Ni all cylchdroi'r cyfrinair hwnnw gywiro diffyg cyfatebiaeth hunaniaeth cyfoedion, oherwydd nid yw'r cysylltiad byth yn cyrraedd y cam mewngofnodi defnyddiwr.
Dylai adroddiad glanweithiol enwi'r ddau: yr hunaniaeth roedd y cleient yn ei ddisgwyl, yr hunaniaeth a gyflwynwyd gan y gweinydd, a chofnodion SAN y dystysgrif.
Yn bumed, newidiwch ef trwy sianel wedi'i dilysu
Pan fydd y porth yn symud yn gyfreithlon, diweddarwch y cyfeiriad yn gyntaf a gadewch llonydd i'r hunaniaeth, oherwydd dyna'r achos IKEv2 yn ymdrin yn dda. Pan fydd yr hunaniaeth ei hun yn newid, dylech ei drin fel digwyddiad ymddiriedaeth a chael y gwerth newydd o ffynhonnell yr ydych eisoes yn ymddiried ynddi, nid o'r pwynt terfyn sy'n methu ar hyn o bryd. Nid yw neges a gyflwynir dros y cysylltiad rydych yn ceisio ei ddilysu yn dystiolaeth o'r cysylltiad hwnnw.
Cofnodwch y cyfeiriad terfynol, hunaniaeth a SAN rhestr gyda'i gilydd yn y nodiadau proffil. Bydd y person nesaf i gyffwrdd â'r dystysgrif wedyn yn gweld pa un o'r tri sy'n cael symud.