Назад | Перейти на главную страницу

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

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

Что при этом важно знать? Вот шаги, которые я планирую использовать. Есть ли что-нибудь с точки зрения безопасности или чего-то еще, чего мне не хватает?

  1. echo "1" > /proc/sys/net/ipv4/ip_forward (или установить постоянно)
  2. iptables -t nat -A PREROUTING -d original.ip.goes.here -p tcp --dport 80 -j DNAT --to-destination new.ip.goes.here
  3. iptables -t nat -A POSTROUTING -p tcp -d new.ip.goes.here --dport 80 -j MASQUERADE
  4. Повторите # 2 и # 3, но для порта 443 вместо того 80 если на сайте есть SSL

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

РЕДАКТИРОВАТЬ:

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

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

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

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

<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 в свой локальный файл hosts. Затем, когда вы будете готовы, включите службу dnsmasq и перезапустите apache, и вперед.

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

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

Сама по себе IP-пересылка не является небезопасной, кроме того, как настроен ваш брандмауэр, если это одна и та же машина. Напротив, он может обеспечить некоторую безопасность, скрывая реальный IP-адрес сервера.

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

Следующая статья RedHat очень хорошо объясняет все это.

7.4. Правила FORWARD и NAT

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

Я также предполагаю, что это будет временная мера, и правила будут удалены позже. Возможно, вам также стоит заранее провести все возможные тесты и убедиться, что он будет работать так, как вы этого хотите.

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

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

Перенаправления 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

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