vpn:gre-over-ipsec-from-linux-to-linux [Моя склеротичка]

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
~~TAGCLOUD~~
{{tag>vpn net linux gre}}
====== Постановка задачи ======

Дан домашний комп администратора. Необходимо обеспечить комфортную и безопасную работу админа с ресурсами сети организациии, с одной стороны, а с другой, режим road-warrior'а в силу разных причин не устраивает. Впервую очередь это связано с видео-звонками через скайп --- очень большой джиттер, да и нет нужды гонять **весь** трафик через VPN.


====== Варианты решения ======

Наиболее простым способом построить маршрутизацию через туннель является поднятие GRE-туннеля, однако это весьма небезопасно в чистом виде, т.к. GRE не предоставляет родных механизмов надёжного шифрования данных, таких как у IPSEC.

Как известно, в режиме transport-mode IPSEC шифрует данные, адресатом и отправителем которых являются концы IPSEC-туннеля. Т.е. если мы даже завернём маршрутизацию удалённой сети через "тот" конец туннеля, наш транзитный трафик шифроваться не будет.

Обратная ситуация возникает при режиме tunnel-mode. Итого, оба варианта "в чистом виде" не подходят.

Стандартным вариантом решения задачи является построение двойного туннеля:
  - через GRE-туннель обеспечивается легко настраиваемая IP-маршрутизация,
  - все данные GRE-туннеля инкапсулируются в IPSEC-туннель, что обеспечивает надёжное шифроваине данных


====== Решение ======

===== IPSEC =====

Описываем IPSEC-соединение на домашнем компе:
<file ini /etc/ipsec.conf>
version 2.0

config setup
        nat_traversal=yes
        protostack=netkey

conn work
        #Office-side description
        left=1.2.3.2
        #leftprotoport=gre
        #Local-side descrioption
        right=5.6.7.2
        rightnexthop=5.6.7.1
        #rightprotoport=gre
        #Other options
        compress=no
        authby=secret
        auto=start
        ike=3des-sha1-modp1024
        esp=3des-md5
        ikelifetime=8h
        keylife=1h
        pfs=yes
        type=transport
</file>

Если в дальнейшем надо будет пропускать через IPSEC только GRE-трафик, снимаем коментарии со строк leftprotoport и rightprotoport, я предпочитаю шифровать абсолютно весть трафик между концами туннеля. Из важного:
  * left и right указываю реальные (aka белые) IP-адреса машин.
  * авторизацию выполняем по PSK-схеме
  * тип туннеля: transport

На офисный конец туннеля копируем это же самое описание соединения, сносим rightnexthop и прописываем leftnexthop=1.2.3.1
Рестартуем openswan на обеих концах туннеля. Проверяем, что трафик шифруется (например, пускаем ping, заходим на 1.2.3.1, запускаем tcpdump, видим, что идёт ESP-трафик). 

==== Возможные проблемы ====

  * Либо не правильно настроен openswan (выше указан рабочий конфиг, с точностью до замены IPшников)
  * Либо эффект фаерволов


===== GRE =====

На домашнем компе:
<file bash /etc/conf.d/net>
#####################################################################
#
## GRE tunnel to office
#
#####################################################################

iptunnel_gre2="mode gre local 5.6.7.2 remote 1.2.3.2 key 1234567890 ttl 255"
mtu_gre2="1400"
config_gre2="172.18.1.30/30"
</file>

На офисном компе:
<file bash /etc/conf.d/net>
#####################################################################
#
## GRE tunnel to home
#
#####################################################################

iptunnel_gre2="mode gre local 1.2.3.2 remote 5.6.7.2 key 1234567890 ttl 255"
mtu_gre2="1400"
config_gre2="172.18.1.29/30"
</file>

==== Возможные проблемы ====

Нет :)
Если таковые возникают --- отключаем на время IPSEC, отлаживаем GRE, включаем IPSEC.


===== Маршрутизация =====

При настройке в ручном режиме на домашнем компе: 
<code bash>
ip ro a 1.2.3.2         via 5.6.7.1
ip ro a 10.0.0.0/8      via 172.18.1.29
ip ro a 192.168.0.0/16  via 172.18.1.29
ip ro a 1.2.3.0/24      via 172.18.1.29
ip ro a 3.2.1.0/24      via 172.18.1.29  # еще одна реальная сеть предприятия, которая раньше по тексту не возникала
</code>

На раутерах в офисе: 
<code bash>
ip ro a 172.18.1.28/30 via 1.2.3.2
</code>

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

===== DNS =====

Чтобы с домашнего компа комфортно работать с сетью офиса, необходимо настроить резолвинг (прямой и обратный) DNSных имен и IP адресов. Если домашний комп --- это классическая "рабочая станция", то в /etc/resolv.conf надо прописать адреса NSов офисной сети.

Если на домашнем компе стоит bind (как у меня), то можно поступить интересней: 

<file c named.conf>

acl "trusted" {
        127.0.0.0/8;
        ::1/128;
        172.18.1.0/24;
        5.6.7.2;
};

view tunnel IN {
        match-clients {
                trusted;
        };
        recursion yes;

        zone "ofis" {
                type forward;
                forward only;
                forwarders {
                        1.2.3.3;       #реальные (aka белые) адреса офисных NSов
                        1.2.3.4;
                        172.16.0.3;    #фейковые (aka серые) адреса офисных NSов
                        172.17.17.4;
                };
        };

        zone "16.172.IN-ADDR.ARPA" {
                type forward;
                forward only;
                forwarders {
                        1.2.3.3;       #реальные (aka белые) адреса офисных NSов
                        1.2.3.4;
                        172.16.0.3;    #фейковые (aka серые) адреса офисных NSов
                        172.17.17.4;
                };
        };

        zone "17.172.IN-ADDR.ARPA" {
                type forward;
                forward only;
                forwarders {
                        1.2.3.3;       #реальные (aka белые) адреса офисных NSов
                        1.2.3.4;
                        172.16.0.3;    #фейковые (aka серые) адреса офисных NSов
                        172.17.17.4;
                };
        };

}; # end of tunnel view

view public IN {

        zone "." in {
                type hint;
                file "/var/bind/root.cache";
        };

        /* тут идёт описание всех остальных зон, которые обслуживаются нашим bindом */

}; # end of public view

</file>
Фокус сводится к указанию типа зоны forward, для локальных зон в сети офиса. Чтобы кто попало не мог спросить у нашего NSа про эти зоны, оборачиваем их во view. (При перечислении зон необходимо помнить, что порядок их указания играет роль.)