LINUX.ORG.RU
Форум — Admin  

Соединить две сети по VPN IPsec каналу

 , , ,


0

1

Друзья, подскажите как и в какую сторону рыть. А то пока ничего не понимаю.

1. Есть удаленная сеть 192.168.0.0/24. Стоит на ней роутер ZyXel, по адресу 192.168.0.10. На нем настроен IPsec. В сети разные, всякие устройства.

2. Есть локальная сеть 192.168.1.0/24 под руководством роутера F660. Доступ к F660 есть только пользовательский, т.е. на нем маршруты настроить не могу. В локальной сети есть Ubuntu 16.04 Server (192.168.1.11) и машин под Windows (192.168.1.12). На Ubuntu Server поднят клиент Strongswan к ZyXel, IPsec бегает, работает, жужжит.

Ситуация следующая:

1. С Ubuntu Server я вижу (пингую) всю удаленную сеть (192.168.0.0/24). Так настроен маршрут на ZyXel в настройках IPsec.

2. Из удаленной сети (192.168.0.0/24) я вижу Ubuntu Server (192.168.1.11), могу его пинговать.

3. Из удаленной сети (192.168.0.0/24) я не вижу локальную сеть (192.168.1.0/24), не могу пинговать машины. Исключение Ubuntu Server (192.168.1.11) с поднятым каналом IPsec.

4. Из локальной сети (192.168.1.0/24) я не могу пинговать удаленную сеть (192.168.1.0/24), включая точку входа ZyXel.

Задача: нужно сделать маршрутизацию (желательно на всех машинах локальной сети не прописывать ее руками) между локальной и удаленной сетью. Нутром чую, что тут что-то завязано на маршруты, причем ковырять надо на Ubuntu Server в первую очередь.

Дополнительно пробовал прописать маршрут на Windows машине (192.168.1.12) следующий маршрут: route add 192.168.0.0 mask 255.255.255.0 192.168.1.11

Когда прописал это дело в первый раз, то смог пинговать машины в удаленной (192.168.0.0/24) сети. Но потом перезагрузил Ubuntu Server и возможность пропала (IP-адрес у сервера не изменился).

Буду рад развернутым мыслям :)



Последнее исправление: kvv213 (всего исправлений: 2)
← NginxProxy -> Nginx + ngx_pagespeed, как правильно настроить?
dnf принудительный выбор репозтария →

Нарисуй на бумаге как у тебя пинг идёт через тоннель, особенно обратный маршрут в обоих случаях. Чую что со стороны F660 он идёт на собственно F660 а не на бубунту-vpn, где благополучно теряется

И вообще иметь гейт без админки зло. Преврати уж тогда бубунту в полноценный гейт с дефолтом на F660, и сделай её (бубунту) дефолтом для всех остальных

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 2)
Ответ на: комментарий от upcFrost

Нарисуй на бумаге как у тебя пинг идёт через тоннель, особенно обратный маршрут в обоих случаях. Чую что со стороны F660 он идёт на собственно F660 а не на бубунту-vpn, где благополучно теряется

Вот так оно выглядит на Windows машине: 

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.12     25
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      192.168.0.0    255.255.255.0     192.168.1.11     192.168.1.12     26

Т.е. как бы маршрут есть. Плюс, если пингую, то вроде бы как пакет до Ubuntu Server доходит:

/etc# tcpdump host 192.168.1.10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on p1p1, link-type EN10MB (Ethernet), capture size 262144 bytes
14:48:42.149237 IP 192.168.1.10 > 192.168.0.10: ICMP echo request, id 1, seq 18, length 40
14:48:47.065977 ARP, Request who-has 192.168.1.11 (d0:50:99:76:6d:21 (oui Unknown)) tell 192.168.1.10, length 46
14:48:47.066043 ARP, Reply 192.168.1.11 is-at d0:50:99:76:6d:21 (oui Unknown), length 28
14:48:47.066517 IP 192.168.1.10 > 192.168.0.10: ICMP echo request, id 1, seq 19, length 40
14:48:52.065606 IP 192.168.1.10 > 192.168.0.10: ICMP echo request, id 1, seq 20, length 40

И вообще иметь гейт без админки зло.

Стопроцентное зло. В сети еще есть маршрутеризатор LinkSys e3200, можно его подключить после F660, но он старенький и как бы уже просится на замену.

Преврати уж тогда бубунту в полноценный гейт с дефолтом на F660, и сделай её (бубунту) дефолтом для всех остальных

Можно подумать, но вдруг навернется... Железка без винта, мне кажется как-то более надежной.

kvv213
() автор топика
Ответ на: комментарий от thesis

Форвардинг на убунте включен?

Включил - пинги из локальной сети теперь стали доходить до удаленной на тех машинах, где прописан route add. Ура.

Из удаленной сети пинги не доходят до локальной сети, за исключением Ubuntu Server (там где IPsec клиент).

kvv213
() автор топика
Ответ на: комментарий от thesis

Из интересного в стронгсване только ipsec.conf, остальное по умолчанию все 


# Sample VPN connections
conn ToZyxel
    ikelifetime=1h
    lifetime=1h
    ike=des-md5-modp768
    esp=des-md5
    left=192.168.1.11
    leftid=UbuntuServer
    leftauth=psk
    leftsubnet=192.168.1.0/24
    right=ZyXel
    rightid=192.168.0.10
    rightauth=psk
    rightsubnet=0.0.0.0/0
    keyexchange=ikev2
    auto=start
    dpdaction=restart
    dpddelay=30s

iptables: 

# Generated by iptables-save v1.6.0 on Sun Jan 15 15:42:05 2017
*filter
:INPUT ACCEPT [6877:2172191]
:FORWARD ACCEPT [1541:1333071]
:OUTPUT ACCEPT [9394:1028299]
COMMIT
# Completed on Sun Jan 15 15:42:05 2017

kvv213
() автор топика
Ответ на: комментарий от thesis

Это почему? У тебя ж «справа» только 192.168.0.0/24.

Если поставить 192.168.0.0/24 то выдает ошибку подсети. Я так понимаю, что проблема в не очень совместимой реализацией IPsec на ZyXel и StrongSwan. Ноги растут откуда-то из Cisco Unity, где именно так и указывают нулевую сеть.

/etc# ip r
default via 192.168.1.1 dev p1p1
192.168.1.0/24 dev p1p1  proto kernel  scope link  src 192.168.1.11
kvv213
() автор топика
Ответ на: комментарий от thesis

Так, до Ubuntu Server (клиент IPsec) из удаленной сети пинги долетают замечательно: 

~$ ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data.
64 bytes from 192.168.1.11: icmp_seq=1 ttl=63 time=11.5 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=63 time=9.22 ms
64 bytes from 192.168.1.11: icmp_seq=3 ttl=63 time=9.20 ms
Маршрут вродебы как тоже понятен: 
traceroute 192.168.1.11
traceroute to 192.168.1.11 (192.168.1.11), 64 hops max
  1   192.168.0.10  0.941ms  0.298ms  0.357ms
  2   192.168.1.11  11.950ms  8.303ms  7.833ms
Но дальше клиента оно не улетает, т.е. если пинговать 192.168.1.12 то получится нечто следующее: 
$ traceroute 192.168.1.12
traceroute to 192.168.1.12 (192.168.1.12), 64 hops max
  1   192.168.0.10  0.428ms  0.282ms  0.318ms
  2   192.168.1.11  10.988ms  8.262ms  5.891ms
^C
Дальше Ubuntu Server не уходит...

kvv213
() автор топика
Ответ на: комментарий от kvv213

А покажи ip xfrm policy на убунте.
И до кучи tcpdump с нее же, когда 12ю машинку пытается пинговать удаленная.

thesis ★★★★★
()

Просто повторю,то что уже описано здесь. Пункты 3,4. потому что клиенты посылают ответ по дефолтному маршруту, т.е. без прописывания им отдельного роута через Ubuntu работать не будет.

И традиция, если у вас винда, то не забываем про ее fw/антивири. По умолчанию, из других подсетей не принимает.

anc ★★★★★
()
Ответ на: комментарий от thesis

Итак,

 ip xfrm policy
src 192.168.0.0/24 dst 192.168.1.0/24
        dir fwd priority 2883
        tmpl src 109.72.233.31 dst 192.168.1.11
                proto esp reqid 42 mode tunnel
src 192.168.0.0/24 dst 192.168.1.0/24
        dir in priority 2883
        tmpl src 109.72.233.31 dst 192.168.1.11
                proto esp reqid 42 mode tunnel
src 192.168.1.0/24 dst 192.168.0.0/24
        dir out priority 2883
        tmpl src 192.168.1.11 dst 109.72.233.31
                proto esp reqid 42 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0

tcpdump host 192.168.0.19
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on p1p1, link-type EN10MB (Ethernet), capture size 262144 bytes
19:56:50.197535 IP 192.168.0.19 > 192.168.1.12: ICMP echo request, id 28324, seq 1, length 64
19:56:50.197608 IP 192.168.0.19 > 192.168.1.12: ICMP echo request, id 28324, seq 1, length 64
19:56:51.198084 IP 192.168.0.19 > 192.168.1.12: ICMP echo request, id 28324, seq 2, length 64
19:56:51.198158 IP 192.168.0.19 > 192.168.1.12: ICMP echo request, id 28324, seq 2, length 64
19:56:52.198621 IP 192.168.0.19 > 192.168.1.12: ICMP echo request, id 28324, seq 3, length 64
19:56:52.198665 IP 192.168.0.19 > 192.168.1.12: ICMP echo request, id 28324, seq 3, length 64
19:56:53.025735 IP 192.168.0.19.53484 > 192.168.1.12.38200: Flags [S], seq 1197074430, win 29200, options [mss 1398,sackOK,TS val 88160263 ecr 0,nop,wscale 7], length 0
19:56:53.025786 IP 192.168.0.19.53484 > 192.168.1.12.38200: Flags [S], seq 1197074430, win 29200, options [mss 1398,sackOK,TS val 88160263 ecr 0,nop,wscale 7], length 0
19:56:54.021143 IP 192.168.0.19.53484 > 192.168.1.12.38200: Flags [S], seq 1197074430, win 29200, options [mss 1398,sackOK,TS val 88160513 ecr 0,nop,wscale 7], length 0
19:56:54.021219 IP 192.168.0.19.53484 > 192.168.1.12.38200: Flags [S], seq 1197074430, win 29200, options [mss 1398,sackOK,TS val 88160513 ecr 0,nop,wscale 7], length 0
19:56:56.025958 IP 192.168.0.19.53484 > 192.168.1.12.38200: Flags [S], seq 1197074430, win 29200, options [mss 1398,sackOK,TS val 88161014 ecr 0,nop,wscale 7], length 0
19:56:56.026031 IP 192.168.0.19.53484 > 192.168.1.12.38200: Flags [S], seq 1197074430, win 29200, options [mss 1398,sackOK,TS val 88161014 ecr 0,nop,wscale 7], length 0
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

Т.е. как бы до Ubuntu Server пинг доходит, но что он с ним дальше делает - не очень понятно.

kvv213
() автор топика
Ответ на: комментарий от anc

Так я же прописыывал руками на Windows машине: 

route add X.X.X.X mask Y.Y.Y.Y Z.Z.Z.Z
Отключил файрвол на виртуальной машине, получаю вот такое вот: 
 ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=126 time=12.3 ms
64 bytes from 192.168.1.10: icmp_seq=7 ttl=126 time=12.0 ms
^C
--- 192.168.1.10 ping statistics ---
23 packets transmitted, 2 received, 91% packet loss, time 22008ms
rtt min/avg/max/mdev = 12.061/12.202/12.343/0.141 ms
Отключил файрвол на физической машине, той самой 12-й, получаем все работает: 
ping 192.168.1.12
PING 192.168.1.12 (192.168.1.12) 56(84) bytes of data.
64 bytes from 192.168.1.12: icmp_seq=1 ttl=126 time=10.9 ms
64 bytes from 192.168.1.12: icmp_seq=2 ttl=126 time=11.1 ms
64 bytes from 192.168.1.12: icmp_seq=3 ttl=126 time=9.45 ms
64 bytes from 192.168.1.12: icmp_seq=4 ttl=126 time=10.8 ms
64 bytes from 192.168.1.12: icmp_seq=5 ttl=126 time=10.3 ms
64 bytes from 192.168.1.12: icmp_seq=6 ttl=126 time=10.3 ms
64 bytes from 192.168.1.12: icmp_seq=7 ttl=126 time=14.6 ms
64 bytes from 192.168.1.12: icmp_seq=8 ttl=126 time=11.0 ms
64 bytes from 192.168.1.12: icmp_seq=9 ttl=126 time=12.9 ms
64 bytes from 192.168.1.12: icmp_seq=10 ttl=126 time=10.2 ms
^C
--- 192.168.1.12 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8999ms
rtt min/avg/max/mdev = 9.454/11.165/14.602/1.430 ms

Отсюда вопрос - что делать и кто виноват? :)

kvv213
() автор топика
Ответ на: комментарий от kvv213

Т.е., если я все же смогу настроить маршрутеризацию на 192.168.1.1, то будет ли принимать файрвол на Windows пакеты или нет? Если нет, то получается, нужно на каждой машине подкручивать?

kvv213
() автор топика
Ответ на: комментарий от kvv213

Я все правильно понял, то вы отключили fw на винде, и после этого заработало? Если да, то как обычно два пути, научить винду принимать пакеты от другой сети или замаскарадить на Ubuntu (но в этом случае все пакеты от клиентов из Ubuntu будут представлены ip адресом самой Ubuntu )

anc ★★★★★
()
Ответ на: комментарий от kvv213

Т.е., если я все же смогу настроить маршрутеризацию на 192.168.1.1, то будет ли принимать файрвол на Windows пакеты или нет? Если нет, то получается, нужно на каждой машине подкручивать?

Общие ответ нет, см. мой пост выше, без маскарада не будет.

anc ★★★★★
()
Ответ на: комментарий от thesis

ЯННП, кто такая «виртуальная машина» и кто кого пингует.

Все работает, что ли?

Да, после отключения файрвола на Win машине в локальной сети, до нее стали доходить пинги из удаленной сети. Т.е. все заработало.

Сейчас жду варианта получения по доступу к роутеру (ONT) локальной сети, дабы прописать маршрут удаленная сеть -> Ubuntu Server.

При этом на Windows машинах, по всей видимости, придется добавлять удаленную сеть в доверенные источники. Что делать на Android машинах - не очень понятно. Но и нужно ли - тоже вопрос :)

Далее, после наладки маршрутизации надо будет каким-то образом пропихнуть IPv6 выдачу адресов с удаленной сети в локальную сеть. И направить IPv6 трафик из локальной сети в удаленную. Все по созданному тоннелю.

kvv213
() автор топика
Ответ на: комментарий от anc

Я все правильно понял, то вы отключили fw на винде, и после этого заработало? Если да, то как обычно два пути, научить винду принимать пакеты от другой сети или замаскарадить на Ubuntu (но в этом случае все пакеты от клиентов из Ubuntu будут представлены ip адресом самой Ubuntu )

Да, после отключенися FW все заработало так, как и должно было. Т.е. по сути нужно было форвардинг включить на Ubuntu и сделать маршрутеризацию (на стандартном гейтвее или на конкретных машинах).

Идея с маскарадингом понятна, но городить еще один нат в своей собственной сети не хочется. Идея противоположная - объединить две сети :)

kvv213
() автор топика
Ответ на: комментарий от kvv213

Идея с маскарадингом понятна, но городить еще один нат в своей собственной сети не хочется. Идея противоположная - объединить две сети :)

Если есть какой-то ад, то можно через него все сделать. Нуууу или если нет только ножками по каждому компу :)

anc ★★★★★
()
Ответ на: комментарий от kvv213

Далее, после наладки маршрутизации надо будет каким-то образом пропихнуть IPv6 выдачу адресов с удаленной сети в локальную сеть. И направить IPv6 трафик из локальной сети в удаленную. Все по созданному тоннелю.

Ну это уж тожно опишите потом в отдельной теме.... что-то сильно забористое по описанию :) Хотя может так и показалось мне....

anc ★★★★★
()
Ответ на: комментарий от anc

Если есть какой-то ад, то можно через него все сделать. Нуууу или если нет только ножками по каждому компу :)

Нету ад-а. Локальная же сеть :) Домашняя так сказать. А удаленная дачная.

kvv213
() автор топика
Ответ на: комментарий от anc

Далее, после наладки маршрутизации надо будет каким-то образом пропихнуть IPv6 выдачу адресов с удаленной сети в локальную сеть. И направить IPv6 трафик из локальной сети в удаленную. Все по созданному тоннелю.

Ну это уж тожно опишите потом в отдельной теме.... что-то сильно забористое по описанию :) Хотя может так и показалось мне....

По идее, там должно быть проще. Через OpenVPN оно делается (https://version6.ru/openvpn), надо понять как оно делается через IPsec и на ЯнЧуд-е :)

kvv213
() автор топика
Ответ на: комментарий от kvv213

Нету ад-а. Локальная же сеть :) Домашняя так сказать. А удаленная дачная.

Даже ругаться не хочется :)

anc ★★★★★
()
Ответ на: комментарий от kvv213

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

anc ★★★★★
()
Ответ на: комментарий от anc

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

Тем более интересна отдельная тема если сделаете.

Я для начала на профильном ЯнЧуд форуме хочу спросить. Если получится там ответ, то ссылку дам тут. Если не получится там ответ получить, то открою новую тему тут. Ссылку дам тоже.

kvv213
() автор топика
Ответ на: комментарий от kvv213

Итак,

Гуру Зухелей ответили, что в текущей реализации никак не протолкнуть IPv6 через IPsec, нужно ждать через одну версию, там реализовали какой-то канальный протокол, вот через него будет можно.

Дополнительно, сам собой сдох тоннель :) Сервер и ZyXel перестали обмениваться SA и канал не поднимается. Чего только не перезагружал - ничего не помогает.

Решил снести StrongSwan и попробовать сразу OpenVPN между Ubuntu и Ubuntu.

kvv213
() автор топика
Ответ на: комментарий от kvv213

Хотя подумал, подумал и решил таки попробовать SoftEther VPN для всего этого дела. По идее (описанию) оно идеально для реализации подходит, даже лучше, чем OpenVPN.

Почему не подходит IPsec, видимо потому, что в нем только L3/TUN (может быть бывает и L2/TAP) и чтобы пропихнуть через него IPv6 DHCP придется в этот тоннель заворачивать какой-то другой тоннель с L2. Что, по всей видимости, не очень здорово, хотя вполне возможно.

kvv213
() автор топика
Ответ на: комментарий от kvv213

Итак, по SoftEhter VPN пробросить IPv6 между сетями оказалось делом очень простым и реализуется оно как минимум 2 способами. Теперь локальная сеть имеет выход в IPv6 сеть и вроде бы как все работает. За исключением малой гадости, которая не дает жить нормально :)

Оба сервера Ubuntu (в локальной и удаленной сетях) не видят друг друга ни в какую. Хоть по IPv4, хоть по IPv6. Более того, если захожу на SoftEther с любого мобильного устройства через туннель IPsec/L2TP или OpenVPN (а такую опцию поддерживает SoftEther), то ситуация аналогичная. С устройств видно отлично всю сеть, за исключением Host машины.

По этому поводу уже сломано несколько голов, но хворост до сих пор там.

kvv213
() автор топика
Ответ на: комментарий от kvv213

Итак, коллеги. Итоги некотороего изыскания. SoftEhter VPN оказалась штукой весьма инетерсной. Способной пробивать файрволы (т.е. сервер можно поставить за файрволом). Но обладающей неприятной особенностью: 1. Работает в Linux в User Space. 2. Не создается в системе виртуальный адаптер, а происходит бриджевание на уровне приложения. 3. Как результат - невозможность соединить два Linux-а с доступом с одного на другой, но туннель при этом прокидывается и машины в соединенных сетях друг-друга видят. Равно как для L2, так и для L3 канала. Решить данный заскок коллективным разумом так и не получилось.

Пропихивание IPv6 из одной сети в другую реализуется достаточно легко при помощи тоннелья SE на уровне L2. Когда через тоннель проходят все пакеты Ethernet. Если не хочется конфликта на уровне DHCP IPv4, например, если у вас уже есть DHCP-сервера в каждой из сетей, то фильтруем весь IPv4 трафик. IPv6 роутинг и выдача адресов (срабатывает RA на роутере, раздающим IPv6 в одной из сетей) настраиваются чисто автоматически благодаря фичам самого протокола.

Но и тут не обошлось без ложки дегтя. Перестали нормально в сети Android устройства. Ресурсы сети они видят замечтательно, все открывают, закрывают. А вот выйти в Интернет не могут. Скорость режется до полу килобайта в секунду или того ниже. В чем проблема не очень понятно. Есть предположение, что трафик где-то начинает кольцеваться... Хотя вроде пытаешься получить доступ к IPv4 сети и IPv6 тут не должен быть ни коим боком.

kvv213
() автор топика
Ответ на: комментарий от kvv213

И все-таки вангую v6, отключите и проверьте без него.

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← NginxProxy -> Nginx + ngx_pagespeed, как правильно настроить?
Admin
dnf принудительный выбор репозтария →