Проблема с TCP flags DF

[alexbalkan]

Помогите плиз разобраться.
Что-то видимо надо донастроить или устранить.
В сети все TCP пакеты с флагом DF.
Перечитал массу по этому поводу, но ничего не помогло из предложенных вариантов устранения.
имеется два настроенных VPS хоста. Все работает как бы без проблем. Но решил попрактиковать TCP UDP. Использовал hping3 -S -p(port) ip-host. И тут заметил проблему (в пакетах флаг DF). Подскажите откуда начинать искать проблему.

[Eugene Nuke]

Устанавливая DF, TCP ищет Path MTU https://en.wikipedia.org/wiki/Path_MTU_Discovery, это общепринятая практика https://tools.ietf.org/html/rfc1191.

[AnrDaemon]

Помогите плиз разобраться.
Что-то видимо надо донастроить или устранить.
В сети все TCP пакеты с флагом DF.

Ничего не надо донастраивать, так и должно быть.

[alexbalkan]

Ок. Спасибо огромное AnrDaemon. Вроде как бы разобрался, помимо этого, все пакеты шли с контрольной суммой Incorrect. Щас вроде как бы все нормально стало. Толком и не понял, как разрешилась проблема.
Но попутно есть вопрос.
Вся политика DROP
Не получается запустить hping3 без флагов. Пишет что operation not permitted
INPUT -j DROP
OUTPUT -j DROP

INPUT -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
OUTPUT -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

Но если OUPUT -j ACCEPT все работает. Помогите решить проблему

[Punko]

alexbalkan, насколько я знаю, сначала должны быть разрешающие правила.
Ибо при первом совпадении дальнейшие правила просто откидываются.

[AnrDaemon]

все пакеты шли с контрольной суммой Incorrect

google:checksumm+offloading

т.е. так и должно быть. Опять же.
Пользователь добавил сообщение 04 Апреля 2017, 02:03:24:А -P OUTPUT DROP - это почти всегда ошибка.

[AnrDaemon]

Что сказать то хотел?…

[alexbalkan]

Что хотел, то сказал. Решил проблемку на энном этапе. Очень сложная сетка получилась, для меня как новичка чтобы разбираться в тонкостях network.

[AnrDaemon]

А по-моему вы просто перемудрили.
Почему-то у всех без замудреных настроек всё работает.

[alexbalkan]

А по-моему вы просто перемудрили.

Может быть и так, но вроде как разобрался не совсем. Так же по проблеме, UDP пакеты и продолжали идти bad chksumm. Погуглив ничего не нашел как два варианта, 1) забить на ошибки 2) отключить проверку на сетевом интерфейсе ethtool -K eth0 tx off rx off. Такой вот вопрос - какой из этих вариантов лучше. Потому как другого решения нет я так понял. Или же как-то иначе можно?

[AnrDaemon]

Для начала стоит разобраться, действительно ли контрольная сумма неверна? В современной сети CRC в большинстве случаев считается аппаратно.

[alexbalkan]

В современной сети CRC в большинстве случаев считается аппаратно.

Совершенно верно. Ошибки не могут возникнуть из неоткуда. Ммммдаааа. Сначала попробую проверить еще раз выяснить откуда у проблемы "ноги" растут. Сделал фильтрацию ICMP, очень даже возможно, это и дало свой результат. Применил такую политику -A INPUT  -p icmp --icmp-type 3,8,12 -m conntrack -ctstate NEW -j ACCEPT
OUTPUT -p icmp --icmp-type 0,3,4,8,11,12 -m conntrack -ctstate NEW -j ACCEPT
Может быть что-то не так. Но я только учусь. Поправьте меня. Решил сам научится решать проблемы, а не просто тупо читать и лепить что попало, подойдет - не подойдет, заработало - или опять не работает.

[snowin]

alexbalkan,
сетевую поменяй

[alexbalkan]

Ок. Поменял на время. поставил icmp-type any. И как вышло инициатор bad chksumm мой хост.
ip-my_host--> ext_ip [bad udp chksum 0x23a2 -> 0x421!] 63006% [1au] AAAA? ns6.gandi.net. ar: . OPT UDPsize=512 DO (42). Что заметил все пакеты 512. Может быть это проблема. Что можно поменять?

[AnrDaemon]

Ещё раз - откуда вы это взяли?