IKE-identeco aŭ finpunkta adreso: ne konfuzu ilin
IKE-identeco de tipo FQDN estas laŭvorta aŭtentiga valoro, ne malantaŭa DNS-serĉo. Tenu aparte la finpunktan adreson, la lokan identecon kaj la atendatan peer.
Legu kampon etikeditan kiel FQDN-identeco kiel laŭvortan ĉenon, ne kiel peton por la malantaŭa DNS-nomo de via publika adreso. En la analizilo de strongSwan ĝi estas ĝuste tio, ĉeno, kaj legado neniam solvas ĝin al finpunkto. Tiu fakto sola forigas la plej kutiman distron kiam vi elektas identigilojn por peer. La subaj kontroloj malhelpas, ke la tri koncernaj valoroj fandu en unu.
Etikedo ne estas serĉo
Interfacoj de vendistoj uzas vortojn kiel FQDN kaj hostname malstrikte, kaj la etikedo sur skatolo nenion diras pri la kodigo malantaŭ ĝi. Aparato, kiu nomas kampon Client FQDN, povas sendi FQDN, ĉenon en retpoŝta formo aŭ nudan adreson. Traktu la tekston kaj la tipon kiel du apartajn decidojn kaj registru ambaŭ.
Nenio en laŭvorta identeco postulas DNS. Ĝi estas aserto, kiun la alia flanko kontrolas, ne nomo, kiun la reto devas solvi.
Tri apartaj valoroj, aparte skribitaj
Tri taskoj kaŝiĝas malantaŭ unu agorda ekrano, kaj kunfandi ilin estas la kosta eraro. Unu valoro estas la finpunkta adreso, kiu decidas, kien la pakaĵoj iras. Alia estas la loka identeco, kiun ĉi tiu peer prezentas, kaj la tria estas la identeco, kiun vi atendas de la malproksima flanko antaŭ ol aŭtentigi ĝin. Skribu ilin kiel tri liniojn en la ŝanĝa bileto, ĉar io ajn malpli priskribas VPN anstataŭ rilaton.
| 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 |
La ekzemplaj identecoj devas esti elektitaj kaj rajtigitaj kiel parto de la deplojo. Ili estas asertoj, kiujn aŭtentigo kontrolas, ne legitimiloj, kiuj igas iun ajn peer fidinda, do ŝajne kredinda ĉeno rajtigas nenion.
La tipo estas parto de la valoro
La identeca referenco de strongSwan apartigas FQDN, retpoŝtformajn valorojn, IP-adresojn kaj aliajn kodigojn, do la kodigo gravas same kiel la signoj. Du aparatoj povas akcepti identan tekston sub malsamaj tipoj kaj tamen rifuzi unu la alian. Noto, kiu registras la valoron sen sia tipo, estas duona agordo.
Demandu la vendiston, kiun tipon la aparato efektive sendas, kaj konfirmu ĝin per malkodigo anstataŭ per la interfaca etikedo. Divenita tipo estas maltrafiĝo atendanta la sekvan ŝanĝon.
Ĉiu flanko devas kontentigi la alian
La loka identeco de ĉiu flanko devas trapasi la aŭtentigan politikon de la alia flanko. Tio ne estas la samo kiel enmeti unu ĉenon en ĉiun identecan kampon sur ambaŭ aparatoj, kio estas la fuĝvojo, kiu produktas agordon, kiun neniu povas sencimigi.
Atestila aŭtentigo aldonas proprajn postulojn, ĉar la identeco de la atestilo kaj la fidaj kondiĉoj staras apud la IKE-identeco, kiun vi tajpis. IKE-identeca kongruo sola ne rajtigas atestilan peer.
Kie DNS gravas, kaj kion via versio devigas
Enireja hostname uzata por malkovro ja bezonas funkciantan DNS, kaj tiu postulo apartenas al trovo de la finpunkto, ne al iu malantaŭa serĉo de tajpita identeco. Tenu la du aparte en la bileto, ĉar malkovra fiasko kaj identeca maltrafiĝo legiĝas simile en klienta protokolo kaj ripariĝas en malsamaj lokoj.
Legu la analizilon por la produkto kaj versio, kiujn vi efektive funkciigas, antaŭ ol kopii sintakson, kiu devigas tipon, ĉar pli malnovaj eldonoj de strongSwan kondutis alie kaj aliaj vendistoj aldonas proprajn limigojn. Kiam vi komparas la du finojn, tenu kvar aferojn kune: atendata identeco, prezentata identeco, tipo kaj la aŭtentiga eraro. Tiu aro igas maltrafiĝon pruvo anstataŭ opinio.