8-)

В статье будет рассмотрена маршрутизация внешнего IP-адреса внутрь локальной без пробрасывания ethernet-шлюза и переписывания адресов в iptables. В итоге на сетевой карте внутреннего сервера будет один правильный внешний IP-адрес, внутренние IP-адреса будут отсутствовать.

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

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

Сервер S0 — шлюз в интернет, у него есть две сетевые карты eth0 — внешняя и brLAN — внутренняя (это может быть как физическая карта, так и просто мост для организации сети с виртуальными машинами). 1.1.1.1 — внешний IP-адрес сервера S0, в настройке никак не участвует. 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-адресов назначать не нужно — пакеты сразу отправляются с публичного адреса.

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

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

#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

Сохраняется адрес назначения пакета На интерфейсе внутреннего сервера виден правильный внешний IP Нет необходимости следить за зеркальными правилами iptables — чтобы исходящий трафик тоже шел с правильного IP При необходимости фильтрации трафика на шлюзе правила будут выглядеть нагляднее — указывать на реальный адрес сервера Отпадает необходимость поддерживать внутреннюю систему адресации Проще манипулировать маршрутами из скриптов При росте инфраструктуры можно будет перейти на динамическую маршрутизацию сохраняя уже существующие правила и логику работы Возможность обращаться к серверам по публичному адресу независимо от источника трафика. Для iptables в этом случае пришлось бы настраивать правила отдельно для случаев когда источник трафика на шлюзе, из внутренней сети, из внешней сети. Возможно есть еше какие-то тонкости Нагляднее вывод маршрутизации по ip route сразу видно какой трафик пойдет во внутреннюю сеть, в iptables правил было бы намного больше + были бы правила фильтрации и вывод нужно отдельно разбирать Два сервера из 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

#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-адрес шлюза (например виртуалка переехала на другой физический сервер) — нужно будет менять настройки внутреннего сервера. При использовании для шлюза отдельного, общего для всех подобных шлюзов адреса такой проблемы не возникает.

Навигация

Navigation

Печать/экспорт