@kravam

То есть нас в книжках учат, что если на маршрутизаторе присутствует таблица NAT, согласно которой осуществляется подмена внутреннего локального адреса на внешних локальный, то при прохождении через эту таблицу пакета из внутренней сети во внешнюю мало того, что будет заменён ip-адрес, будет заменён и порт. Причём последний будет УНИКАЛЬНЫМ. У Олиферов:

А они ни хрена не уникальный. Вот я к примеру составил макет сети. Имеется внутренняя сеть с двумя хостами 192.168.2.2 и 192.168.7.2 (они оба слева), есть внешний хост 192.168.3.2 (он справа)

Начнём пинговать (192.168.2.2->192.168.3.2 и 192.168.7.2->192.168.3.2). То есть от хостов пойдут пакеты с указанием портов, откуда они вышли. Эта сущность (номер порта которая) в ICMP пакетах определяется полем SEQ NUMBER. Наша цель сделать так, чтобы с узла 192.168.2.2 и с узла 192.168.7.2 вышли пакты с одинаковыми значениями этого поля. То есть если на момент испытаний с узла 192.168.2.2 вышло 16 пакетов (ну то есть мы просто чё-нибудь пропинговали, неважно что и у нас получилось, что мы в общей сложности отослали куда-нибудь 16 пакетов), то и с узла 192.168.7.2 должно быть выйти столько же пакетов; а если вышло меньше (например, 12), то нужно просто пропинговать какой-нибудь узел (например 192.168.7.2->192.168.3.2), уравняв тем самым количество пакетов, вышедших с каждого из узлов и приступить к испытаниям.

Зайдём в режим симуляции, зайдём на роутер, очистим таблицу NAT:

Так, теперь с каждого из хостов запустим по одному пакету ОДНОВРЕМЕННО на 192.168.3.2 в режиме симуляции. И когда пакеты один за другим пройдёт роутер, обратимся к таблице NAT, вот такая она примерно должна быть:

Красным я выделил то, что должно быть одинаково-мы этого должны добиться и выше я написал как. А вот обведённые синим цветом цифры должны быть уникальны, ну то есть хотя бы в пределах таблицы. Не должно быть двух одинаковых портов согласно теории. А они есть. А теперь смотрите, что получается. Эта таблица на момент, когда с хостов 192.168.2.2 и 192.168.7.2 на хост 192.16.3.2 прошло по одному пакету. Какой пакет прошёл первым, я сказать не берусь, может, строки в таблице сортируются по алфавиту или ещё как (похоже, что сортируются). НО! Самое-то главное. Когда назад пойдёт какой-нибудь пакет, адресованный 192.168.2.2 или 192.168.7.2 он БЕЗУСЛОВНО придёт на 192.168.2.2, вот в чём дело!

Ещё раз, если сейчас в обратном направлении пойдёт пакет на узел, к примеру, 192.168.7.2, он, согласно таблице, попадёт на 192.168.2.2! И в CPT так и произошло! Обратно пошёл пакет, предназначенный узлу 192.168.7.2. но он охренительно завернул на 199.168.2.2! Как я определил пакет? А по цвету. (В результате на один узел вернулось 5 пакетов, а на другой 3, но это в режиме симуляции)

А теперь представьте, что в реале пакет, предназначенный узлу 192.168.2.2 на обратном пути где-нибудь пропал или ещё что-то в этом роде. Хост 192.168.2.2 об этом инфы не получит, он будет считать, что связь установлена, хотя на самом деле к нему придёт пакет, предназначенный другому узлу (192.168.7.2)

Решилось бы, если порты, нарисованные синим цветом действительно были уникальны в пределах таблицы. Но они не уникальны. Cтранно, необъяснимо и вредно. Ну и как же теперь быть? Спасибо, кто откликнется.

Вложения

NAT.rar (10.6 Кб, 9 просмотров)

0

@kravam

Случайно нашёл ошибку, она концептуальна. Эффект, который нужен мне достигается применением списка доступа. Ну то есть надо использовать способ "dinamic NAT" и тогда назначенные порты будут действительно уникальными. Если назначать адрес адресу ("statick NAT"), как делал я, тогда, наверное, надо придерживаться правила: каждому адресу УНИКАЛЬНЫЙ адрес. А я двум адресам (192.168.2.2 и 192.168.7.2) назначил один и тот же адрес 192.168.6.1, за что и поплатился.

0

@corlovito

в принципе в жизни наверное трудно себе представить схему в которой делался бы статический nat один inside global в несколько inside local, что то даже не представлю себе такое в жизни да и в пакет трасер косяков полно чтобы полностью доверять его поведению

0