dsk Posted January 29, 2015 · Report post Вопрос наверное к линукс-гуру. Каким образом можно обойти работу модуля nf_defrag_ipv4, если вообще возможно? Всякие телодвижения с NOTRACK не помогают, пакеты все равно дефрагментируются. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted January 30, 2015 · Report post А вы как себе представляете передачу пакетов между интерфейсами с разным mtu? Если сильно мешает - собирайте кастомное ядро с ампутированным функционалом, на свой страх и риск. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dsk Posted January 30, 2015 · Report post Если не подгружать модуль conntrack со всеми вытекающими, то все работает как надо. При подгрузке conntrack, автоматом подгружается и этот модуль и дальше начинается свистопляска в виде сборки воедино этим модулем уже фрагментированных как нужно пакетов. И это при том, что этому трафику в conntrack делать то и нечего, и он туда вроде как не попадает. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
aabc Posted January 30, 2015 · Report post уже фрагментированных как нужно пакетов. Как так происходит? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dsk Posted January 31, 2015 · Report post Элементарно. На вход тазика прилетает, допустим, udp пакет размером 1764 байта. Прилетает на самом деле два пакета, один 1500, другой 264 байта, ибо mtu 1500 и отфрагментилось оно раньше, там где надо. В результате работы nf_defrag_ipv4 мы получаем на выходе не два пакета, как пришло на вход, а уже собранный один пакет в 1764 байта, со всеми вытекающими проблемами. Весь вопрос собственно в том, каким образом, и вообще возможно ли, заставить этот модуль жрать не весь трафик, а только тот, который должен попадать в conntrack. Гребаный conntrack нужен всего лишь для одного DNAT, и если возможности обхода нет, то буду просто выпиливать это правило с данного тазика, ибо без conntrack все работает. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nuclearcat Posted January 31, 2015 · Report post Это очень похоже на логику работы GSO. Мне кажется (но исходники детально не разбирал, там совсем немного кода и легко его пропатчить), nf_defrag собирает только пакеты с флагом фрагментации. Приведенный вами случай совсем не из той оперы. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dsk Posted January 31, 2015 · Report post А почему трафик вообще туда попадает? Неужели nf_defrag работает на самом входе, до всяких raw, nat и т.п. и путей обхода нет? Или я как-то неверно оперирую правилом ... -j NOTRACK От программирования я к сожалению далек, и лезть в исходники для меня темный лес, а мой знакомый программер последнее время сильно занят, не до меня ему... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
aabc Posted January 31, 2015 (edited) · Report post Неужели nf_defrag работает на самом входе, до всяких raw, nat и т.п. и путей обхода нет? Да. От программирования я к сожалению далек, и лезть в исходники для меня темный лес, а мой знакомый программер последнее время сильно занят, не до меня ему... Самое простое - в файле ipv4/netfilter/nf_defrag_ipv4.c в начало ipv4_conntrack_defrag() вставить return NF_ACCEPT. Правда, не понятно как поведёт себя conntrack, когда до него начнут доходить фрагментированные пакеты, могут быть побочные эффекты. Возможно, в ipv4_conntrack_defrag() надо сразу делать функционал NOTRACK, а не просто return NF_ACCEPT, чтоб их не было. Edited January 31, 2015 by aabc Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
