Назад | Перейти на главную страницу

Как называется эта концепция маршрутизации? Проблемы с получением дополнительных сведений о маршрутизации LAN-to-WAN-to-LAN

В простой сети мои журналы nginx будут указывать адрес шлюза (10.0.0.1) вместо адреса внутреннего клиента (10.0.0.19), когда я использую DNS (например, foo.com) для доступа к серверу внутри локальной сети.

Я пытаюсь прочитать об этом больше, но не знаю, как это называется. Есть ли термин для обозначения «маршрутизатор заметил, что вы пытались подключиться за пределами сети, к ресурсу внутри сети, и заменил ваш IP-адрес на адрес шлюза»? Если это стандартная вещь, есть ли статьи, где я могу почитать больше? Я не совсем понимаю, почему это происходит, но это похоже на «особенность» маршрутизатора, названия которой я не знаю.

В качестве побочного эффекта того, что адрес FROM является шлюзом, ответы отправляются маршрутизатору (затем обратно к локальному клиенту), а не просто с использованием коммутатора. Это не очень хорошо, потому что коммутатор LAN имеет гораздо более высокую пропускную способность, чем маршрутизатор, из-за того, что маршрутизатор выполняет функции брандмауэра.

Это довольно простая настройка сети:


WAN - (70.x)Router(10.0.0.1) - Switch - (10.0.0.3)  Server
                                      - (10.0.0.19) Client

На компьютере внутри локальной сети (клиент 10.0.0.19) я делаю запрос на foo.com. DNS для foo.com указывает на интерфейс WAN на маршрутизаторе, который имеет настройку переадресации порта на сервер. nginx внутри сервера показывает, что запрос поступает от 10.0.0.1 вместо 10.0.0.19.

Если запрос исходит из WAN, то в журналах nginx отображаются ожидаемые данные.

Если это уместно, маршрутизатор - это универсальная универсальная группа безопасности с коммутатором универсальной сети позади.

«Маршрутизатор заметил, что вы пытаетесь подключиться за пределами сети к ресурсу внутри сети, и заменил ваш IP-адрес на адрес шлюза»?

Это вариант NAT (трансляция сетевых адресов), который называется NAPT (трансляция сетевых адресов и портов). Некоторые называют это PAT (преобразование адресов порта), потому что крупный поставщик называет это так, но RFC 2663, Терминология и соображения транслятора сетевых адресов IP (NAT) объясняет это. Когда вы хотите, чтобы он выполнял обратную петлю внутри, это называется разными вещами в зависимости от поставщика (маршрутизация шпильки, отражение NAT и т. Д.), И это очень расточительно для ресурсов маршрутизатора.

Существуют различные ресурсы, в том числе RFC. Например, RFC 3022, Традиционный преобразователь сетевых адресов IP (традиционный NAT) имеет Раздел 2.2. Обзор NAPT:

2.2. Обзор NAPT

Скажем, у организации есть частная IP-сеть и WAN-соединение с поставщиком услуг. Маршрутизатору-заглушке частной сети назначается глобально действующий адрес на канале WAN, а остальные узлы в организации имеют IP-адреса, которые имеют только локальное значение. В таком случае узлам частной сети может быть разрешен одновременный доступ к внешней сети с использованием одного зарегистрированного IP-адреса с помощью NAPT. NAPT позволяет отображать кортежи типа (локальные IP-адреса, номер локального порта TU) в кортежи типа (зарегистрированный IP-адрес, назначенный номер порта TU).

Эта модель соответствует требованиям большинства групп малого офиса для домашнего офиса (SOHO) для доступа к внешней сети с использованием IP-адреса, назначенного одним поставщиком услуг. Эта модель может быть расширена для разрешения входящего доступа путем статического сопоставления локального узла на каждый порт TU службы зарегистрированного IP-адреса.

В примере, показанном на рисунке 3 ниже, заглушка A внутренне использует блок адреса класса A 10.0.0.0/8. WAN-интерфейсу тупикового маршрутизатора поставщик услуг назначает IP-адрес 138.76.28.4.

                                 \ | /
                               +-----------------------+
                               |Service Provider Router|
                               +-----------------------+
                             WAN |
                                 |
             Stub A .............|....
                                 |
     ^{s=138.76.28.4,sport=1024, |  v{s=138.76.29.7, sport = 23,
     ^ d=138.76.29.7,dport=23}   |  v d=138.76.28.4, dport = 1024}
                     +------------------+
                     |Stub Router w/NAPT|
                     +------------------+
                       |
                       |  LAN
 --------------------------------------------
    |        ^{s=10.0.0.10,sport=3017, |  v{s=138.76.29.7, sport=23,
    |        ^ d=138.76.29.7,dport=23} |  v d=10.0.0.10, dport=3017}
    |                                  |
   +--+      +--+                    +--+
   |--|      |--|                    |--|
  /____\    /____\                  /____\
 10.0.0.1  10.0.0.2   .....        10.0.0.10

  Figure 3: Network Address Port Translation (NAPT) Operation

Когда тупиковый узел A 10.0.0.10 отправляет пакет telnet на узел 138.76.29.7, он использует глобально уникальный адрес 138.76.29.7 в качестве пункта назначения и отправляет пакет своему основному маршрутизатору. Маршрутизатор-заглушка имеет статический маршрут для подсети 138.76.0.0/16, поэтому пакет пересылается в WAN-канал. Однако NAPT преобразует кортеж адреса источника 10.0.0.10 и порта TCP 3017 источника в заголовках IP и TCP в глобально уникальный 138.76.28.4 и однозначно назначенный порт TCP, например 1024, перед пересылкой пакета. Пакеты на обратном пути проходят аналогичные преобразования адресов и портов TCP для целевого IP-адреса и целевого TCP-порта. Еще раз обратите внимание, что это не требует изменений хостов или маршрутизаторов. Перевод полностью прозрачен.

В этой настройке разрешены только сеансы TCP / UDP, и они должны происходить из локальной сети. Однако есть службы, такие как DNS, которые требуют входящего доступа. Могут быть и другие службы, для которых организация желает разрешить доступ к входящим сеансам. Можно статически настроить известную службу порта TU [RFC 1700] на тупиковом маршрутизаторе, чтобы она была направлена ​​на определенный узел в частной сети.

Помимо сеансов TCP / UDP, сообщения ICMP, за исключением сообщения типа REDIRECT, также могут отслеживаться маршрутизатором NAPT. Пакеты типа запроса ICMP транслируются аналогично пакетам TCP / UDP, поскольку поле идентификатора в заголовке сообщения ICMP будет однозначно сопоставлено с идентификатором запроса зарегистрированного IP-адреса. Поле идентификатора в сообщениях запроса ICMP задается отправителем запроса и возвращается без изменений в ответном сообщении от ответчика запроса. Таким образом, кортеж (локальный IP-адрес, локальный идентификатор запроса ICMP) сопоставляется с кортежем (зарегистрированный IP-адрес, назначенный идентификатор запроса ICMP) маршрутизатором NAPT, чтобы однозначно идентифицировать запросы ICMP всех типов с любого из локальных узлов. Модификации сообщений об ошибках ICMP обсуждаются в следующем разделе, так как они включают изменения полезной нагрузки ICMP, а также заголовков IP и ICMP.

В настройке NAPT, где зарегистрированный IP-адрес совпадает с IP-адресом WAN-интерфейса тупикового маршрутизатора, маршрутизатор должен обязательно различать сеансы запросов TCP, UDP или ICMP, инициированные им самим, и сеансы, исходящие от узлов на локальная сеть. Предполагается, что все входящие сеансы (включая сеансы запросов TCP, UDP и ICMP) направляются на маршрутизатор NAT в качестве конечного узла, если целевой порт службы статически не сопоставлен с другим узлом в локальной сети.

Сеансы, отличные от типа запроса TCP, UDP и ICMP, просто не разрешены с локальных узлов, обслуживаемых маршрутизатором NAPT.

Правильный способ - использовать что-то вроде раздельного DNS, чтобы ваш внутренний трафик никогда не попадал на маршрутизатор, чтобы вы не тратили впустую полосу пропускания интерфейса LAN (в обоих направлениях), и вы не использовали ЦП и ОЗУ маршрутизатора для трафика, который никогда не должен покинуть вашу сеть.