Подскажите по tcp соединениям - бесконечные SYN и SYN. в tcpdump

И так, виновник найден. Конечный шлюз, перед моим хостом теряет ответный трафик.

На p2p1 - вижу как с vpn тоннеля приходит трафик, на интерфейсе локальной сети - всё. Приплыли. Нет ничего для моего хоста где я запустил Яндекс. - Может кто подскажет куда копать, если firewallа нету по идее. По чему подобный трафик может ядро откидывать? С самого vpn сервера, хост откуда я запускаю ЯндексТелемост - пингуется и доступен.

Ядро может дропать входящие из-за rp_filter (/proc/sys/net/ipv4/conf/iface/rp_filter). Если SYN-ACK входит не через тот интерфейс, через который выходил SYN. Но из твоего поста не ясно, на каком хосте ты запускал tcpdump (на том который инициирует соединение до cloud-api.yandex.net?) и на каком интерфейсе (конкретный или all?).

Схема:

Я -> (сюда приходит SAN но нету SAN+ACK ответного) шлюз (отсюда уходит SYN, сюда же приходит SYN+ACK) -> VPN клиент (mptcp+openvpn в режиме tcp) -> VPN сервер (mptcp+openvpn в режиме tcp) -> мир

rp_filter везде стоит в значении 1

Поставил в ноль на исходящем к моей машине интерфейсе - не помогло.

Раз шлюз дропает, значит на нём и надо ставить rp_filter=0 на интерфейсе наружу. Видимо он исходящие шлёт в туннель, а входящие к нему приходят не из туннеля.

Не, не, всё приходит с тоннеля, с метками похоже проблемы какие-то, не врубаюсь. Если из Windows метить пакеты ToS, прокидывать их до шлюза, всё приходит обратно, всё работает. А скайп, и т.п. - таким же образом мечу - не работает, хоть убейся. В любом случае, пока писал тред, дошло, что точно дело в шлюзе… :)

Ядро может дропать входящие из-за rp_filter (/proc/sys/net/ipv4/conf/iface/rp_filter). Если SYN-ACK входит не через тот интерфейс, через который выходил SYN

Наконец то на простом языке объяснил значение параметра, вроде по английски читать умею, но ниифига толком не понимал, как и чего. Теперь гораздо ясней. :)