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 тунел и свако правило између примењује се на њега.

Најпре разјасните захтеве сервера за протокол и проверу идентитета. Затим употребите клијент и пут регистрације које оператер подржава и држите приватне кључеве далеко од веб претварача док се то одвија.