Уже второй раз натыкаюсь в железяках двух довольно больших фирм с багом, вызванным необоснованными предположениями касательно TCP/UDP source port. Как, КАК они это делают???
Не, таблицы адресации портов зашиваются. Так быстрее. Раньше их писали "как в первый раз", а сейчас "привыкли". Вот и ошибаются... Сложность и возможности техники выросли, а надёжность падает. У меня в институте уже вторая перемена современных 64–битных компов. Летят... А рядышком тихонько пашут "постоянные" третьи пни... :)
Ну, там хитрый был случай. В принципе, FTP в active mode требует, чтобы использовался source port 20, так что тот факт, что nortel делают PAT в одну сторону правильно, а в обратную заменяют порт (вне зависимости от его настоящего значения) на 20-й, как бы, просителен (по крайней мере, понятно, почему их проверки этого не засекли: ИХ сервер, видимо, дейсвтительно работает в соответствии с RFC).
Гм... Может быть, это такая защита FTP протокола? В обратную сторону он восстанавливает этот номер? Точнее, вот какой сценарий: внутри сервер использует другой source port (например, потому что у него стоит несколько виртуальных серверов), но снаружи все выглядит, как будто это стандартный active mode FTP?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
Не, таблицы адресации портов зашиваются. Так быстрее. Раньше их
писали "как в первый раз", а сейчас "привыкли". Вот и ошибаются...
Сложность и возможности техники выросли, а надёжность падает. У
меня в институте уже вторая перемена современных 64–битных компов.
Летят... А рядышком тихонько пашут "постоянные" третьи пни... :)
no subject
а откуда они берут тогда source ports?
no subject
no subject
и как оно вообще срабатывает?!.
no subject
no subject
no subject
no subject