Некорректные пакеты от провайдера

Весело

This document describes three IPv4 address blocks that are provided for use in documentation.  
The use of designated address ranges for documentation and examples reduces the likelihood of conflicts 
and confusion arising from the use of addresses assigned for some other purpose.

   [RFC1166] reserves the first of the three address blocks,
   192.0.2.0/24.  

https://datatracker.ietf.org/doc/rfc5737/

Во втором случае в поле src должно быть: 8.8.8.8

А это был не какой-нибудь port-unreachable?

iptables'ом вы такое не исправите, iptables не изменяет адреса в пакете, там создаётся записи в conntrack. Все пакеты, попадающие под условия в записи, относятся к одному соединению и у них изменяются адреса/порты. У вас первый пакет прошёл, запись (точнее две записи) созданы.

Возможно, получится что-то сделать с помощью ″conntrack -I″, парся вывод ″conntrack -E″

Это inside/outside NAT у провайдера.
Можно попробовать поднять NAT на самой машине.
Двойной NAT получится. Один на тачке, второй у прова.

Четко по документации нат настраивали. Вот и настроили двойной :)

192.0.2.0/24 - это для примера

Может лучше спросить у провайдера почему так ? Проблему провайдера лучше чтоб решал сам провайдер :-)

Вообще в таком случае у вас не должна работать связь с внешним миром, полностью, т.к. вы отправляете пакеты на один адрес, а ответы всегда приходят с другого. Ни одно tcp-соединение не создастся.
Если же всё работает, значит есть большое подозрение, что эти пакеты, как написал mky, - просто ответы об ошибках от какого-то провайдерского маршрутизатора. Это выглядит не совсем красиво, но в целом нормально, ибо на возможность связи с внешним миром не влияет.

Но, можно сделать через pedit так:

tc qdisc add dev wan0 handle ffff: ingress
tc filter add dev wan0 protocol ip u32 match ip src 192.0.2.1 match ip dst 100.64.8.1 action pedit ex murge ip src set <ip своей vps на которой vpn> pipe action csum ip and udp and tcp and icmp

Потом через этот vpn выйти в мир.

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

Скажи что ничего не пингуется, а тебе очень нужно пинговать!

У меня возникли подозрения, что у ТС'а не провайдер, а хостер и ТС не решает проблему, а ковыряет дырку в обход его запретов...

Но как можно через iptables изменять на входящем пакете адрес источника на правильный?

Например, с помощью nfqueue.

Нет, это обход технических проблем провайдера.

• Это как минимум надо знать C
• Это не более 300Mbps.

tc-pedit наше всё