Урок 8 — Маршрутизация и NAT

Как пакет из твоего ноутбука находит дорогу до сервера на другом континенте? Кто решает, в какую сторону его толкать? И почему миллионы устройств за домашним роутером могут жить под одним публичным IP? Финал серии — самые сетевые из всех сетевых тем.

1. Зачем нужна маршрутизация

Когда твой пакет летит из дома в Лондоне на сервер в Франкфурте, он проходит через 10-20 промежуточных устройств. Никто из них не знает «весь интернет». Каждый знает только: «если адрес такой — толкаю в эту сторону».

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

2. Шлюз по умолчанию

Когда твой ноутбук хочет отправить пакет, он смотрит:

1. Получатель в моей подсети? Тогда отдам напрямую (через MAC через коммутатор)
2. Не в моей? Тогда отдам своему шлюзу по умолчанию (default gateway) и пусть он разбирается

Шлюз — это обычно твой роутер. У него один интерфейс смотрит в твою LAN, другой — наружу (к провайдеру).

# Узнать свой шлюз
ip route                      # Linux
# default via 192.168.1.1 dev wlan0
# 192.168.1.0/24 dev wlan0 ...

netstat -rn                   # старый универсальный
# 0.0.0.0   192.168.1.1  ...

Здесь 0.0.0.0/0 или default — это «всё, что не подходит ни под одно другое правило». Шлюз — 192.168.1.1.

3. Таблица маршрутизации

У каждого устройства (включая твой ноутбук) есть routing table. Формат: «если адрес назначения подходит под этот CIDR — отправь в этот интерфейс через этот next-hop».

Логика выбора:

1. «Хочу на 192.168.1.50?» — подходит под 192.168.1.0/24 → отдаю напрямую через wlan0
2. «Хочу на 10.20.5.10?» — подходит под 10.20.0.0/16 → отдаю через VPN tun0
3. «Хочу на 93.184.216.34?» — не подходит ни под что → берётся default, отдаю шлюзу 192.168.1.1

На сервере (роутере, фаерволе, ALB) таблица сложнее, но принцип тот же.

4. Как пакет идёт «по миру» — hop-by-hop

Каждое промежуточное устройство называется hop (прыжок). Пакет от тебя до сервера на другом континенте проходит 10-20 хопов.

На каждом хопе:

• Уменьшается поле TTL (Time To Live) в IP-заголовке — на 1
• Если TTL стал 0 — пакет отбрасывается, отправителю шлётся ICMP «time exceeded»

TTL — это защита от вечно блуждающих пакетов в случае «петли» в маршрутизации. И именно благодаря TTL работает traceroute — он намеренно отправляет пакеты с TTL=1, TTL=2, TTL=3..., и каждый умирающий пакет на N-ном хопе отвечает «я хоп номер N». Так строится карта пути.

5. NAT — как миллионы за одним IP

В уроке 2 мы видели, что у Алисы и Боба дома одинаковые приватные IP (192.168.1.50), но интернет видит только один публичный IP их роутера. Как это работает?

NAT — Network Address Translation. Роутер «подменяет» адреса при выходе и обратно.

То, что показано на схеме — это PAT (Port Address Translation) или NAT Overload. Самый частый вид. Роутер запоминает не только адрес, но и порт — поэтому из одного публичного IP может выходить тысячи устройств одновременно.

Плюсы NAT:

• Экономия адресов — один публичный IP на всю сеть
• «Невидимость» внутренних устройств — снаружи их адресов не видно
• Естественный фаервол — если кто-то не сначала вышел, ему ничего не придёт

Минусы:

• Снаружи трудно обратиться к устройству внутри — нужен port forwarding
• Усложняет P2P-протоколы (требует STUN / TURN / hole punching)
• В Cloud — отдельная биллинговая позиция (NAT Gateway $$ в AWS)

6. Port forwarding и DNAT

Если ты хочешь, чтобы кто-то извне мог достучаться до твоего сервера, который сидит за NAT (например, домашний NAS), — настраиваешь port forwarding.

На роутере: «приходит пакет на мой публичный IP, порт 8080 — переадресуй на 192.168.1.100:80».

Это разновидность NAT — DNAT (Destination NAT). Обратная задача — SNAT (Source NAT, что мы видели в обычном NAT).

7. Маршрутизация в облаке (VPC)

В AWS/GCP/Azure ты будешь конфигурировать те же концепции, только через API. Главные понятия:

8. Дебаг — ping, traceroute, mtr

ping

Отправляет ICMP echo-пакеты и измеряет, кто отвечает за сколько мс.

ping example.com
ping -c 4 8.8.8.8           # 4 пакета и выход

Если ping не идёт — проблема либо в сети до хоста, либо хост блокирует ICMP. На AWS по умолчанию SG не пропускает ICMP — не пугайся.

traceroute

Показывает каждый хоп на пути. Это «карта пути».

traceroute example.com       # Linux/macOS
tracert example.com          # Windows

Вывод покажет 5-20 строчек — каждая строчка это промежуточный роутер с задержкой до него. Если на каком-то хопе обрыв — там и проблема.

mtr

Лучший инструмент. Сочетает ping + traceroute в реальном времени, показывает потери на каждом хопе.

sudo apt install mtr
mtr example.com

Если на конкретном хопе видишь 80% потерь — там «узкое горлышко». Часто проблема не у тебя и не у получателя, а где-то посередине у транзитного провайдера.

9. Что с этим делает DevOps / DevSecOps

10. Чек-лист «понимаю это»

11. Финальный плейбук: «нет интернета» — весь путь в одном алгоритме

Это выпускной экзамен трека, упакованный в рабочий инструмент. Ситуация, знакомая каждому: «интернет не работает». За этой фразой скрывается десяток разных поломок на разных слоях — и теперь у тебя есть знания, чтобы за пять минут найти нужный. Иди строго по шагам, снизу вверх: каждый шаг проверяет один слой и опирается на один из пройденных уроков.

12. Задачи — реши сам (ответы спрятаны)

Что дальше