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

Прво разјаснете ги барањата на серверот за протокол и автентикација. Потоа користете го клиентот и патеката за регистрација што ги поддржува операторот, и држете ги приватните клучеви подалеку од веб-конвертори додека тоа се случува.