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

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

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

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

Стандартным вариантом решения задачи является построение двойного туннеля:

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

Описываем IPSEC-соединение на домашнем компе:

/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

Если в дальнейшем надо будет пропускать через 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шников)
• Либо эффект фаерволов

На домашнем компе:

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

На офисном компе:

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

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

При настройке в ручном режиме на домашнем компе:

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  # еще одна реальная сеть предприятия, которая раньше по тексту не возникала

На раутерах в офисе:

ip ro a 172.18.1.28/30 via 1.2.3.2

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

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

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

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

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