Несколько лет назад я решил отказаться от использования внешних почтовых сервисов решил купить домен и настроить домашний сервер для приема всей моей корреспонденции. Работа была завершена очень быстро и я получил свой работающий на домашнем сервере почтовый домен! Некоторое время все работало гладко и ничего не предвещало проблем. Я споекйно наслаждася полным контролем над потоками почты в мой ящик..

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

Самым простым решением было бы переставить MX-записи моего домена на реальный мейл-сервер во внешней сети и использовать fetchmail или что-то похожее для доставки почты на домашний сервер. Но это решение не было достаточно гибким и я решил взять один из адресов, принадлежащих IP-пулу моего работодателя (я работаю на хостинговую компанию и ее владелец разрешил построение описанной здесь конфигурации) и назначить его на мой домашний сервер, сделав его таким образом доступным для реального мира. Вы можете сказать: “Это невозможно! Нельзя назначить чужой реальный IP на интерфейс внутри приватной сети другого провайдера!”. Да, в общем случае это так и есть, но при помощи небольшой хитрости с использованием Linux policy routing и тунеллирования это становится возможным. Эта статья расскажет Вам, как это можно сделать.

Во-первых, я выбрал один из адресов (RE.AL.AD.DR) в сети моего работодателя и организовал ip-over-tcp тунель с домашнего сервера на один из хостинговых серверов технической площадки работодателя. Это было сделано при помощи отличного средства для построения тунелей под UNIX - утилиты vtun от Максима Краснянского. Конфигураионные файлы для обоих серверов будут представлены позже в этой статье. На данном шаге я получил следующие интерфейсы со стороны на “мирового” и домашнего серверов:

  • Сторона “мирового” сервера: 
    #ifconfig tun0
tun0 Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
     inet addr:10.200.0.1  P-t-P:RE.AL.AD.DR  Mask:255.255.255.255
     UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1450  Metric:1
     RX packets:8 errors:0 dropped:0 overruns:0 frame:0
     TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
     collisions:0 txqueuelen:10
     RX bytes:546 (546.0 b)  TX bytes:494 (494.0 b)
  • Сторона домашнего сервера: 
    #ifconfig tun0
tun0 Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
     inet addr:RE.AL.AD.DR  P-t-P:10.200.0.1  Mask:255.255.255.255
     UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1450  Metric:1
     RX packets:8 errors:0 dropped:0 overruns:0 frame:0
     TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
     collisions:0 txqueuelen:10
     RX bytes:494 (494.0 b)  TX bytes:546 (546.0 b)

В приведенных выше выдержках используются 2 IP-адреса:

  • RE.AL.AD.DR - реальный IP-адрес, который был установлен на тунеле со стороны домашнего сервера.
  • 10.200.0.1 - произвольно выбранный (мною) приватный IP-адрес на “мировом” сервере.

Далее, мне нужно было заставить мой домашний сервер отправлять ответы на все запросы к сервисам по адресу RE.AL.AD.DR через тунельный интерфейс. Этой цели удалось добиться использую следующий надор команд для конфигурирования Linux policy routing в скрипте подьема тунельного интерфейса:

 ip "rule add fwmark 65 table hof";
 ip "route add default via 10.220.0.1 dev tun0 table hof”;
 firewall “-t mangle -A PREROUTING -s RE.AL.AD.DR -j MARK –set-mark 65″;
 firewall “-t mangle -A OUTPUT -s RE.AL.AD.DR -j MARK –set-mark 65″;

Эти команды добавляют в систему новую таблицу маршрутизации с именем hof (для которой необходимо добавить отдельную строку в файле /etc/iproute2/rt_tables в виде “имя_таблицы числовой_идентификатор”), затоем добавляют в созданную таблицу маршрут по-умолчанию через конец тунеля на стороне “мирового” сервера и, наконец, помечают все пакеты с адреса RE.AL.AD.DR для маршрутизации при помощи таблицы hof.

Последним шагом необходимо было настроить “мировой” сервер так, чтобы он анонсировал при помощи arp-фреймов адрес RE.AL.AD.DR со своим MAC-адресом в ethernet-сеть в сторону своего маршрутизатора. Я использовал для этого маленькую утилиту farpd из официального репозитария дистрибутива Debian GNU/Linux. При помощи этой утилиты возможно анунсирование любого IP-адреса при помощи arp-фреймов в сеть, соединенную с определенным интерфейсом сервера:

/usr/sbin/farpd -i eth0 RE.AL.AD.DR

Вот и все! После выполнения описанных шагов, любое ПО на моем домашнем сервере, настроенное на использование моего нового IP-адреса address (RE.AL.AD.DR) будет доступно из реального мира сети Internet. На данный момент я могу без проблем менять провайдеров, обеспечивающих мне доступ в Сеть и это никак не повлияет на работу моего сервера так-как мой IP постоянно перемещается вместе со мною.

Как я и обещал, фрагменты конфигурационных файлов для vtun доступны для удобного скачивания:

  • Сторона “мирового” сервера: здесь
  • Сторона домашнего сервера: здесь

Удачи Вам в ваших испытаниях описанной схемы получения собственного выделенного не зависимого от провайдера IP-адреса! :-)

 Bookmark on del.icio.us