Шпаргалка по маршрутизации внешних IP во внутреннюю сеть без моста и iptables в 4 команды

Практика применения: например маршрутизация IP-адресов с сервера на виртуальные машины, без необходимости подключать их к ethernet-сети физического сервера.
При этом на сетевой интерфейс может быть назначена как сеть адресов, так и разрозненные адреса, у которых этот сервер указан просто как следующий узел маршрутизации (так например Hetzner раздает свои отказоустойчивые IP-адреса).

Исходное состояние

Сервер S0 — шлюз в интернет, у него есть две сетевые карты eth0 — внешняя и brLAN — внутренняя (это может быть как физическая карта, так и просто мост для организации сети с виртуальными машинами).
1.2.3.4 — внешний IP-адрес, пакеты которого приходят на eth0
192.168.0.1 — IP-адрес сервера S0 на brLAN.
На S0 включена функция перенаправления IPv4

cat /etc/sysctl.conf | grep net.ipv4.ip_forward net.ipv4.ip_forward=1 

Сервер S1 — сервер во внутренней сети или виртуальный сервер, для которого нужно пробросить внешний IP-адрес, у него есть один сетевой интерфейс — eth0, включенный в brLAN.

iptables на обоих серверах выключен

Краткая шпаргалка по командам

Сервер S0 (шлюз):

ip route add 1.2.3.4 dev brLAN # отправлять пакеты для адреса 1.2.3.4 на интерфейс brLAN 

Сервер S1 (внутренний)

ip addr add 1.2.3.4 dev eth0 # Добавить адрес 1.2.3.4 на интерфейс, смотрящий в brLAN ip route add 192.168.0.1 dev eth0 # Пакеты на 192.168.0.1 отправлять в сеть brLAN ip route add default via 192.168.0.1 # Весь внешний трафик отправлять через 192.168.0.1 

На этом всё: для S1 внутренних IP-адресов назначать не нужно — пакеты сразу отправляются с публичного адреса.

Настройка клиента через конфиги

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

cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static ONBOOT=yes IPADDR=1.2.3.4 NETMASK=255.255.255.255 SCOPE="peer 192.168.0.1"  cat /etc/sysconfig/network-scripts/route-eth0 ADDRESS0=0.0.0.0 NETMASK0=0.0.0.0 GATEWAY0=192.168.0.1 

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

Преимущества перед iptables с пробросом на внутренний IP

1. Сохраняется адрес назначения пакета
2. На интерфейсе внутреннего сервера виден правильный внешний IP
3. Нет необходимости следить за зеркальными правилами iptables — чтобы исходящий трафик тоже шел с правильного IP
4. При необходимости фильтрации трафика на шлюзе правила будут выглядеть нагляднее — указывать на реальный адрес сервера
5. Отпадает необходимость поддерживать внутреннюю систему адресации
6. Проще манипулировать маршрутами из скриптов
7. Возможность обращаться к серверам по публичному адресу независимо от источника трафика. Для iptables в этом случае пришлось бы настраивать правила отдельно для случаев когда источник трафика на шлюзе, из внутренней сети, из внешней сети. Возможно есть еше какие-то тонкости
8. Нагляднее вывод маршрутизации по ip route сразу видно какой трафик пойдет во внутреннюю сеть, в iptables правил было бы намного больше + были бы правила фильтрации и вывод нужно отдельно разбирать
9. Два сервера из brLAN могут общаться между собой по публичным адресам напрямую, без участия шлюза
   Скрытый текст

   ping 1.2.3.4 PING 1.2.3.4 (1.2.3.4) 56(84) bytes of data. 64 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=1.18 ms From 192.168.122.1: icmp_seq=2 Redirect Host(New nexthop: 1.2.3.4) 64 bytes from 1.2.3.4: icmp_seq=2 ttl=64 time=0.386 ms 64 bytes from 1.2.3.4: icmp_seq=3 ttl=64 time=0.325 ms 64 bytes from 1.2.3.4: icmp_seq=4 ttl=64 time=0.262 ms 64 bytes from 1.2.3.4: icmp_seq=5 ttl=64 time=0.298 ms 64 bytes from 1.2.3.4: icmp_seq=6 ttl=64 time=0.344 ms </spoiler> arp Address                  HWtype  HWaddress           Flags Mask            Iface 192.168.122.1            ether   52:54:00:91:b2:67   C                     eth0 1.2.3.4                  ether   52:54:00:11:80:37   C                     eth0 

Как избавиться от 192.168.0.1

P.S. в принципе адрес 192.168.0.1 тоже можно исключить и указывать вместо него любой IP-адрес сервера-шлюза, например его публичный IP, тогда трассировка пути будет смотреться красиво. При установках по умолчанию всё будет работать, но могут возникать ньюансы.

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