Туннелирование

Что такое туннелирование

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

Аналогия ровно из названия: письмо кладут в конверт и отправляют обычной почтой. Почта везёт конверт и читает адрес на конверте. На той стороне конверт вскрывают и достают исходное письмо, которое дальше едет по своим правилам.

Шаги всегда одни и те же:

1. Инкапсуляция   исходный пакет + новый заголовок → пакет-переносчик
2. Транспорт      сеть везёт пакет-переносчик как обычный трафик
3. Декапсуляция   на выходе заголовок снимается, исходный пакет идёт дальше

Зачем это нужно

• Связать сети, между которыми нет прямой маршрутизации — две частные подсети через интернет, то есть site-to-site VPN.
• Перенести протокол через чуждую сеть — IPv6 через IPv4-only участок, кадры Ethernet через маршрутизируемую L3-сеть.
• Добавить шифрование поверх открытого протокола — приложение не меняли, но по сети трафик идёт внутри зашифрованного туннеля.
• Построить overlay — виртуальную сеть поверх физической, с собственной адресацией, не зависящей от того, как устроена сеть ЦОД снизу.

Протоколы туннелирования

SSH-туннель: самый частый в работе

Типичная задача: подключиться к базе, которая слушает только внутренний интерфейс и наружу не опубликована.

# локальный форвардинг: localhost:5432 → db.internal:5432 через бастион
ssh -L 5432:db.internal:5432 admin@bastion.example.com

# теперь клиент ходит как будто в локальную БД
psql -h 127.0.0.1 -p 5432 -U app appdb

# обратный форвардинг: открыть свой локальный сервис на удалённой машине
ssh -R 8080:localhost:3000 admin@server.example.com

# динамический: SOCKS5-прокси на localhost:1080, трафик приложения — через сервер
ssh -D 1080 admin@bastion.example.com

Порт СУБД при этом наружу не открыт вообще: iptables пускает только 22-й, а всё остальное едет внутри SSH-сессии — с её шифрованием и её аутентификацией по ключу.

Накладные расходы и MTU

Каждый уровень упаковки добавляет заголовок, а размер кадра ограничен MTU (в Ethernet обычно 1500 байт). Значит, полезная нагрузка внутри туннеля меньше:

Симптом неправильного MTU обманчив: ping через туннель идёт, SSH подключается и даже работает, а крупные ответы и загрузка файлов виснут намертво. Причина в том, что большие пакеты в туннель не влезают, а ICMP-сообщения «нужна фрагментация» кто-то по пути режет, и Path MTU Discovery не срабатывает. Лечится выставлением MTU на интерфейсе туннеля или зажимом MSS на шлюзе:

# подогнать MSS под реальный MTU туннеля
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Туннелирование в инфраструктуре

Главный потребитель туннелей сегодня — overlay-сети. В Kubernetes поды получают адреса из собственной подсети, а трафик между узлами идёт в VXLAN-туннелях: поэтому под может переехать на другой узел, сохранив свой IP, а сеть ЦОД про эту адресацию ничего не знает. Тот же приём в облаках: VPC — это адресация клиента поверх общей физической сети ЦОД, развязанная туннелями. Изоляция между клиентами при этом обеспечивается тем, что чужой трафик просто не попадает в ваш туннель.

Связанные термины

• VPN — зашифрованный туннель как готовый продукт
• VPN-протоколы (L2TP/PPTP/IPsec) — конкретные реализации туннелей
• SSH — самый доступный туннель, ничего ставить не нужно
• MTU и MSS — то, что ломается при туннелировании чаще всего
• VPC — облачная сеть, построенная на туннелях
• NAT — соседний механизм преобразования трафика на пути