IKE-identiteit of eindpuntadres: moenie dit verwar nie
'n IKE-identiteit van die FQDN-tipe is 'n letterlike verifikasiewaarde, nie 'n reverse-DNS-soektog nie. Hou die eindpuntadres, die plaaslike identiteit en die verwagte peer apart.
Lees 'n veld met die etiket FQDN-identiteit as 'n letterlike string, nie as 'n versoek om die reverse-DNS-naam van jou openbare adres nie. In strongSwan se ontleder is dit presies dit, 'n string, en om dit te lees los dit nooit na 'n eindpunt op nie. Daardie feit alleen verwyder die mees algemene afleiding wanneer jy identificerings vir 'n peer kies. Die kontroles hieronder verhoed dat die drie betrokke waardes in een saamsmelt.
'n Etiket is nie 'n soektog nie
Verkopers se koppelvlakke gebruik woorde soos FQDN en hostname losweg, en die etiket op 'n boks sê niks oor die enkodering daaronder nie. 'n Toestel wat 'n veld Client FQDN noem, kan 'n FQDN, 'n e-posvormige string of 'n kaal adres stuur. Behandel die teks en die tipe as twee afsonderlike besluite, en teken albei aan.
Niks aan 'n letterlike identiteit vereis DNS nie. Dit is 'n bewering wat die ander kant nagaan, nie 'n naam wat die netwerk moet oplos nie.
Drie aparte waardes, apart geskryf
Drie take sit agter een konfigurasieskerm, en om hulle te vermeng is die duur fout. Een waarde is die eindpuntadres, wat bepaal waarheen pakkette gaan. 'n Ander is die plaaslike identiteit wat hierdie peer voorhou, en die derde is die identiteit wat jy van die ander kant verwag voordat jy dit verifieer. Skryf hulle as drie reëls in die veranderingsticket, want enigiets minder beskryf 'n VPN eerder as 'n verhouding.
| Job | Example | What it decides |
|---|---|---|
| Where the packets go | 198.51.100.7 | The endpoint address |
| What this peer claims | gw.branch.internal | The local IKE identity |
| Who should answer | ike.hub.internal | The expected remote identity |
Die voorbeeldidentiteite moet as deel van die ontplooiing gekies en gemagtig word. Hulle is bewerings wat verifikasie nagaan, nie geloofsbriewe wat enige peer betroubaar maak nie, so 'n geloofwaardig-voorkomende string magtig niks.
Die tipe is deel van die waarde
Die strongSwan-identiteitsverwysing skei FQDN, e-posvormige waardes, IP-adresse en ander enkoderings, so die enkodering maak net so saak soos die karakters. Twee toestelle kan identiese teks onder verskillende tipes aanvaar en mekaar steeds weier. 'n Nota wat die waarde sonder sy tipe aanteken, is 'n halwe konfigurasie.
Vra die verkoper watter tipe die toestel werklik stuur, en bevestig dit teen 'n dekodeer eerder as die koppelvlaketiket. 'n Gerade tipe is 'n wanpassing wat op die volgende verandering wag.
Elke kant moet die ander bevredig
Elke kant se plaaslike identiteit moet die ander kant se verifikasiebeleid slaag. Dit is nie dieselfde as om een string in elke identiteitsblokkie op beide toestelle te plak nie; daardie kortpad lewer 'n konfigurasie wat niemand kan ontfout nie.
Sertifikaatverifikasie voeg sy eie vereistes by, want die sertifikaat se identiteit en die vertrouensvoorwaardes staan langs die IKE-identiteit wat jy getik het. 'n Ooreenstemmende IKE-identiteit alleen magtig nie 'n sertifikaat-peer nie.
Waar DNS saak maak, en wat jou weergawe afdwing
'n Gateway-hostname wat vir ontdekking gebruik word, het wel werkende DNS nodig, en daardie vereiste hoort by die vind van die eindpunt, nie by enige reverse-soektog van 'n getikte identiteit nie. Hou die twee apart in die ticket, want 'n ontdekkingsfout en 'n identiteitswanpassing lees soortgelyk in 'n kliëntlog en word op verskillende plekke herstel.
Lees die ontleder vir die produk en weergawe wat jy werklik gebruik voordat jy sintaksis kopieer wat 'n tipe afdwing, want ouer strongSwan-weergawes het anders opgetree en ander verkopers voeg hul eie beperkings by. Wanneer jy die twee kante vergelyk, hou vier dinge saam: verwagte identiteit, voorgehoue identiteit, tipe en die verifikasiefout. Daardie stel maak 'n wanpassing bewyse eerder as 'n mening.