Переадресация IP-адресов в Linux - что-нибудь важное, что нужно сделать или знать?

Отчасти меня заинтересовал вопрос, не хватает ли чего-то, что мне не хватает, - это вопрос, почему ip_forward не всегда установлен в 1, а вместо этого по умолчанию равен 0 - например, есть ли какой-то риск для безопасности или нежелательный поведение, если для него в определенных ситуациях установлено значение 1.

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

Что касается порта 80. Поскольку у вас уже есть веб-сервер, прослушивающий example.com, довольно легко настроить обратный прокси для нового веб-сервера. Существует множество примеров того, как это сделать при сбое сервера, но вкратце

<VirtualHost *:80>
    ProxyPreserveHost On
    ProxyPass / http://example.com/
    ProxyPassReverse / http://example.com/

    ServerName example.com
</VirtualHost>

Вы можете сделать то же самое для https на порту 443

<VirtualHost *:443>
    ProxyPreserveHost On
    ProxyPass / https://example.com/
    ProxyPassReverse / https://example.com/

    ServerName example.com
</VirtualHost>

Единственное, что вам нужно сделать, это настроить локальный преобразователь DNS с записью для example.com, так что он предпочтительнее глобального DNS. Что-то вроде dnsmasq должно сделать это легко.

В вашем конкретном случае вы заранее подготовите свои новые vhosts для example.com, установите dnsmasq и добавьте example.com в файл локальных хостов. Затем, когда вы будете готовы, включите службу dnsmasq и перезапустите apache, и вперед.

ip_forwarding: ip_forwarding может быть опасен в ситуациях, когда используются общедоступные IP-адреса. Вновь установленный компьютер с Linux можно затем использовать в качестве маршрутизатора для сетей, которые не должны маршрутизироваться таким образом.

iptables: Основная проблема с настройкой iptables, вероятно, связана с маршрутизацией на новом компьютере. Эта машина должна использовать старую машину в качестве маршрутизатора, чтобы отправить обратно искаженные пакеты, и таким образом вы столкнетесь с проблемой маршрутизации. Вероятно, намного безопаснее / проще использовать прокси, например varnish, для пересылки HTTP-трафика. Если вы используете apache или nginx для хостинга, вы даже можете настроить их как прокси-серверы для своего нового веб-сервера.

Для этого вы можете использовать haproxy. Конфигурацию можно найти ниже:

global
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats

defaults
    mode                    http
    option                  abortonclose
    no option               checkcache
    option                  redispatch
    retries                 3
    timeout http-request    30s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout server          1m
    timeout http-keep-alive 5s
    timeout check           10s
    maxconn                 4000

# x.x.x.x = new IP
# y.y.y.y = old IP

listen l.x.x.x.x
       option forwardfor header X-Real-IP
       option http-server-close
       source y.y.y.y
       bind y.y.y.y:80
       server newserver x.x.x.x:80 id 1

listen l.x.x.x.x.ssl
       source y.y.y.y
       mode tcp
       bind y.y.y.y:443
       server newserver x.x.x.x:443 id 1

Кроме того, вы можете использовать dnsmasq для пересылки DNS-запросов - полезный ответ для этого можно найти прямо здесь, на serverfault Как заставить dnsmasq использовать DNS для некоторых хостов?

Я несколько раз перемещал центры обработки данных, при этом вместе с перемещением менялся полный блок класса C. Целесообразно использовать conntrack как в iptables, так и в snat.

Вот небольшой удобный сценарий, который я использовал несколько раз. Просто и работает как шарм. При необходимости добавьте дополнительные порты. Как только DNS обновится и у вас больше не будет подключений, удалите правила iptables.

#!/bin/sh
IPTABLES="/sbin/iptables"

# modify to suit
EXTERNAL="eth0" 
OLDSERVER="10.10.10.1"
NEWSERVER="10.10.20.2"

$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -i $EXTERNAL -o $EXTERNAL -p tcp --dport 80 -d $OLDSERVER -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -t nat -A PREROUTING -i $EXTERNAL -p tcp --dport 80 -d $OLDSERVER -j DNAT --to-destination $NEWSERVER
$IPTABLES -t nat -A POSTROUTING -p tcp --dport 80 -d $NEWSERVER -j SNAT --to $OLDSERVER

echo 1 > /proc/sys/net/ipv4/ip_forward

Эта пересылка должна быть реализована внутри брандмауэра, а не оставлена ​​для общего доступа.

Что касается того, почему пересылка не включена по умолчанию, могут ли другие ответы сказать это лучше всего: если устройство не маршрутизирует пакеты, оно не должно быть включено. Это угроза безопасности? Все зависит от роли и конфигурации сервера.

Надеюсь, это поможет.

Вы также должны убедиться, что -A Forwarding не установлен на ACCEPT, поскольку ваш Сервер станет открытым маршрутизатором, который может (и, скорее всего, будет) использоваться для злонамеренных действий. С учетом сказанного просто добавьте правило для пересылки только необходимого трафика, и все будет в порядке.

Пересылка, вероятно, отключена по 2 причинам: Номер 1 заключается в том, что каждый загруженный и активный модуль использует вычислительную мощность. Когда он отключен, вы экономите вычислительную мощность. Это так просто. Номер 2 немного сложнее: когда кто-то, новичок в Linux или Iptables, просто использует набор правил по умолчанию, по умолчанию будет принята политика FORWARD, которая приводит к открытому маршрутизатору (снова). Поскольку никто не хочет, чтобы была принята вторая «мера безопасности», прежде чем ваш сервер начнет маршрутизацию пакетов.

Лучший пример IP-переадресации, который я видел, - на веб-сайте города Тайджи, Япония. Как популярная цель для хактивистов, они держат фиктивный устаревший веб-сервер Apache, работающий на их выделенном IP-адресе назначения пересылки 58.94.160.100. Это служит молнией для их трех других веб-серверов, которые являются моделями MS 2012R, присвоенными 10.0.0.0, но физически расположенными в неизвестных частях. Они используют дюжину различных хостинговых компаний для стабилизации своего веб-сайта, используя постоянную переадресацию IP-адресов, практически без простоев. Если ваша компания не является популярной целью атак типа «отказ в обслуживании», пересылка вашего сигнала на выделенный и перенаправленный IP-адрес не должна быть проблемой, особенно с учетом вашего заблаговременного планирования. Мой VPN использует сеть Нью-Йорка, которая зарегистрирована на opendns.com, и с att.net в качестве моего интернет-провайдера, это дает мне серверы имен по адресу 208.67.220.220 и 208.67.222.222, которые близки к серверам имен att.net по адресу 209.xxx .xxx.xxx. Мой цикл установлен на 127.0.0.1, который хорошо работает с Tor и dnschef в режимах TCP и ipv6. Мой первый сетевой адаптер - NAT, затем я назначаю еще два как сеть nat, а мой четвертый и последний адаптер - только как хост. В результате я всегда использую 10.0.2.2, 127.0.0.1 или 192.156.0.100, и это идеально подходит для анонимности с дополнительным преимуществом, заключающимся в возможности распознавать адреса веб-сайтов. Подводя итог, я подумал, что переадресация IP, вероятно, предназначалась для использования в целях безопасности, поэтому значение по умолчанию 0 может быть способом защитить анонимность конкретной географической подсети, даже с зарегистрированными серверами имен,так как должно быть полное разделение работающей сети на случай выхода из строя перенаправляемого IP. Люди, которые ищут ваш IP-адрес, вряд ли обнаружат утечку DNS, так как систему необходимо будет активно обслуживать. Я слышал, что по всему миру доступно около 50 000 общедоступных серверов имен, и кто-нибудь, обладающий вашим опытом работы в сети, может легко включить некоторые из них в вашу систему на временной основе во время перемещения и избежать простоев.

Перенаправления NAT iptables будут работать, но имейте в виду, что этот метод зависит от модуля conntrack. Если на вашем сервере слишком много одновременных запросов, таблица conntrack заполнится, и вы столкнетесь с простоем. Конечно, вы можете увеличить размер хеш-таблицы conntrack и то, как выполняется хеш-поиск, но это может повлиять на производительность. Поэтому я советую вам тщательно изучить этот вопрос, если ваш сервер обслуживает большой объем веб-трафика.

Я бы также не использовал здесь -j MASQUERADE в ваших правилах; только СНАТ и ДНАТ. Я делал это раньше; мои правила таковы:

iptables -t nat -A PREROUTING  -p tcp -s TEST_IP -d ORIGINAL_IP --dport 80 -j DNAT --to NEW_IP
iptables -t nat -A POSTROUTING -p tcp -s TEST_IP -d NEW_IP --dport 80 -j SNAT --to ORIGINAL_IP

Это удобно, потому что оно ограничивает переадресацию до одного исходного (тестового) хоста / IP-адреса, и тогда вы сможете использовать этот хост для проверки работы пересылки. Как только вы будете довольны, вы можете повторно применить эти правила с удаленным -s TEST_IP .

Из-за моего первого замечания относительно перегрузки conntrack, я бы все равно снизил TTL DNS, как вы описали - это должно минимизировать общий объем трафика, поступающего на ваш старый сервер,поэтому любые мошеннические запросы обрабатываются через перенаправление порта NAT iptables, где объем запросов должен быть достаточно низким, чтобы не создавать риск заполнения вашей таблицы conntrack.

Вам не нужны iptables , haproxy и т. Д. Для такой простой задачи. Просто установите rinetd , это самый простой файл конфигурации.

<your IP/FQDN> <your port> <where to forward IP/FQDN> <where to forward port>

т.е.

old.webserver.com 80 new.webserver.com 80