Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 18 Jan 24 18:16:22, всего сообщений: 10753
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 9528 из 10753 ===================================== RU.UNIX.BSD =
От   : Eugene Grosbein                  2:5006/1           19 Dec 19 06:29:48
Кому : Victor Sudakov                                      19 Dec 19 06:29:48
Тема : Re: l2tp client
FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+b317f3d5
На   : area://RU.UNIX.BSD?msgid=2:5005/49+5dfa6893
= Кодировка сообщения определена как: IBM866 =================================
Ответ: area://RU.UNIX.BSD?msgid=2:5005/49+5dfacd2f
==============================================================================
19 дек. 2019, четверг, в 00:20 NOVT, Victor Sudakov написал(а):

VS>>> Hе получается к этой штуке подключиться, что бы там ни было, в
VS>>> конфиг ей не заглянешь. Как найти общее множество алгоритмов? В
VS>>> wireshark на этой стадии уже ничего не видно, т.е. "Encrypted
VS>>> data" Как я понимаю, доходит до фазы 2 и не дальше, точнее дальше
VS>>> NO-PROPOSAL-CHOSEN и INVALID-HASH-INFORMATION
EG>> Во-первых, в моём примере не зря уровень дебага был установлен в
EG>> debug2 (что даже больше подробностей даёт, чем debug). Типа намёк. Там
EG>> будут виден список алгоритмов, которые присылает в IKE та сторона.
VS> Я запускал "racoon -Fdd", полагаю что это то же самое. Список алгоритмов там
VS> как-то невнятно виден, ну да ладно.

Hадо привыкнуть к формату лога, да. Оно излишне многословно и бестолково,
но нужная информация там есть.

VS> Причина оказывается не в наборах
VS> криптографических алгоритмов. Я убрал "pfs_group 2" из sainfo, и IPSec поднялся,
VS> сформировались две SA, в ту и в обратную сторону.

А покажи setkey -DP.

VS> Правда mpd5 через них не пашет, не дожидается ответа (expecting reply; none
VS> received), и в tcpdump вижу только исходящие от меня ESP пакеты, но не входящие.
VS> Где-то видимо режется. В pf разрешены ESP. Завтра буду разбираться. Или подниму
VS> transport mode с каким-нибудь ещё хостом вместо этого злосчастного VPN-gateway,
VS> проверю методом исключения, так сказать.

Включи nat_traversal. В моём примере конфига не было лишних строк
и ты совершенно зря его игнорируешь. Там в комментарии был пример
для forced-режима, чтобы инкапсуляция была в UDP/4500 вместо ESP,
так больше шансов пролезть через интернет.

VS> А ответы от L2TP сервера точно нужно ждать с 1701 порта?

После расшифровки - да.

VS> Вот тут: https://termbin.com/24pec не видится навскидку что-то неправильное?

Тут всё более менее хорошо, кроме выбранной инкапсуляции ESP,
которая почему-то в твоём случае не пролазит через провайдера.

VS> И что за прикол с "pfs_group 2" и почему оно даёт такой негативный эффект?

Вероятно, remote его неподдерживает, только и всего. Подробней - надо в логи
смотреть.

Eugene
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.093863 секунды