Идентификатор 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 се държаха различно, а други доставчици добавят свои ограничения. Когато сравнявате двата края, дръжте четири неща заедно: очакван идентификатор, представен идентификатор, тип и грешката при удостоверяване. Този набор превръща несъответствието в доказателство, а не в мнение.