[lang_en]How To Get “Provider Independent” IP Address For Your Home Server?[/lang_en][lang_ru]Как получить “не зависящий от провайдера” IP-адрес для домашнего сервера?[/lang_ru]
2 Apr2006

[lang_en]

Some years ago I decided to stop using public mail services and decided to buy my own domain and to setup my own mail server at home to handle all of my email. Work was completed very quickly and I got my own working e-mail server and my own mail domain! Some time there was no problems and I was glad to have an opportunity to have full control over my own mail flow.

But little bit later my ISP decided to make my Internet connection cheaper (for them) and they were assigned private IP address to my home Internet connection (192.168.192.2). As you can predict, from that moment my mail server was not reachable from real world and my mail domain was down.

First available solution was to point my MX record to some real mail server in real Internet and to use fetchmail or something like it ti fetch my email to home server. But this solution was not so flexible, and I decided to take one of IP addresses from IP pool of my employer (I am working for hosting company and company owner approved configuration described here) and to assign it to my home server to make my SMTP server available from real world. “It is impossible”, you can say, “You can not set foreign real IP to interface in PRIVATE network of another ISP!”. Yes, it is true, but using some tricks with Linux policy routing an some tunnelling I can do it! This article is about how it has been done by me.

[/lang_en]

[lang_ru]

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

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

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

[/lang_ru]

[lang_en]

First of all, I selected one IP (RE.AL.AD.DR) in my employer IP network and created ip-over-tcp tunnel from my home server to one of the employer’s servers. It has been done using great UNIX tool vtun by Maxim Krasnyansky. Config files will be presented later in this article.At this step I got following interfaces on world server and home server sides:

  • World server side: 
    #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)
  • Home server side: 
    #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)

There are two different ip addresses in above quotes:

  • RE.AL.AD.DR – real IP address which is being setup on home server side.
  • 10.200.0.1 – randomly selected (by me) fake IP address for world server side.

Next, I need to force my home server to send answers to all queries to RE.AL.AD.DR services via tunnel interface. This aim was achieved by using following Linux policy routing configuration commands in tunnel up script:

 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";

These commands are adding new routing table with name hof (for which I need to have specific line in /etc/iproute2/rt_tables file with table name and any selected table id), adding default route to this table via world server’s end of tunnel and marking all packets from RE.AL.AD.DR to be marked for routing via hof routing table.

Last step is to setup world server to arp-announce RE.AL.AD.DR with its MAC-address to ethernet network with default router. I have used farpd utility from debian official repository. With this tiny tool you can arp-announce any IP address to network connected to specific interface by running following command:

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

That is all! At this point I was able to setup any software on my new IP address (RE.AL.AD.DR) and this software were available from the outside world. As for now, I can switch my ISPs any number of times – this is no matter because my IP is always moving with me.

As I promised before, vtun config files are available there for your convenience:

  • World server side: here
  • Home server side: here

Good luck with your experience with setting up your dedicated “provider-independent” IP addresses! 🙂

[/lang_en]

[lang_ru]

Во-первых, я выбрал один из адресов (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-адреса! 🙂

[/lang_ru]

No related posts.