L3/L4 NAT, ACL, firewall — безопасность на сетевом уровне

Этот модуль — про то, как сеть переписывает адреса (NAT) и решает, что пропустить, а что выбросить (ACL, firewall). Это повседневная работа инженера и прямой мост в безопасность и облако: Security Groups в AWS, iptables/nftables в Linux, Network Policies в Kubernetes — всё это родом отсюда.

Что узнаешь

Зачем нужен NAT и какие бывают виды: static, dynamic, PAT (overload)
SNAT против DNAT — кто и зачем переписывает
Hairpin NAT (NAT loopback) — почему «изнутри по внешнему IP не работает»
Что NAT ломает и почему это не безопасность
ACL: standard, extended, named; порядок правил и неявный deny
Wildcard-маски — как их читать (это не маска подсети!)
Stateful firewall: чем он умнее ACL, таблица соединений
Zone-based firewall и Control Plane Policing (CoPP)
Мост в DevOps: iptables/nftables, conntrack, AWS SG/NACL, k8s NetworkPolicy

1. Зачем нужен NAT

IPv4-адреса закончились. Внутри компаний используют приватные диапазоны RFC1918 (10/8, 172.16/12, 192.168/16), которые не маршрутизируются в интернете. Чтобы тысячи внутренних хостов вышли наружу через горстку публичных адресов, на границе их адреса транслируются — это и есть NAT (Network Address Translation).

Вид NAT	Что делает	Где
Static NAT	1:1 фиксированно (внутр. IP ↔ внешн. IP)	сервер должен быть доступен извне по постоянному адресу
Dynamic NAT	из пула внешних адресов, по мере надобности	редко; когда внешних адресов почти столько же
PAT / NAT overload ⭐	много внутр. → один внешн. IP, различая по портам	99% домашних и офисных выходов в интернет

PAT (overload): сотни хостов выходят через один публичный IP, различаясь портами

Роутер помнит, какой ответ кому вернуть, по уникальной паре внешний-IP:порт. Это и есть «overload».

2. SNAT против DNAT

SNAT (Source NAT)

Переписывает адрес источника. Применяется к трафику изнутри наружу: «спрячь приватный src за публичный». PAT — это разновидность SNAT.

DNAT (Destination NAT)

Переписывает адрес назначения. Применяется к трафику снаружи внутрь: «запрос на публичный IP:443 переадресуй на внутренний веб-сервер». Это port-forwarding / publish сервиса.

Запомни связку: выходишь в интернет → SNAT (прячем источник). Публикуешь сервис наружу → DNAT (перенаправляем назначение). В облаке: NAT Gateway = SNAT, Load Balancer / Elastic IP на инстанс = DNAT.

3. Hairpin NAT — «изнутри по внешнему IP не открывается»

Классическая боль: снаружи сайт https://203.0.113.10 работает, а из внутренней сети по этому же публичному адресу — нет. Причина: пакет идёт хост → роутер → и должен «развернуться обратно» внутрь (DNAT) и при этом подмениться источник (SNAT), иначе сервер ответит напрямую внутреннему хосту, минуя NAT, и сессия не сойдётся. Решение — hairpin NAT (NAT loopback): роутер делает и DNAT, и SNAT для такого «разворота».

Hairpin: пакет «разворачивается» на NAT-устройстве (форма шпильки)

Лучше вообще не ходить наружу за «своими» — используй split-DNS (внутренний DNS отдаёт приватный IP).

4. Что NAT ломает и почему это НЕ безопасность

End-to-end связность. Входящие соединения к хосту за NAT невозможны без проброса/DNAT. Боль для P2P, VoIP, игр → отсюда STUN/TURN/ICE и hole punching.
Протоколы с IP внутри payload (FTP active, SIP) — NAT должен «залезать» в данные (ALG), что хрупко.
Логи и атрибуцию — за одним публичным IP сотни хостов.

важно для собеса NAT — это НЕ firewall. Да, побочно он скрывает внутренние адреса, но защищает не NAT, а сопутствующая stateful-логика. Полагаться на NAT как на защиту — ошибка. Тем более в IPv6, где NAT обычно не нужен — там защищает именно firewall.

5. ACL — список контроля доступа

ACL (Access Control List) — упорядоченный список правил «permit/deny» по полям пакета. Роутер проверяет пакет правилами сверху вниз и применяет первое совпавшее — остальные не смотрит. В конце любого ACL — невидимый deny any: что явно не разрешено, то запрещено.

Тип ACL	По чему фильтрует
Standard (1–99)	только source IP
Extended (100–199)	source+dest IP, протокол, порты, флаги — полноценно
Named	то же, но с именем (читаемо, можно редактировать по строкам)

ACL обрабатывается сверху вниз, до первого совпадения

Порядок правил критичен: специфичное — выше, общее — ниже. Иначе правило «никогда не сработает».

Wildcard-маска — это НЕ маска подсети

ACL использует wildcard-маску — по сути «инвертированную» маску подсети. 0 = бит должен совпасть, 1 = бит неважен. Для /24 маска подсети 255.255.255.0, а wildcard — 0.0.0.255. Удобный трюк: wildcard = 255.255.255.255 − маска подсети.

Хочу описать	Wildcard
один хост `10.0.0.5`	`0.0.0.0` (или ключевое слово `host`)
вся /24 `10.0.0.0`	`0.0.0.255`
любой адрес	`255.255.255.255` (или `any`)

# named extended ACL: пускаем только web к серверу, блок гостевой сети, остальное разрешено R1(config)# ip access-list extended EDGE-IN R1(config-ext-nacl)# permit tcp any host 10.0.0.10 eq 443 R1(config-ext-nacl)# permit tcp any host 10.0.0.10 eq 80 R1(config-ext-nacl)# deny ip 192.168.66.0 0.0.0.255 any R1(config-ext-nacl)# permit ip any any R1(config)# interface gi0/0 R1(config-if)# ip access-group EDGE-IN in # применить на вход интерфейса

Где применять extended ACL? Классическое правило: extended — ближе к источнику (режем мусор сразу), standard — ближе к назначению (т.к. фильтрует только по src и слишком рано отрезал бы лишнее).

6. Stateful firewall — умнее, чем ACL

Обычный ACL без памяти: смотрит каждый пакет отдельно. Чтобы разрешить «исходящий запрос + ответ на него», пришлось бы вручную открывать обратные порты — дыра. Stateful firewall ведёт таблицу соединений (conntrack): разрешил исходящее соединение — ответный трафик пропускается автоматически, потому что он «принадлежит установленной сессии».

Stateful: ответ проходит, потому что сессия уже в таблице

Это фундамент любого современного firewall — и Cisco ASA/ZBFW, и Linux iptables/nftables, и облачных SG.

Zone-Based Firewall (ZBFW) и CoPP

Zone-based firewall — современная модель Cisco: интерфейсы группируются в зоны (inside, outside, dmz), а политика описывает, что разрешено между парами зон. По умолчанию между зонами — запрет. Намного чище, чем развешивать ACL по интерфейсам.

CoPP (Control Plane Policing) — отдельная защита: ограничивает трафик, идущий на сам процессор роутера (CPU): OSPF/BGP-hello, SSH, SNMP, ICMP к роутеру. Без CoPP флуд на control plane может «положить» устройство, даже если оно справляется с транзитом. Это часть защиты инфраструктуры.

7. Мост в DevOps — здесь начинается твоя security-карьера

Это самый «переносимый» модуль трека: те же концепции ты увидишь каждый день в облаке и Linux.

Сетевой концепт	Аналог в DevOps
Stateful firewall / conntrack	Linux iptables/nftables (`conntrack`), firewalld
SNAT/PAT	AWS NAT Gateway, Linux `MASQUERADE`, Docker bridge NAT
DNAT / port-forward	k8s Service/NodePort, LoadBalancer, `iptables -j DNAT`
ACL (stateless)	AWS Network ACL (на уровне subnet, stateless!)
Stateful allow-list	AWS Security Group (stateful, per-ENI)
Zone policy	k8s NetworkPolicy (что какому поду можно)

# Linux: PAT (как роутер) — MASQUERADE $ iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE # Linux: stateful allow — пускаем ответы established (тот же conntrack) $ iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT $ iptables -A INPUT -p tcp --dport 443 -j ACCEPT $ iptables -A INPUT -j DROP # неявный deny, как в ACL # смотрим таблицу соединений (как show в firewall) $ conntrack -L

🌉 Прямая дорога в DevSecOps

Понял ACL и stateful firewall здесь — понимаешь AWS Security Groups (stateful) против NACL (stateless), знаешь, почему SG достаточно открыть только входящий порт, а NACL — оба направления. Это буквально вопросы с собеседований по облаку.

8. Вопросы с собеседования

❓ В чём разница SNAT и DNAT?

SNAT переписывает источник (выход наружу, прячем приватный IP). DNAT — назначение (публикация сервиса извне, port-forward). PAT — это SNAT с различением по портам.

❓ Stateless ACL против stateful firewall?

ACL смотрит каждый пакет отдельно (для ответа надо открывать обратный порт вручную). Stateful ведёт таблицу соединений и пропускает ответный трафик автоматически. AWS NACL = stateless, Security Group = stateful — классический вопрос.

❓ Что в конце каждого ACL?

Невидимый deny any. Что явно не разрешено — запрещено. Поэтому хотя бы одно permit обязательно, иначе ACL заблокирует весь трафик.

❓ NAT — это безопасность?

Нет. NAT транслирует адреса; «скрытие» внутренних IP — побочный эффект. Защищает stateful-логика/firewall, а не сам NAT. В IPv6 NAT обычно не нужен — защищает firewall.

9. Частые ошибки джунов

ошибка 1 Неверный порядок ACL. Общее правило permit ip any any стоит выше специфичного deny — и deny никогда не срабатывает. Специфичное — наверх.

ошибка 2 Забыли неявный deny. Написали один permit — и заблокировали всё остальное, включая нужное (DNS, ответы). Всегда продумывай, что попадёт под финальный deny.

ошибка 3 Путают wildcard и маску подсети. Пишут 255.255.255.0 вместо 0.0.0.255 — ACL ловит не то. Wildcard инвертирован: 0 = совпасть, 1 = неважно.

ошибка 4 Полагаются на NAT как на защиту. Открыли проброс «на всякий» — и сервис торчит наружу без firewall. NAT не фильтрует намерения.

ошибка 5 Забыли про CoPP. Флуд на сам роутер (ICMP/SSH/SNMP) грузит CPU, и устройство «тупит», хотя транзит идёт. Защищай control plane отдельно.

Ключевое за этот урок

NAT транслирует адреса: static 1:1, dynamic из пула, PAT/overload — много→один по портам (99% случаев).
SNAT — прячем источник (выход наружу); DNAT — переписываем назначение (публикация/port-forward).
Hairpin NAT — «разворот» для доступа изнутри по внешнему IP; лучше решать split-DNS.
NAT — НЕ firewall; ломает end-to-end, P2P, протоколы с IP в payload.
ACL: сверху вниз, первое совпадение, в конце невидимый deny; standard (src) / extended (всё) / named.
Wildcard-маска инвертирована: 0 = совпасть, 1 = неважно. /24 → 0.0.0.255.
Stateful firewall ведёт таблицу соединений — ответ проходит автоматически; ZBFW — политика между зонами.
CoPP защищает CPU/control plane от флуда на сам роутер.
В DevOps это iptables/nftables+conntrack, NAT Gateway, AWS SG (stateful) vs NACL (stateless), k8s NetworkPolicy.