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 понашала другачије, а други произвођачи додају своја ограничења. Када поредите два краја, држите четири ствари заједно: очекивани идентитет, представљени идентитет, тип и грешку провере аутентичности. Тај скуп претвара неспоразум у доказ уместо у мишљење.