Ідентифікатор IKE чи адреса кінцевої точки: не плутайте їх
Ідентифікатор IKE типу FQDN — це буквальне значення автентифікації, а не зворотний запит DNS. Тримайте окремо адресу кінцевої точки, локальний ідентифікатор і очікуваного peer.
Читайте поле з позначкою «ідентифікатор FQDN» як буквальний рядок, а не як запит зворотного DNS-імені вашої публічної адреси. У парсері strongSwan це саме так, рядок, і читання ніколи не перетворює його на кінцеву точку. Уже цей факт прибирає найпоширеніше відволікання під час вибору ідентифікаторів для peer. Перевірки нижче не дають трьом задіяним значенням злитися в одне.
Позначка — це не пошук
Інтерфейси постачальників вільно вживають слова на кшталт FQDN і hostname, а позначка на коробці нічого не каже про кодування за нею. Пристрій, який називає поле Client FQDN, може надіслати FQDN, рядок у формі електронної пошти або голий адрес. Ставтеся до тексту й типу як до двох окремих рішень і фіксуйте обидва.
Ніщо в буквальному ідентифікаторі не потребує DNS. Це твердження, яке перевіряє інший бік, а не ім'я, яке має розв'язати мережа.
Три окремі значення, записані окремо
За одним екраном конфігурації стоять три завдання, і їх злиття — дорога помилка. Одне значення — адреса кінцевої точки, яка вирішує, куди йдуть пакети. Друге — локальний ідентифікатор, який пред'являє цей peer, а третє — ідентифікатор, який ви очікуєте від далекого боку, перш ніж автентифікувати його. Запишіть їх трьома рядками в тікеті зміни, бо все менше описує VPN, а не стосунки.
| 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 |
Прикладні ідентифікатори треба вибрати й авторизувати як частину розгортання. Це твердження, які перевіряє автентифікація, а не облікові дані, що роблять будь-який peer довіреним, тому правдоподібний рядок нічого не авторизує.
Тип — частина значення
довідник ідентифікаторів strongSwan розділяє FQDN, значення у формі електронної пошти, IP-адреси та інші кодування, тому кодування важливе так само, як символи. Два пристрої можуть прийняти один і той самий текст під різними типами і все одно відмовити одне одному. Нотатка, яка фіксує значення без його типу, — половина конфігурації.
Запитайте постачальника, який тип пристрій справді надсилає, і підтвердьте це декодуванням, а не позначкою інтерфейсу. Угаданий тип — це невідповідність, що чекає наступної зміни.
Кожен бік має задовольнити інший
Локальний ідентифікатор кожного боку має пройти політику автентифікації іншого боку. Це не те саме, що вставити один рядок у кожне поле ідентифікатора на обох пристроях, — така коротка дорога дає конфігурацію, яку ніхто не зможе налагодити.
Автентифікація за сертифікатом додає власні вимоги, бо ідентифікатор сертифіката й умови довіри стоять поруч із введеним вами ідентифікатором IKE. Одного збігу ідентифікатора IKE не досить, щоб авторизувати peer із сертифікатом.
Де важливий DNS і що нав'язує ваша версія
Ім'я хоста шлюзу, яке використовується для виявлення, справді потребує робочого DNS, і ця вимога стосується пошуку кінцевої точки, а не якогось зворотного запиту введеного ідентифікатора. Тримайте ці дві речі в тікеті окремо, бо збій виявлення й невідповідність ідентифікатора читаються в журналі клієнта схоже і виправляються в різних місцях.
Прочитайте парсер того продукту й тієї версії, які ви справді запускаєте, перш ніж копіювати синтаксис, що нав'язує тип, бо старі випуски strongSwan поводилися інакше, а інші постачальники додають свої обмеження. Порівнюючи два кінці, тримайте разом чотири речі: очікуваний ідентифікатор, пред'явлений ідентифікатор, тип і помилку автентифікації. Цей набір перетворює невідповідність на доказ, а не на думку.