wireguard не пропускает http, при этом ssh и ping проходят

[montanaboy]

Есть 3 машины: A, B, С
Построены 2 wg туннеля A->B и C->B (вместе соединяется так A->B<-С)
На B поднимаются 2 разных wg интерфейса с разными подсетями (10.0.0.0/24 и 10.0.1.0.24) для каждого A и C отдельно.
В итоге:
A = 10.0.0.2
B(A) = 10.0.0.1
B(C) = 10.0.1.1
С = 10.0.1.2
Туннели на B соединены между собой, настроен форвардинг и маскарад. На A и C попарно созданы роуты via подсети на B.
С пингуется с A, наоборот тоже все работает, B пересылает пакеты в две стороны. По ssh тоже можно подключиться с A на C и с C на A.
Но запущенный на C nginx недоступен при curl http://10.0.1.2, ни с A ни с B это не работает. При этом ping 10.0.1.2 и с A и c B работает.
На С сделано перенаправление 80 порта с 10.0.1.2 на 127.0.0.1, если локально на C сделать curl http://10.0.1.2 то ответ приходит. С любого другого хоста - зависает намертво.
Через tcpdump на C было обнаружено, что при обращении c B в этом случае какие-то пакеты приходят, но нет syn/ack, при запросе с A вообще тишина.
Что это может быть? Как решать, куда смотреть ?

 

[tenfield]

Что это может быть: Неправильный маскарад/роуты. Возможно образуются лупы. Возможно лишнее правило на блок http на хосте B. Если ssh работает, возможно nginx обслуживает только localhost/127.0.0.1?

куда смотреть:
На хосте "A" ip route get 10.0.1.2 должно быть via 10.0.0.1 dev wgN src 10.0.0.2
С хоста A traceroute 10.0.1.2 должно быть через 10.0.0.1

Как решать:
На хосте C поднять еще один http сервис, python3 -m http.server 8000 (слушает 0.0.0.0:8000) и проверить через curl с B и с А
Если не работает, убрать хост A. Построить сначала B-C и проверить работу, потом добавить A

 

[montanaboy]

Возможно лишнее правило на блок http на хосте B.

Проверял, нет никаких DROP, на B вообще кроме форвардинга с маскарадом ничего нет.

возможно nginx обслуживает только localhost/127.0.0.1

Тоже проверял, он крутится на 0.0.0.0:80, и доступен из интернета по внешнему ip С

На хосте "A" ip route get 10.0.1.2 должно быть via 10.0.0.1 dev wgN src 10.0.0.2

Да, так и сделано, только без src. На C точно так же к A проделано.

A traceroute 10.0.1.2 должно быть через 10.0.0.1

Идет через 10.0.0.1, все верно.

Если не работает, убрать хост A. Построить сначала B-C и проверить работу, потом добавить A

Так оно так и есть, там отдельные туннели для AB и BC, если через из B посылать B->С получается та же история, недоступен nginx

Есть еще одна особенность, рядом крутится другой сервис на 9000 порту, если с A на него послать curl http://10.0.1.2:9000 без явного указания интерфейса wg то он недоступен, но с --interface wg-ab ответ нормальный.

АПДЕЙТ:
Попробовал с текущими сетевыми настройками на A сделать curl http://10.0.1.2:9000 (без указания интерфейса) - ответ нормальный. А по порту 80 уже не бъет.

 

[montanaboy]

Апну, проблема все еще не решеша

 

[toxella]

Попробуй MTU понизить на сервере и клиентах до 1420

 

[kerberos]

пробуй смотреть tcpdump на каждой машине по очереди кто дропает твои пакеты http.
Из памяти как то так это делается:
sudo tcpdump -s0 -i any -Aql port 80 | grep -A5 -P 'HTTP'
Если в командной строке не видно замени -Aql нa -W и пиши в дамп и потом смотри через wireshark локально, другого пути нет самому разобратся...

 

[Patr1ck]

Мой опыт показывает следующее, не проходит то что должно проходить - проверь файрволл, в 9 из 10 случаев это он.

 

[montanaboy]

Проблема была в nginx, точнее в порту на котором он крутился (80), поставил другой - все заработало как часы. Странно конечно, никаких блоков ни на одном из 3-х серверов на 80 порт не было. Файрволов нет никаких, в iptables чисто.

 

[stelthon]

Проверяй вот это:

1) Фильтрацию сетевых пакетов на предмет блокировок определенных протоколов и портов. На хостах может работать несколько различных фильтров разного уровня, и не только файерволы, но могут быть запреты на уровне различных списков доступа, ids/ips систем, итд. Проверять фильтрацию желательно по всему маршруту следования пакетов.
2) Маршрутизацию, в том числе возможно неправильно работает маршрутизация "от источника", возможно где-то особым образом настроены правила НАТ, маскарадинга, форвардинга, итд, что потенциально может оказывать влияние на пакеты и пути их следования.
3) Параметры работы сетевой подсистемы операционной системы, возможно где-то какие-то ограничения, например на уровне ядра.
4) Настройки правил уровня приложений, на уровне приложений возможны ограничения, могут отрабатывать какие-то фильтры типа waf, итд
5) Фильтрация действий на уровне отношений объектов системы, если работают всякие там selinux, apparmor, итд.