Постановка задачи

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

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

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

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

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

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

через GRE-туннель обеспечивается легко настраиваемая IP-маршрутизация,

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

Решение

IPSEC

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

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шников)

Либо эффект фаерволов

GRE

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

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

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

##################################################################### # ## 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

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

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

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. (При перечислении зон необходимо помнить, что порядок их указания играет роль.)

Tracedump:

newBaseSize: 16pt
newBaseSizeInPt: 16