Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
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
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 9529 из 10753 ===================================== RU.UNIX.BSD =
От   : Victor Sudakov                   2:5005/49          19 Dec 19 07:57:38
Кому : eugen                                               19 Dec 19 07:57:38
Тема : l2tp client
FGHI : area://RU.UNIX.BSD?msgid=2:5005/49+5dfacd2f
На   : area://RU.UNIX.BSD?msgid=grosbein.net+b317f3d5
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.UNIX.BSD?msgid=grosbein.net+cb8feaa7
==============================================================================
Dear eugen,

19 Dec 19 06:29, Eugene Grosbein wrote to me:

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

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

Не привык пока. Если я тебе лог мылом пришлю, покажешь где там про протоколы и про pfs_group ?

Обычно FreeBSD - Cisco, FreeBSD - FreeBSD работает как из пушки, первый раз в жизни такое чудо вижу.

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

EG> А покажи setkey -DP.

Да там же в https://termbin.com/24pec в начале.

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

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

На моем хосте публичный адрес, но мысль понял. Попробую вечером. Если например этот netpoint сам себе esp фильтрует, должна такая картина быть.

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

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

Вот сегодня вечером заведу с этого хоста IPSec до какого-нибудь подведомственного мне хоста под эхотагом, тут и узнаю, провайдер виноват или нет. Или провайдер, но не мой.

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

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

Готов показать, но не публично.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322
* Origin: Ulthar (2:5005/49)

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