Ідэнтыфікатар 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 паводзілі сябе інакш, а іншыя пастаўшчыкі дадаюць свае абмежаванні. Параўноўваючы два канцы, трымайце разам чатыры рэчы: чаканы ідэнтыфікатар, прад'яўлены ідэнтыфікатар, тып і памылку аўтэнтыфікацыі. Гэты набор ператварае неадпаведнасць у доказ, а не ў меркаванне.