Monday, November 20th, 2017

Проброс реального IP с внешнего сервера на домашнюю машину

Published on Март 30, 2009 by   ·   Комментариев нет

Как получить «не зависящий от провайдера» IP-адрес для домашнего сервера

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

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

Сторона «мирового» сервера:

                scoundrel-hof {
                  passwd  somepass;    # Password
                  type  tun;            # IP tunnel
                  proto tcp;            # UDP protocol
                  compress  zlib:9;     # LZO compression level 9
                  keepalive yes;        # Keep connection alive

                  up {
                        # Connection is Up
                        ifconfig "%% 10.220.0.1 pointopoint RE.AL.AD.DR mtu 1450";
                        ifconfig "%% up";
                  };

                  down {
                        ifconfig "%% down";
                  };
                }

Сторона домашнего сервера:

                scoundrel-hof {
                  passwd somepass; # Password
                  type tun;         # Device tun
                  persist yes;      # Persist mode
                  encrypt no;       # No encryption
                  stat yes;
                  device tun0;

                  up {
                    ifconfig "%% RE.AL.AD.DR pointopoint 10.220.0.1 mtu 1450";
                    ip "rule add fwmark 65 table hof";
                    ip "route add default via 10.220.0.1 dev %% 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";
                  };
                  down {
                    ifconfig "%% down";
                    ip "rule del fwmark 65 table hof";
                    ip "route del default via 10.220.0.1 dev %% table hof";
                    firewall "-t mangle -D PREROUTING -s RE.AL.AD.DR -j MARK --set-mark 65";
                    firewall "-t mangle -D OUTPUT -s RE.AL.AD.DR -j MARK --set-mark 65";
                  };
                }

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

zp8497586rq


















































Смотрите также:

Readers Comments (Комментариев нет)

Comments are closed.

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]