Ipsec tunnel linux to linux

Библиотека сайта rus-linux.net

# vim /etc/ipsec.secrets siteA-public-IP siteB-public-IP: PSK "pre-shared-key" ## in case of multiple sites ## siteA-public-IP siteC-public-IP: PSK "corresponding-pre-shared-key"

Запуск сервиса и поиск возникающих проблем

Теперь сервер должен быть готов для создания туннеля VPN между полдсетями. Если вы также осуществляете управление на стороне B, то, пожалуйста, убедитесь, что вы настроили необходимые параметры на сервере стороны B. Для систем, основанных Red Hat, пожалуйста, убедитесь, что вы с помощью команды chkconfig добавили запуск сервиса в startup.

Если на обоих серверах нет ошибок, то туннель должен сейчас подняться. Вы можете проверить туннель с помощью команды ping с следующим образом.

Если туннель не поднят, то частная подсеть на стороне B не должна быть доступна со стороны А, т. е. команда ping не должна работать.
После того, как туннель будет поднят , попробуйте команду ping для доступа к частной подсети на стороне B со стороны A. Это должно работать.

Кроме того, в таблице маршрутизации сервера должны появиться маршруты к частной подсети.

# ip route [siteB-private-subnet] via [siteA-gateway] dev eth0 src [siteA-public-IP] default via [siteA-gateway] dev eth0

Кроме того, мы можем проверить состояние туннеля с помощью следующих команд.

# service ipsec status IPsec running - pluto pid: 20754 pluto pid 20754 1 tunnels up some eroutes exist # ipsec auto --status ## output truncated ## 000 "demo-connection-debian": myip=; hisip=unset; 000 "demo-connection-debian": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; nat_keepalive: yes 000 "demo-connection-debian": policy: PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,28; interface: eth0; ## output truncated ## 000 #184: "demo-connection-debian":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 1653s; newest IPSEC; eroute owner; isakmp#183; idle; import:not set ## output truncated ## 000 #183: "demo-connection-debian":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 1093s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:not set

В журнальном файле /var/log/pluto.log также должна быть информация об аутентификации, обмене ключами и информация о различных этапах туннелирования. К этому файлу также нужно обратиться в случае, если туннель не поднимается.

Если вы уверены, что все настройки правильные, а ваш туннель все еще не поднимается, то вы должны проверить следующее.

Многие провайдеры отфильтровывают использование портов IPsec. Убедитесь, что вашим провайдером разрешено использовать порты UDP 500, TCP/UDP 4500. Вы можете с помощью telnet попробовать дистанционно подключиться к вашим портам IPsec на сервере.
Убедитесь, что в брандмауэре сервера / серверов открыты необходимые порты.
Убедитесь, что на обоих серверах правильные ключи.
На обоих серверах должны быть правильно настроены параметры left и right.
Если вы столкнулись с проблемами NAT, то вместо MASQUERADING попробуйте воспользоваться SNAT.

Если кратко, то в данном руководстве описана процедура создания VPN-туннеля IPSec с помощью пакета Openswan. Туннели VPN очень полезны для повышения безопасности, поскольку они позволяют администраторам открывать доступ к критическим ресурсам только через туннели. Также туннели VPN обеспечивают при передаче защиту данных от перехвата.

Надеюсь, что это руководство вам будет полезно.

Источник

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

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

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

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

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

Читайте также: Linux web camera app

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

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

Решение

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, я предпочитаю шифровать абсолютно весть трафик между концами туннеля. Из важного:

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

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

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

vpn/gre-over-ipsec-from-linux-to-linux.txt · Последнее изменение: 2022-11-18 22:05 — Andrew A. Sabitov

Источник