в том числе на локалхосте

Траф магически пропадает

Да, никаких ошибок в netstat -sp esp нету.

загрузи if_enc и смотри в tcpdump

Кому там нужно больше нетмапа, айда в карент https://reviews.freebsd.org/D17683

загрузи if_enc и смотри в tcpdump

Да по логу видно. Смешное. Что не попадает пакет в ipfw второй раз после декапсуляции если ipsec применялся. Это что-то очень странное, но видно чётко. Вот без IPsec: Oct 25 20:08:12 gateway-old kernel: ipfw: 1720 Count ICMP:8.0 10.0.10.1 10.0.10.2 out via gif0 Oct 25 20:08:12 gateway-old kernel: ipfw: 1720 Count P:4 10.0.0.1 10.0.0.2 out via em1 Oct 25 20:08:12 gateway-old kernel: ipfw: 1720 Count P:4 10.0.0.2 10.0.0.1 in via em1 Oct 25 20:08:12 gateway-old kernel: ipfw: 1720 Count ICMP:0.0 10.0.10.2 10.0.10.1 in via gif0 Вот с IPsec: Oct 25 20:09:58 gateway-old kernel: ipfw: 1720 Count ICMP:8.0 10.0.10.1 10.0.10.2 out via gif0 Oct 25 20:09:58 gateway-old kernel: ipfw: 1720 Count P:50 10.0.0.1 10.0.0.2 out via em1 Oct 25 20:09:58 gateway-old kernel: ipfw: 1720 Count P:50 10.0.0.2 10.0.0.1 in via em1 Нету пакета в файрволле. А в сокете — есть, сам ping ответ видит. Разница только в наличии tunnel-политики IPsec для протокола ipencap.

Есть ещё вот такое https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174602

Кому шо, у меня wireguard не пашет.

Вон же @blacklion79 вроде заводил

Кому шо, у меня wireguard не пашет.

который на go? Он у меня сокет через раз не может открыть, я плюнул

Вон же @blacklion79 вроде заводил

Ага. То заводится, то не заводится. Я не смог понять от чего зависит.

Говорит, мол, управляющий сокет not exist внезапно и всё

А ещё через 3 попытки всё работает

А потом снова нет

Глюкалово

ох уж эти хипстеры програмисты :)

Какой контрол, я его перезапускаю каждый раз.

Всё вроде правильно, но пакетики не бегают.

Какой контрол, я его перезапускаю каждый раз.

Ну вот у меня сам "драйвер" wireguard-go запускается 1 раз из 5

народ, какие фс умеет 8 фря?

Закапывай.

надо дистр заменить на линь

и линь тоже закапывай

Да по логу видно. Смешное. Что не попадает пакет в ipfw второй раз после декапсуляции если ipsec применялся. Это что-то очень странное, но видно чётко. Вот без IPsec: Oct 25 20:08:12 gateway-old kernel: ipfw: 1720 Count ICMP:8.0 10.0.10.1 10.0.10.2 out via gif0 Oct 25 20:08:12 gateway-old kernel: ipfw: 1720 Count P:4 10.0.0.1 10.0.0.2 out via em1 Oct 25 20:08:12 gateway-old kernel: ipfw: 1720 Count P:4 10.0.0.2 10.0.0.1 in via em1 Oct 25 20:08:12 gateway-old kernel: ipfw: 1720 Count ICMP:0.0 10.0.10.2 10.0.10.1 in via gif0 Вот с IPsec: Oct 25 20:09:58 gateway-old kernel: ipfw: 1720 Count ICMP:8.0 10.0.10.1 10.0.10.2 out via gif0 Oct 25 20:09:58 gateway-old kernel: ipfw: 1720 Count P:50 10.0.0.1 10.0.0.2 out via em1 Oct 25 20:09:58 gateway-old kernel: ipfw: 1720 Count P:50 10.0.0.2 10.0.0.1 in via em1 Нету пакета в файрволле. А в сокете — есть, сам ping ответ видит. Разница только в наличии tunnel-политики IPsec для протокола ipencap.

% sysctl -d net.inet.ipsec.filtertunnel

OMG

Да, в логе появляется. Но дальше как-то не de-nat-ится

с такого пакета стрипаются теги все про интерфейсы?

Т.е. не получается, что на нём висит даже после расшифровки, что он in phy0?

Oct 25 20:24:06 gateway-old kernel: ipfw: 1720 Count ICMP:0.0 10.0.10.2 10.0.10.1 in via em1

НЕ СТРИПАЮТСЯ

БЛЯДЬ

Извините

Я не понимаю, как в таких условиях файрволл писать, когда пакет который на самом деле in via gif0 записан как in via em1 :-(

Причём я нашёл закрытый баг про это

не может файрволл пустить пакет для 10.0.10.1 через em1

Причём он на столько via em1, что его даже tcpdump -i gif0 не видит :-(

скорее всего ты опять что-то делаешь неправильно

Ну вот, кусочек лога от правила до всех разборок я привёл

ICMP-ответ на туннельный адрес на физическом интерфейсе

если пакет декапсулирован gif'ом, то rcvif будет gif0

Закапывай.

прежде чем закопать, нужно сохранить данные так, чтобы можно было вытащить потом

если пакет декапсулирован gif'ом, то rcvif будет gif0

Вот лог 1 цикла пинга Oct 25 20:28:29 gateway-old kernel: ipfw: 1720 Count ICMP:8.0 10.0.10.1 10.0.10.2 out via gif0 Oct 25 20:28:29 gateway-old kernel: ipfw: 1720 Count P:50 10.0.0.1 10.0.0.2 out via em1 Oct 25 20:28:29 gateway-old kernel: ipfw: 1720 Count P:50 10.0.0.2 10.0.0.1 in via em1 Oct 25 20:28:29 gateway-old kernel: ipfw: 1720 Count ICMP:0.0 10.0.10.2 10.0.10.1 in via em1

Запрос пошёл через gif0, был энапсулирован, зашифрован и послан через em1

Ответ пришёл зашифрованным через em1 (правильно), потом расшифрован, ДЕЭНКАПСУЛИРОВАН и принят снова через em1

10.0.0.0/24 — физика, 10.0.10.0/24 — внутри туннеля

значит у тебя туннельная SA, которая декапсулировала, а не gif это сделал

прежде чем закопать, нужно сохранить данные так, чтобы можно было вытащить потом

Перелить никак?

значит у тебя туннельная SA, которая декапсулировала, а не gif это сделал

А почему она это сделала?

SA у меня вот такие:

потому что она туннельная

потому что она туннельная

Ну, она должна ESP декапсулировать а не то, что внутри

нет

10.0.0.2[any] 10.0.0.1[any] ip4 in ipsec esp/transport//require spid=10 seq=1 pid=3035 scope=global refcnt=1 10.0.0.1[any] 10.0.0.2[any] ip4 out ipsec esp/transport//require spid=9 seq=0 pid=3035 scope=global refcnt=1

это не SA

Перелить никак?

400 гиг, канал 10 мбит

как, но очень долго

А что тебе надо в итоге то? Ось поставить и данные оставить? Kvm есть?

это не SA

10.0.0.2 10.0.0.1 esp mode=any spi=65538(0x00010002) reqid=0(0x00000000) E: null seq=0x00000000 replay=0 flags=0x00000040 state=mature created: Oct 25 20:09:47 2018 current: Oct 25 20:30:53 2018 diff: 1266(s) hard: 0(s) soft: 0(s) last: Oct 25 20:09:48 2018 hard: 0(s) soft: 0(s) current: 1512(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 20 hard: 0 soft: 0 sadb_seq=1 pid=3033 refcnt=1 10.0.0.1 10.0.0.2 esp mode=any spi=65537(0x00010001) reqid=0(0x00000000) E: null seq=0x00000014 replay=0 flags=0x00000040 state=mature created: Oct 25 20:09:47 2018 current: Oct 25 20:30:53 2018 diff: 1266(s) hard: 0(s) soft: 0(s) last: Oct 25 20:09:48 2018 hard: 0(s) soft: 0(s) current: 2152(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 20 hard: 0 soft: 0 sadb_seq=0 pid=3033 refcnt=1

По идее, мне вообще нужны транспортные SA, не туннельные, в данном случае.

А что тебе надо в итоге то? Ось поставить и данные оставить? Kvm есть?

поставить свежий деб, данные сохранить (сайт)

ипми+квм е

поставить свежий деб, данные сохранить (сайт)

Та хоть фат32

ну у тебя mode=any, т.е. " 334 if (prot == IPPROTO_IPIP && 335 saidx->mode != IPSEC_MODE_TRANSPORT) { 336 if (m->m_pkthdr.len - skip < sizeof(struct ip)) { 337 IPSEC_ISTAT(sproto, hdrops); 338 error = EINVAL; 339 goto bad; 340 } 341 /* enc0: strip outer IPv4 header */ 342 m_striphdr(m, 0, ip->ip_hl << 2); 343 } "

если ты скажешь при добавлении SA, -m transport

ну у тебя mode=any, т.е. " 334 if (prot == IPPROTO_IPIP && 335 saidx->mode != IPSEC_MODE_TRANSPORT) { 336 if (m->m_pkthdr.len - skip < sizeof(struct ip)) { 337 IPSEC_ISTAT(sproto, hdrops); 338 error = EINVAL; 339 goto bad; 340 } 341 /* enc0: strip outer IPv4 header */ 342 m_striphdr(m, 0, ip->ip_hl << 2); 343 } "

ага, уже начитал в man'е, ка краз пробую

то IPsec не будет стрипать

и тогда ipencap пакет попадёт в gif

Умничает IPsec! :-)

Да, так заработало

Но я начинаю понимать тех, кто написал и тех, кто полюбил WireGuard

то IPsec не будет стрипать

Огромное тебе спасибо

Я тебе должен не одно пиво. или что ты предпочитаешь.

:)

Ты же в Москве? :)

не, наверно где-то через месяц буду там на недельку

Увы, я не буду, я-то тоже не в Москве. А обычно ты где?

Киров

ужасное место, простите.

окруженное лагерями)

Киров

Который в Хибинах? Ещё один повод съездить. Но летом, летом. Простите. Горные лыжи не для меня, увы.

Или это Вятка, блин. Я всё время путаю.

Кто Киров а кто Кировск

не, гор у нас нет, по крайней мере с которых на лыжах ездить можно)

Да, Вятка.

Киров-Вятка-Хлынов

У меня дед был из тех краёв. В общем, тоже повод съездить! :-)

По идее, там даже по-прежнему где-то в лесу живут мои дальние (очень уже дальние) родственники.

В лесу — там лесхоз всегда был. Но я там никогда не был, только мама рассказывала как её туда два раза на лето отправляли

:)

да, так мы и живём тут, в лесу, окружённые лагерями

делаем себе потихоньку С400

Р-романтика :)

https://twitter.com/pernila/status/1055546024297725952

делаем себе потихоньку С400

Лучше б что полезное :-)

Лучше б что полезное :-)

что только не пробовали, всё ракетыполучаются

Да, да. Помню этот старый анекдот :-)

используя if_enc ты можешь занатить пакет во время ipsec обработки

Ну, кстати, не могу. Потому что если у меня SAP'ы и SA'шки на после-nat-адреса, то нифига в if_enc не попадает, потому что он не находит SA по трафику до nat (что не удивительно). Т.е. в if_enc вообще не попадает трафик, который интересен. А вот можно ли сделать SA'шки на сочетание внутреннего адреса и внешнего я не очень понимаю, потому что на втором-то конце адреса другие… В общем, похоже, не может NAT-бокс накрутить шифрование в транспортном режиме без всякого туннелирования вообще.

я не понял объяснение твоё. Надо понимать как действует if_enc и когда ты можешь вызвать pfil хук из него. Исходящий трафик попадает в ipsec на основании матчинга политики, а входящий на основании SPI в SA и dst адреса пакета. От этого и надо думать как и когда натить и какие политики и SA делать.

я не понял объяснение твоё. Надо понимать как действует if_enc и когда ты можешь вызвать pfil хук из него. Исходящий трафик попадает в ipsec на основании матчинга политики, а входящий на основании SPI в SA и dst адреса пакета. От этого и надо думать как и когда натить и какие политики и SA делать.

Угу, надо на бумажке порисовать. Ситуация получается несимментричная — на выходе IPsec видит внутренние адреса (только до NAT), на входе — внешние, а другой конец видит, конечно, только внешние адреса (внутренних для него несуществует). SA должны быть РАЗНЫЕ а не одинаковые, получается. Главное не запутаться. Т.е. я уже. завтра возьму бумажку