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

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

Практика применения: например маршрутизация 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-адресов назначать не нужно — пакеты сразу отправляются с публичного адреса.

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

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

Пример конфигурационных файлов для 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

1. Сохраняется адрес назначения пакета


2. На интерфейсе внутреннего сервера виден правильный внешний IP


3. Нет необходимости следить за зеркальными правилами iptables — чтобы исходящий трафик тоже шел с правильного IP


4. При необходимости фильтрации трафика на шлюзе правила будут выглядеть нагляднее — указывать на реальный адрес сервера


5. Отпадает необходимость поддерживать внутреннюю систему адресации


6. Проще манипулировать маршрутами из скриптов


7. При росте инфраструктуры можно будет перейти на динамическую маршрутизацию сохраняя уже существующие правила и логику работы


8. Возможность обращаться к серверам по публичному адресу независимо от источника трафика. Для iptables в этом случае пришлось бы настраивать правила отдельно для случаев когда источник трафика на шлюзе, из внутренней сети, из внешней сети. Возможно есть еше какие-то тонкости


9. Нагляднее вывод маршрутизации по ip route сразу видно какой трафик пойдет во внутреннюю сеть, в iptables правил было бы намного больше + были бы правила фильтрации и вывод нужно отдельно разбирать


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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.