Профіль WireGuard для шлюза IPsec: пра што запытацца замест гэтага

Тайм-аўты рукапаціскання з маўклівым шлюзам звычайна азначаюць два пратаколы, якія ніколі не сустракаюцца. Пір WireGuard гаворыць на Noise, а шлюз IPsec чакае IKE. Правільны адрас і порт гэтага не змяняюць.

Паўторнае выкарыстанне канчатковай кропкі ў профілі не злучае іх. Наступны крок — запыт да таго, хто кіруе шлюзам.

Запыт першы: версія пратакола

IPsec называе сямейства, а не адзіны працэс. IKEv2 і IKEv1 адрозніваюцца сваімі абменамі, сваімі варыянтамі аўтэнтыфікацыі і паводзінамі пры змене сеткі. Шлюз, які завяршае толькі IKEv1, будзе паводзіць сябе зусім інакш, чым той, што прапануе IKEv2. Канфігурацыя кліента адрозніваецца разам з гэтым.

Запытайце, якую версію завяршае сэрвіс і ці выкарыстоўвае ён рэалізацыю на аснове стандартаў або варыянт пастаўшчыка з уласным кліентам. Меню аперацыйных сістэм часта хаваюць гэты адказ за адзінай пазнакай. Пазнака — не пратакол.

Запыт другі: метад аўтэнтыфікацыі кліента

Аўтэнтыфікацыя — гэта месца, дзе знаходзіцца большая частка рэальнай працы. Сэрвіс можа чакаць сертыфікат машыны з пэўным пашыраным выкарыстаннем ключа, сертыфікат карыстальніка, метад EAP праз IKEv2 або папярэдне агучаны ключ, прывязаны да ідэнтычнасці. Які менавіта — вызначае, што патрэбна кліенту.

Прыватны ключ WireGuard — нішто з гэтага. Гэта ключ Curve25519, які выкарыстоўваецца ў адным канкрэтным рукапацісканні. Ніякае пераўтварэнне не робіць з яго сертыфікат або ўліковыя даныя EAP. Інструмент, які сцвярджае адваротнае, пераназывае файл або стварае нешта незвязанае.

Спецыфікацыя IKEv2 у RFC 7296 апісвае, што павінна падтрымліваць рэалізацыя гэтай версіі. Гэта даведка для неакрэсленага адказу аператара, а не кіраўніцтва па канфігурацыі кліента.

Запыт трэці: давераная ідэнтычнасць і пункты прызначэння

Запытайце ідэнтычнасць шлюза такой, якой кліент павінен яе бачыць, плюс якар даверу, што яе правярае. Затым запытайце, якія прыватныя дыяпазоны і рэзалверы сэрвіс перадае. Гэтыя два адказы вызначаюць, што тунэль фактычна нясе.

Без іх працоўнае злучэнне ўсё роўна можа не выканаць задачу. Тунэль, які ўзняўся без перададзенага рэзалвера, пакідае ўнутраныя імёны без адказу. Адсутны селектар трафіку пакідае пункт прызначэння па-за тунэлем, нават калі рукапацісканне ўдалося.

Праверка канчатковай кропкі адказвае на іншае пытанне, чым памылка кліента. Дасягальны порт без асацыяцыі ўказвае на аўтэнтыфікацыю, а недасягальны порт — на шлях.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

Выканайце гэтую праверку, перш чым нешта змяняць у кліенце. Калі парты адказваюць, а асацыяцыя ўсё яшчэ не ўдаецца, праблема ў ўліковых даных або палітыцы. Калі яны не адказваюць зусім, ніякая праўка профілю не дапаможа.

Калі абодва пратаколы мусяць суіснаваць

Адміністраванне абедзвюх сетак — слушная прычына захаваць абодва пратаколы. Звычайная схема завяршае WireGuard і IPsec на асобных інтэрфейсах або асобных шлюзах. Затым ухвалены трафік маршрутызуецца паміж імі.

Гэтая схема ўводзіць мяжу даверу і аўтарызацыі, і яе трэба так і запісаць. Якія піры могуць пераходзіць, у якім кірунку і пад чыёй палітыкай — гэта рашэнне па маршрутызацыі і файрволе. Ні адзін з пратаколаў яго не дае.

Чаго гэта не робіць — гэта празрыстага пераўтварэння. Трафік, які прыходзіць праз WireGuard, перанакіроўваецца ў тунэль IPsec, і ўсякая палітыка паміж імі да яго ўжываецца.

Спачатку ўдакладніце патрабаванні сервера да пратакола і аўтэнтыфікацыі. Затым выкарыстоўвайце кліент і шлях рэгістрацыі, якія падтрымлівае аператар, і трымайце прыватныя ключы па-за вэб-канвертарамі, пакуль гэта адбываецца.