none
RRAS, NAT и маршрутизация ICMP RRS feed

  • Вопрос

  • Коллеги, уже не первый раз натыкаюсь на подобную проблему с ping, но первый раз (благодаря полной виртуализации) имею возможность увидеть, что же происходит на самом деле.

    Итого, суть проблемы:

    ping 213.180.193.11 /n 1 /l 1400
    
    Обмен пакетами с 213.180.193.11 по с 1400 байтами данных:
    Ответ от 213.180.193.11: число байт=1400 время=12мс TTL=56
    
    ping 213.180.193.11 /n 1 /l 1472
    
    Обмен пакетами с 213.180.193.11 по с 1472 байтами данных:
    Ответ от 213.180.193.11: число байт=1472 время=12мс TTL=56
    
    ping 213.180.193.11 /n 1 /l 1474
    
    Обмен пакетами с 213.180.193.11 по с 1474 байтами данных:
    Превышен интервал ожидания для запроса.
    
    Статистика Ping для 213.180.193.11:
        Пакетов: отправлено = 1, получено = 0, потеряно = 1
        (100% потерь)

    Ping выполняю с рабочей станции в локальной сети. Пингую внешний ресурс (в примере - yandex.ru). Но та же проблема с любым внешним ресурсом.

    Подключение к интернету: маршрутизатор на базе windows 2012 standard server + rras + NAT. на rras PPPoE соединение к провайдеру.

    MTU: в локальной сети - везде 1500. на интерфейсе провайдера (PPPoE): 1480.

    Сразу обращаю внимание: флаг запрета фрагментации /f не ставил.

    Причину подобного поведения выяснил, но как лечить не знаю. Поставил Network Monitor на хост, чтобы "увидеть" трафик, который уходит по PPPoE интерфейсу в сторону провайдера. В общем - не суть важно, считайте, что "внешний" порт отзеркалил, и посмотрел его Network Monitor'ом. Картина маслом:

    3	www.nice-tour.nov.ru	213.180.193.11	Echo Request Message, From 81.9.24.103 To 213.180.193.11	ICMP	{IPv4:36, PPPoE:1}
    4	213.180.193.11	www.nice-tour.nov.ru	Echo Reply Message, From 213.180.193.11 To 81.9.24.103	ICMP	{IPv4:36, PPPoE:1}
    5	www.nice-tour.nov.ru	213.180.193.11	Echo Request Message, From 81.9.24.103 To 213.180.193.11	ICMP	{IPv4:36, PPPoE:1}
    6	www.nice-tour.nov.ru	213.180.193.11		IPv4	{IPv4:36, PPPoE:1}
    7	213.180.193.11	www.nice-tour.nov.ru	Echo Reply Message, From 213.180.193.11 To 81.9.24.103	ICMP	{IPv4:36, PPPoE:1}
    8	213.180.193.11	www.nice-tour.nov.ru		IPv4	{IPv4:36, PPPoE:1}
    9	192.168.100.112	213.180.193.11	Echo Request Message, From 192.168.100.112 To 213.180.193.11	ICMP	{IPv4:258, PPPoE:1}
    10	192.168.100.112	213.180.193.11		IPv4	{IPv4:258, PPPoE:1}
    11	192.168.100.112	213.180.193.11		IPv4	{IPv4:258, PPPoE:1}

    Итого: запрос, и ответ. При этом в запросе адрес отправителя заменён на внешний адрес шлюза (81.9.24.103). Ответ прекрасно вернулся, всё в порядке.

    Второй пример (пакеты 5, 6 и7): на сервер (шлюз) пакет пришёл нефрагментированным (MTU внутри 1500), но на шлюзе возникла необходимость фрагментации (MTU 1480), которая успешно выполнена (5 и 6ой пакеты). Ответ успешно вернулся (7ой пакет). Но! в запросе опять адрес заменён на внешний адрес шлюза.

    И третий пример (пакеты 9, 10 и 11): пакет необходимо фрагментировать уже на клиенте. Клиент это успешно сделал (получил 2 фрагмента). Но так как MTU на шлюзе ещё меньше (1480), шлюз так же фрагментирует уже полученные фрагменты. Как мы видим - вполне успешно (пакеты 9, 10 и 11). НО!!! в отправляемых пакетах адрес отправителя уже не подменён на внешний адрес шлюза (NAT не выполнен!)! В результате - естественно, ответа нет.

    Естественно, пробовал MTU в LAN уменьшать. И 1480, и 1400, и 1000 (ну уже ради эксперимента) - результаты ещё хуже. Суть в следующем: как только на шлюз поступает УЖЕ ФРАГМЕНТИРОВАННЫЙ пакет, шлюз его отправляет дальше (при этом не важно - если его ещё раз нужно фрагментировать - фрагментирует, не нужно - не фрагментирует), НО АДРЕС ОТПРАВИТЕЛЯ СОБСТВЕННЫМ АДРЕСОМ УЖЕ НЕ ПОДМЕНЯЕТ (NAT на фрагментированных ICMP пакетах RRAS не выполняет)!

    На внешнем интерфейсе шлюза поднят NAT. Работает замечательно.

    Итого, вопрос: почему ICMP echo request фрагментированный так некорректно пересылается в Windows Server RRAS NAT (сейчас - 2012, но наблюдал и ранее, с windows 2000 server)? И как это исправить? Или я что-то неправильно делаю? Возможно, где-либо требуется "включить" явную поддержку пересылки (NAT) фрагментированных ICMP пакетов?

    P.P.S> при выполнении ping yandex.ru /l 2000 непосредственно со шлюза результат положительный. Да, отправляемый пакет естественно фрагментируется, но адрес в нём - внешний "белый" адрес внешнего интерфейса шлюза. Проблема именно при ping /l 1473+ из LAN, и она - из за неподмены адреса отправителя на шлюзе.


    С Уважением, Бетке Сергей Сергеевич.


    19 октября 2011 г. 6:37

Все ответы

  • Наткнулся на одну статью How NAT Handles ICMP Fragments

    Но она - о CISCO. но суть проблемы, я думаю, ясна из статьи. Возможно - проблема в реализации NAT?

    Черновик требования к NAT в связи с ICMP: NAT Behavioral Requirements for ICMP protocol. На сегодняшний день есть предположение, что NAT на RRAS "игнорирует" (не выполняет NAT) фрагментированные ICMP пакеты в связи со "сложностью" идентификации последовательности icmp фрагментов. Так ли это?
    13 августа 2013 г. 8:48
  • собственно - up.

    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru

    21 августа 2013 г. 14:58
  • Интересная ситуация. Не нашли решение?

    Чем дальше в лес - тем третий лишний..

    15 января 2014 г. 8:56
  • К сожаление - нет до сих пор. Это поведение, судя по всему - "особенность" реализации NAT. Безусловно, NAT к ICMP прямого отношения не имеет, и для ICMP требуется явная "поддержка" со стороны разработчика. Видимо - её нет.

    С Уважением, Бетке Сергей Сергеевич, http://sergey-s-betke.blogs.novgaro.ru

    15 января 2014 г. 14:15
  • А с разработчиками удалось связаться по этому поводу?

    Чем дальше в лес - тем третий лишний..

    5 марта 2014 г. 4:03
  • В рамках бесплатной поддержки этот вопрос не решили, а платную поддержку для этих целей использовать жалко, однако. К тому же, явно складывается впечатление, что о реализации подобия NAT для ICMP трафика в MS видимо не задумывались (хотя и в Linux, и в cisco этот вопрос решён). В общем то, MS нигде и не заявляет о поддержке NAT для ICMP (это ведь не совсем NAT, точнее - совсем не NAT, а его аналог конкретно для ICMP).

    С Уважением, Бетке Сергей Сергеевич.

    12 марта 2014 г. 8:00