LINUX.ORG.RU
решено ФорумAdmin

Проблемы с ftp. Пропадает пакет с командой PORT.


0

1

Куда выложить дамп я хз, вот скриншот Итак ситуация. Дамп снят с маршрутизатора с интерфейса за которым находится 10.11.0.54 в нем вы можете наблюдать пакет в командой PORT под номером 12. В дампе с интерфейса в сторону 10.11.0.62 этого пакета уже нету. Кто виноват и что делать. Каковы причины потери. Это не iptables точно, правил там много, но так глубоко в пакеты не лезут, чтобы только PORT вырезать, и сеть 10.11 пропускаю всю, без каких либо ограничений.


так глубоко в пакеты не лезут

Тут ты ошибаешься. Если там Linux, проверь подгружен ли там модуль nf_conntrack_ftp. Если это маршрутизатор с web-интерфейсом - поврубай всё связанное с FTP(название опций могут варьироваться, от ALG Gateway до FTP Passthrough).

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

Модуль загружен, но разве он не нужен для того, чтобы корректно обрабатывалось фаерволом второе соединение для передачи данных? Тем более iptables пропускает весь трафик сетей 10.11 без каких либо NATов и других правил.

Тут смысл в том, что проблемы есть только если клиент - конкретная аппаратная ревизия свича(raisecom 2110ea RevB). Я пытаюсь выгрузить по ФТП конфиг, или залить на него прошивку и возникают проблемы. В целом с фтп проблем нет, а вот с эими свичами есть. Но и причем тут свич тоже не совсем понятно, если пакет, вроде на вид валидный, доходит до маршрутизатора, а вот он по каким-то причинам его дропает.

swelf
() автор топика
Ответ на: комментарий от swelf

Отброс пакетов iptables-ом всегда можно увидеть. «iptables -t raw -A PREROUTING ... -j TRACE»

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

Кривые реализации tcp на таких устройствах не редкость. Если есть свежая прошивка, то попробуй обновить - возможно в ней что-то починили.

vel ★★★★★
()
Ответ на: комментарий от vel

Я настолько был уверен, что это не iptables, так как только с этой версией свичей проблемы, что даже не смотрел.

Aug 28 17:46:29 isport kernel: [273800.358083] nf_ct_ftp: dropping packetIN=eth0.5 OUT= MAC=00:1b:21:cb:ac:89:00:0e:5e:2d:cd:49:08:00 SRC=10.1.1.2 DST=10.1.1.1 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=45514 DF PROTO=TCP SPT=58392 DPT=21 SEQ=2713967771 ACK=3625424058 WINDOW=10000 RES=0x00 ACK PSH URGP=0
Выгрузил модуль и все заработало, но почему оно дропало пакет непонятно. Причем в данном случае я подключался точка-точка мимо роутера. И модуль все равно грохнул пакет, на другой машине с другим ядром.

Кривые реализации tcp на таких устройствах не редкость. Если есть свежая прошивка, то попробуй обновить - возможно в ней что-то починили.

Это на всех версиях прошивок на этой ревизии свичей

swelf
() автор топика
Последнее исправление: swelf (всего исправлений: 1)

Глянул тут исходники nf_conntack_ftp

static int try_number(const char *data, size_t dlen, u_int32_t array[],
              int array_size, char sep, char term)
{
    u_int32_t i, len;

    memset(array, 0, sizeof(array[0])*array_size);

    /* Keep data pointing at next char. */
    for (i = 0, len = 0; len < dlen && i < array_size; len++, data++) {
        if (*data >= '0' && *data <= '9') {
            array[i] = array[i]*10 + *data - '0';
        }
        else if (*data == sep)
            i++;
        else {
            /* Unexpected character; true if it's the
               terminator and we're finished. */
            if (*data == term && i == array_size - 1)
                return len;

            pr_debug("Char %u (got %u nums) `%u' unexpected\n",
                 len, i, *data);
            return 0;
        }
    }
    pr_debug("Failed to fill %u numbers separated by %c\n",
         array_size, sep);
    return 0;
}

/* Returns 0, or length of numbers: 192,168,1,1,5,6 */
static int try_rfc959(const char *data, size_t dlen,
              struct nf_conntrack_man *cmd, char term)
{
    int length;
    u_int32_t array[6];

    length = try_number(data, dlen, array, 6, ',', term);
    if (length == 0)
        return 0;

    cmd->u3.ip =  htonl((array[0] << 24) | (array[1] << 16) |
                    (array[2] << 8) | array[3]);
    cmd->u.tcp.port = htons((array[4] << 8) | array[5]);
    return length;
}

Если посмотреть на команду PORT в моем дампе, то она выглядит так.

PORT 10,11,0,54,-35,183

5ое число у нас отрицательное, vsftpd и pyftplib ругаются на такую команду, что-то вроде illegal PORT, pyftplib я под это дело дело подправил, чтоб он вычислял порт. А вот модуль ядра не ждет в команде ничего кроме цифр, разделителя и конца строки. Поэтому модуль и дропал этот порт.

И ТП raisecom меня еще убеждают, что отрицательные числа там это нормально, раз к виндовому 3Com ftp он конектится.

swelf
() автор топика
Ответ на: комментарий от swelf

Это в raisecom чудаки на букву му.

Тогда какого хрена они 183 как положительное число передают ?

Можно запретит conntrack для адресов таких свитчей через «iptables -t raw -A PREROUTING -p tcp -s X -j CT --notrack» «iptables -t raw -A PREROUTING -p tcp -d X -j CT --notrack»

А через tftp нет проблем ?

vel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.