NAT: статический и динамический

Внутренняя сеть 192.168.10.0/24 использует приватные адреса из диапазона RFC 1918 — они не маршрutизируются в интернете напрямую. Чтобы устройства из этой сети могли выходить наружу, нужен NAT (Network Address Translation) — механизм, который подменяет внутренний адрес на внешний, публичный, при прохождении пакета через границу сети. В этой статье настроим на маршрутизаторе rtr-edge01 оба классических варианта: динамический NAT с перегрузкой портов (PAT) для выхода в интернет и статический NAT для проброса внутреннего сервера наружу. Домен сети — itpages.lab.local.

Разница между статическим и динамическим NAT простая: статический — это постоянное соответствие «один внутренний адрес — один внешний адрес», обычно используется для серверов, которые должны быть доступны извне. Динамический — временное соответствие из пула адресов (или, чаще всего в небольших сетях, из одного внешнего адреса с разными портами через PAT) для исходящих подключений рабочих станций.

Определение внутреннего и внешнего интерфейса

Прежде чем настраивать сами трансляции, IOS нужно явно сказать, какой интерфейс смотрит во внутреннюю сеть, а какой — наружу.

rtr-edge01# configure terminal
rtr-edge01(config)# interface gigabitEthernet 0/0
rtr-edge01(config-if)# ip nat inside
rtr-edge01(config-if)# exit

rtr-edge01(config)# interface gigabitEthernet 0/1
rtr-edge01(config-if)# ip address 203.0.113.10 255.255.255.252
rtr-edge01(config-if)# ip nat outside
rtr-edge01(config-if)# no shutdown
rtr-edge01(config-if)# exit

gigabitEthernet 0/0 смотрит в локальную сеть 192.168.10.0/24 и помечен как ip nat inside, а gigabitEthernet 0/1 с публичным адресом 203.0.113.10, полученным от провайдера, помечен как ip nat outside. Без этих двух команд ни статический, ни динамический NAT работать не будут — это обязательная привязка, которая говорит маршрутизатору, в какую сторону вообще применять трансляцию.

Динамический NAT с перегрузкой (PAT)

В подавляющем большинстве офисных сетей на один внешний адрес выходит множество внутренних устройств одновременно. Для этого используется PAT (Port Address Translation, часто называют просто «NAT overload») — все внутренние адреса транслируются в один внешний, а различаются подключения по номеру порта.

rtr-edge01(config)# access-list 1 permit 192.168.10.0 0.0.0.255
rtr-edge01(config)# ip nat inside source list 1 interface gigabitEthernet 0/1 overload

Список доступа 1 определяет, какие внутренние адреса подлежат трансляции — вся сеть 192.168.10.0/24. Ключевое слово overload и есть то, что превращает обычный динамический NAT в PAT: без него на один внешний адрес мог бы выходить только один внутренний одновременно, что для реальной сети практически бесполезно.

Динамический NAT через пул адресов

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

rtr-edge01(config)# ip nat pool PUBLIC-POOL 203.0.113.10 203.0.113.14 netmask 255.255.255.248
rtr-edge01(config)# ip nat inside source list 1 pool PUBLIC-POOL overload

overload работает и с пулом — в этом случае несколько внешних адресов используются по очереди, а внутри каждого адреса тоже работает трансляция портов, что увеличивает общее количество одновременных исходящих сессий по сравнению с одним внешним адресом.

Статический NAT для внутреннего сервера

Когда внутренний сервер (например, веб-сервер с адресом 192.168.10.50) должен быть доступен из интернета, используется статический NAT — постоянное соответствие внутреннего адреса внешнему.

rtr-edge01(config)# ip nat inside source static 192.168.10.50 203.0.113.11

Теперь любой пакет, приходящий на внешний адрес 203.0.113.11, будет транслироваться маршрутизатором на внутренний адрес 192.168.10.50, и наоборот для исходящего трафика этого сервера. Обрати внимание: для статического NAT нужен отдельный внешний адрес, отличный от того, что используется для PAT — иначе возникнет конфликт трансляций.

Проброс отдельного порта (static NAT with port)

Часто выделять отдельный публичный адрес под каждый внутренний сервис нецелесообразно — можно пробросить конкретный порт на том же внешнем адресе, что используется для PAT.

rtr-edge01(config)# ip nat inside source static tcp 192.168.10.50 443 203.0.113.10 443 extendable
rtr-edge01(config)# ip nat inside source static tcp 192.168.10.51 22 203.0.113.10 2222 extendable

Первая строка пробрасывает HTTPS сервера 192.168.10.50 напрямую на порт 443 внешнего адреса. Вторая — пробрасывает SSH другого сервера (192.168.10.51) не на стандартный 22-й порт снаружи, а на нестандартный 2222-й, что дополнительно снижает шум от автоматических сканеров портов в интернете. Ключевое слово extendable позволяет такому правилу сосуществовать с overload-трансляцией на том же внешнем адресе.

Отладка NAT в реальном времени

Когда таблицы трансляций выглядят правильно, но трафик всё равно не проходит, полезно посмотреть на процесс трансляции в реальном времени. Команда debug — мощный инструмент, но её стоит использовать осторожно на загруженном оборудовании, потому что она заметно повышает нагрузку на процессор.

rtr-edge01# debug ip nat
rtr-edge01# terminal monitor
! после проверки
rtr-edge01# undebug all

Вывод debug ip nat показывает каждую трансляцию по мере её выполнения: исходный адрес и порт, итоговый адрес и порт после NAT. Если при генерации тестового трафика в выводе вообще ничего не появляется — трафик не доходит до правила NAT, и проблему нужно искать раньше, в маршрутизации или в ACL, который определяет, какой трафик подлежит трансляции. Команда undebug all обязательна сразу после диагностики — оставленный включённым debug на боевом маршрутизаторе способен ощутимо просадить производительность при высокой нагрузке.

Влияние времени жизни трансляции на надёжность

Динамические трансляции не живут вечно — по истечении времени простоя они автоматически удаляются из таблицы, освобождая ресурсы маршрутизатора. По умолчанию таймауты в IOS рассчитаны на типичный веб-трафик, но для некоторых приложений (долгие фоновые соединения, специфичные корпоративные сервисы) стандартных значений может не хватать.

rtr-edge01(config)# ip nat translation timeout 86400
rtr-edge01(config)# ip nat translation tcp-timeout 3600
rtr-edge01(config)# ip nat translation udp-timeout 300

Слишком короткий таймаут обрывает долгоживущие, но малоактивные соединения — приложение будет вынуждено переустанавливать связь заново, что не всегда проходит для пользователя незаметно. Слишком длинный таймаут, наоборот, зря удерживает записи в таблице трансляций дольше необходимого. Значения стоит подбирать по факту наблюдений через show ip nat statistics, а не менять вслепую при первых признаках проблем.

Проверка трансляций

rtr-edge01# show ip nat translations
rtr-edge01# show ip nat statistics
rtr-edge01# clear ip nat translation *

show ip nat translations покажет активные таблицы соответствий — inside local (реальный внутренний адрес), inside global (внешний адрес, под которым его видит интернет), а также обратные пары для исходящих подключений. clear ip nat translation * сбрасывает динамические записи трансляции — полезно во время отладки, когда после изменения конфигурации старые записи мешают проверить новую логику. Статические трансляции командой clear не затрагиваются, они постоянны, пока явно не удалены из конфигурации.

Ограничение числа трансляций на клиента

При PAT одно устройство теоретически может открыть тысячи одновременных соединений — например, из-за вредоносного ПО, торрент-клиента или просто некорректно работающего приложения, — и исчерпать таблицу трансляций маршрутизатора, из-за чего перестанут работать соединения у всех остальных пользователей сети. Ограничение количества трансляций на один внутренний адрес снижает этот риск.

rtr-edge01(config)# ip nat translation max-entries all-host 200

Значение стоит подбирать по реальному профилю нагрузки сети — современный браузер с десятком открытых вкладок легко создаёт несколько десятков одновременных соединений, поэтому слишком низкий лимит будет мешать обычной работе. 200 — разумная отправная точка для офисной сети, которую можно скорректировать по факту наблюдений через show ip nat statistics.

NAT и протоколы, чувствительные к трансляции адресов

Не все протоколы одинаково хорошо переживают подмену IP-адреса и порта. Некоторые приложения передают адрес и порт прямо внутри полезной нагрузки пакета (например, часть протоколов VoIP или старые FTP-клиенты в активном режиме) — обычный NAT не трогает эти данные внутри payload, и удалённая сторона получает адрес, который снаружи не существует. Для таких случаев в IOS есть специализированные ALG (Application Layer Gateway), встроенные в сам NAT.

rtr-edge01(config)# ip nat service list 1 sip udp port 5060
rtr-edge01(config)# ip nat service ftp port 21

Для большинства современных протоколов (HTTP, HTTPS, DNS) эта проблема неактуальна — адрес назначения передаётся отдельно от данных, и обычная трансляция работает без дополнительных настроек. Но если в сети встречается FTP в активном режиме, SIP-телефония или другие протоколы с адресами внутри данных, полезно заранее знать, что для них может понадобиться отдельная настройка ALG, а не просто правило NAT.

Частые ошибки и как их избежать

• Не помечены ip nat inside / ip nat outside. Список доступа и команда трансляции настроены правильно, но NAT просто не срабатывает — IOS не понимает, в какую сторону идёт трафик, если интерфейсы не помечены. Это первое, что стоит проверить при «NAT не работает».
• ACL для NAT разрешает слишком много или слишком мало. Список доступа, используемый в ip nat inside source list, определяет, какой трафик вообще транслируется. Слишком широкий ACL (например, permit any) может неожиданно транслировать трафик, который должен идти без NAT — например, трафик по site-to-site VPN, где адреса должны оставаться нетронутыми. Эта проблема разберём подробнее в статье про VPN — там NAT и VPN конфликтуют особенно часто.
• Забыли extendable или использовали один и тот же внешний порт дважды. При проброса нескольких сервисов на один внешний адрес легко случайно указать одинаковый внешний порт для двух разных внутренних серверов — второе правило либо не применится, либо перезапишет первое. Веди список пробросов отдельно от общей конфигурации, чтобы не терять из виду занятые порты.
• Статический NAT конфликтует с overload на том же внешнем адресе. Если статическую трансляцию (ip nat inside source static) без указания портов настроить на тот же внешний адрес, что уже используется в правиле overload, маршрутизатор откажется применить конфигурацию или начнёт вести себя непредсказуемо для части трафика. Для статических трансляций без портов всегда используй отдельный, ничем больше не занятый внешний адрес.

Автор — Команда IT-Pages