pdn_mail
-
Posts
51 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by pdn_mail
-
-
Спасибо!
Добавил в настройки интерфейса Gre0 команду
(config-if)> tunnel source 192.168.0.1Gre потом один оставлю, Пока осталось с заворотом порта разобраться, про него чуть позже спрошу, как конфигурацию поковыряю, а сейчас можно вопрос?
Зачем нужен транспортный режим? Мне он разве даст через NAT работать? На схеме, что в ссылке дана в начале, слева перед сервером неадминистрируемый роутер с NAT.
Просто в этой схеме если вместо Zyxel использовать машинку с linux, то всё замечательно в режиме туннеля работает. Вот почему такой вопрос возник.
-
Вот концовка сообщения
справа: Zyxel Giga II версия 2.09(config)> int Gre0 Network::Interface::Repository: Created interface Gre0. (config-if)> tunnel destination 192.168.2.2 Network::Interface::Tunnel: Destination set to 192.168.2.2. (config-if)> ip address 192.168.100.1 255.255.255.0 Network::Interface::IP: "Gre0": IP address is 192.168.100.1/24. (config-if)> up Network::Interface::Base: "Gre0": interface is up. (config-if)> security-level private Network::Interface::IP: "Gre0": security level set to "private". (config-if)> no isolate-private Netfilter::Manager: Private networks not isolated. (config)>
проброска порта - ip static tcp ISP 80 192.168.100.2 80 !http:80
-
да тут предпросмотра нет, конец обрезало. Пытаюсь отредактировать.
-
Здравствуйте!
Случилась оказия завести сервер который сидит за серым IP и потребовалось пробросить на него порт по туннелю от шлюза с белым IP.
Схема один в один как в статье http://blog.kvv213.com/2017/03/podklyuchaemsya-k-udalennomu-routeru-zyxel-po-ipsec-vpn-cherez-strongswan-na-headless-ubuntu-14lts/
за некоторым исключением: туннель GRE/IPSec на strongswan.Туннель устанавливается, тут всё нормально:
ipsec-eoip{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6644240_i c9bb72d4_o
ipsec-eoip{1}: 192.168.2.2/32 === 192.168.0.1/32
а вот дальше, как пробросить порт начинаю буксовать:во первых не видят друг друга концы туннеля, с левой машины на ping 192.168.100.1 тишина.... From 192.168.100.2 icmp_seq=1 Destination Host Unreachable
во вторых, проброска порта, но до этого пока не доходит. из-за во первых...
где что я не доделал или накосячил? Что сделать чтобы концы туннеля GRE друг друга увидели?
слева на машине linux: ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> ... 2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:1a:64:94:68:74 brd ff:ff:ff:ff:ff:ff inet 192.168.2.2/24 brd 192.168.2.255 scope global enp4s0 ... 3: enp6s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:1a:64:94:68:76 brd ff:ff:ff:ff:ff:ff 4: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000 link/gre 0.0.0.0 brd 0.0.0.0 5: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 9: grelan@enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether 46:cf:f7:8f:fc:58 brd ff:ff:ff:ff:ff:ff inet 192.168.100.2/24 scope global grelan ....
слева: ip routedefault via 192.168.100.1 dev grelan (БЕЛЫЙ IP Zyxel) via 192.168.2.1 dev enp4s0 192.168.2.0/24 dev enp4s0 proto kernel scope link src 192.168.2.2 192.168.100.0/24 dev grelan proto kernel scope link src 192.168.100.2
-
Для большего понимания ситуации накидал схему, как говорится лучше один раз увидеть.
1. Надо объединить сегменты через IPSec туннель
2. Станции сегмента 192.168.0.0 / 24 должны видеть станции сегмента 192.168.2.0 / 24, это в идеале, так хотя-бы чтобы сервер был виден из обоих сегментов и сам сервер видел оба сегмента.
3. Web-трафик поступающий на порт 48.210.2.2[80] должен перенаправляться на web-server 192.168.2.2
4. Весь интернет трафик web сервера пропустить через IPSec туннель и обеспечить выход через 48.210.2.2, т.е.сервер перестаёт ходить через 212.20.13.66, начинает ходить, через 48.210.2.2, при этом сам может стать гейтвеем для машин сегмента, которые при указании его в качестве шлюза будут ходить в инет через 48.210.2.2Пока голова пухнет, как на самом web-сервере всё это связать в кучу? Вроде есть статья на подобную тему - https://libreswan.org/wiki/EoIP_shared_ethernet_LAN_using_IPsec, но и тут куча вопросов, интерфейсы и бридж там имеют адреса, разве всё это можно пихать в бридж, интерфейсы не должны быть с адресами, либо сам бридж должен быть без адреса? Если делать по писаному то пока ничего не выходит.
Схема кстати очень похожа на схему в статье https://zyxel.ru/kb/3208/ за исключением того, что объединение локальных сетей у нас происходит через EoIP over IPSec по сети интернет и в качестве второго роутера выступает сервер на Linux с одним Ethernet интерфейсом. Если честно хотелось бы на сервере обойтись без второй таблицы маршрутизации.
-
19 часов назад, Le ecureuil сказал:
У сервера должен быть "белый" адрес, клиент же может быть где угодно. Опишите подробнее, как у вас подключены к Интернету клиент и сервер.
В 15.01.2017 в 16:32, r13 сказал:Не понятно что такое "у сервера (на роутере) белый IP с NAT"
Вопрос вывел в отдельную тему - https://forum.keenetic.net/topic/1673-как-на-linux-с-помощью-strongswan прокинуть-туннель-eoip-over-ipsec-до-модема/
Может поможете?
-
В том-то и дело что у сервера (на роутере) белый IP с NAT, клиент-же, который поднимает соединение, сидит тоже за NAT с белым IP, и поэтому мне думается не работает.
Получаю -
Jan 15 13:49:48 ipsec: 07[IKE] no shared key found for '48.210.2.2'[46.241.10.2] - '(null)'[212.20.13.66]
Jan 15 13:49:48 ipsec: 07[IKE] no shared key found for 48.210.2.2 - 212.20.13.66
-
Ещё попутный вопрос: в автоматической настройке туннель поднимается в транспортном режиме, может поэтому получается так?
Jan 15 13:49:48 ipsec: 07[IKE] no shared key found for '48.210.2.2'[48.210.2.2'] - '(null)'[212.20.13.66]
Есть способ конфигурирования в туннельном режиме, или нужно полностью ручную настройку делать?
-
Здравствуйте!
Вопрос собственно в теме: Как на Linux прокинуть туннель EoIP over IPSEC на Strongswan до модема?
Исходные данные:
версия 2.09 на Giga II с NAT, белый IP - 48.210.2.2
Linux, на котором установлены пакеты "Strongswan" и "linux-eoip", находится за NAT, что не так важно, важно что на машине linux - IP 192.168.2.2/32, шлюз 192.168.2.1, iptables пустой, без правил.
на модеме выполняю команды:
(config)> interface EoIP0 (config-if)> tunnel source ISP (config-if)> tunnel eoip id 1500 (config-if)> ipsec preshared-key mytestingkey (config-if)> ip address 192.168.100.1 255.255.255.0 (config-if)> security-level private (config-if)> up (config-if)> exit (config)> no isolate-privateбольше ничего не настраиваю.
Смотрим что получилось:
(config)> show interface eoip0 id: EoIP0 index: 0 type: EoIP description: interface-name: EoIP0 link: up connected: yes state: up mtu: 1500 tx-queue: 1000 address: 192.168.100.1 mask: 255.255.255.0 uptime: 719 global: no security-level: private mac: 16:0e:68:fe:79:85 auth-type: none (config)> show ipsec ipsec_statusall: Status of IKE charon daemon (strongSwan 5.5.1, Linux 3.4.113, mips): uptime: 2 hours, since Jan 13 12:46:56 2017 malloc: sbrk 188416, mmap 0, used 114856, free 73560 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2 loaded plugins: charon random nonce openssl hmac attr kernel-netlink socket-default stroke updown eap-mschapv2 eap-dyn amic xauth-generic xauth-eap error-notify systime-fix unity Listening IP addresses: 78.47.125.180 48.210.2.2 192.168.0.1 192.168.100.1 Connections: EoIP0: %any...%any IKEv1, dpddelay=30s EoIP0: local: [48.210.2.2] uses pre-shared key authentication EoIP0: remote: uses pre-shared key authentication EoIP0: child: 48.210.2.2/32[gre] === 0.0.0.0/0[gre] TRANSPORT, dpdaction=restart Security Associations (0 up, 0 connecting): noneВидим, что IPSEC настроен в режиме транспорта и IKEv1. Это важно, чтобы понять как нам настраивать клиента.
Остался только непонятным момент, какое время устанавливать для
Далее настройки на Linux:
# ipsec.conf - strongSwan IPsec configuration file # basic configuration config setup # strictcrlpolicy=yes # uniqueids = no # Add connections here. conn ipsec-eoip type=transport keyexchange=ikev1 authby=psk ike=aes128-sha1-modp1024! esp=aes128-sha1-modp1024! left=192.168.2.63 leftsubnet=192.168.2.63/32[47/0] right=48.210.2.2 rightsubnet=192.168.0.1/32[47/0] auto=start# ipsec.secrets - strongSwan IPsec secrets file 192.168.2.63 48.210.2.2 : PSK "mytestingkey"Проблема в том что ещё на этапе установления соединения возникает ошибка:
Журнал на роутере пишет:
[I] Jan 15 13:49:34 ipsec: 00[DMN] signal of type SIGHUP received. Reloading configuration [I] Jan 15 13:49:34 ipsec: 14[CFG] received stroke: add connection 'EoIP0' [I] Jan 15 13:49:34 ipsec: 14[CFG] conn EoIP0 [I] Jan 15 13:49:34 ipsec: 14[CFG] left=%any [I] Jan 15 13:49:34 ipsec: 14[CFG] leftsubnet=48.210.2.2/32[47] [I] Jan 15 13:49:34 ipsec: 14[CFG] leftauth=psk [I] Jan 15 13:49:34 ipsec: 14[CFG] leftid=48.210.2.2 [I] Jan 15 13:49:34 ipsec: 14[CFG] leftupdown=/tmp/ipsec/charon.left.updown [I] Jan 15 13:49:34 ipsec: 14[CFG] right=%any [I] Jan 15 13:49:34 ipsec: 14[CFG] rightsubnet=0.0.0.0/0[47] [I] Jan 15 13:49:34 ipsec: 14[CFG] rightauth=psk [I] Jan 15 13:49:34 ipsec: 14[CFG] rightid=%any [I] Jan 15 13:49:34 ipsec: 14[CFG] rightupdown=/tmp/ipsec/charon.right.updown [I] Jan 15 13:49:34 ipsec: 14[CFG] ike=aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024! [I] Jan 15 13:49:34 ipsec: 14[CFG] esp=aes128-sha1,aes256-sha1,3des-sha1,aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024! [I] Jan 15 13:49:34 ipsec: 14[CFG] dpddelay=30 [I] Jan 15 13:49:34 ipsec: 14[CFG] dpdtimeout=90 [I] Jan 15 13:49:34 ipsec: 14[CFG] dpdaction=3 [I] Jan 15 13:49:34 ipsec: 14[CFG] mediation=no [I] Jan 15 13:49:34 ipsec: 14[CFG] keyexchange=ikev1 [I] Jan 15 13:49:34 ipsec: 00[CFG] loaded 0 entries for attr plugin configuration [I] Jan 15 13:49:34 ipsec: 14[CFG] added configuration 'EoIP0' [I] Jan 15 13:49:34 ndm: IpSec::IpSecNetfilter: start reloading netfilter configuration... [I] Jan 15 13:49:34 ndm: IpSec::Configurator: reloading IPsec config task done. [I] Jan 15 13:49:34 ndm: IpSec::IpSecNetfilter: netfilter configuration reloading is done. [I] Jan 15 13:49:35 ipsec: 12[CFG] proposing traffic selectors for us: [I] Jan 15 13:49:35 ipsec: 12[CFG] 48.210.2.2/32[gre] [I] Jan 15 13:49:35 ipsec: 12[CFG] proposing traffic selectors for other: [I] Jan 15 13:49:35 ipsec: 12[CFG] 0.0.0.0/0[gre] [I] Jan 15 13:49:35 ipsec: 12[CFG] statistics was written [I] Jan 15 13:49:38 ipsec: 16[CFG] proposing traffic selectors for us: [I] Jan 15 13:49:38 ipsec: 16[CFG] 48.210.2.2/32[gre] [I] Jan 15 13:49:38 ipsec: 16[CFG] proposing traffic selectors for other: [I] Jan 15 13:49:38 ipsec: 16[CFG] 0.0.0.0/0[gre] [I] Jan 15 13:49:38 ipsec: 16[CFG] statistics was written [I] Jan 15 13:49:41 ipsec: 06[CFG] proposing traffic selectors for us: [I] Jan 15 13:49:47 ipsec: 08[CFG] 48.210.2.2/32[gre] [I] Jan 15 13:49:47 ipsec: 08[CFG] proposing traffic selectors for other: [I] Jan 15 13:49:47 ipsec: 08[CFG] 0.0.0.0/0[gre] [I] Jan 15 13:49:47 ipsec: 08[CFG] statistics was written [I] Jan 15 13:49:48 ndm: Hotspot::Manager: Delete neighbour: IP: 192.168.0.11, MAC: 00:00:00:00:00:00, Interface: Bridge0. [I] Jan 15 13:49:48 ndm: Hotspot::Manager: ARP Entries dump. [I] Jan 15 13:49:48 ndm: Hotspot::Manager: 0: IP: 192.168.0.9, MAC: 00:16:e8:25:c8:b3, Interface: Bridge0, Age: 41 s. [I] Jan 15 13:49:48 ndm: Hotspot::Manager: 1: IP: 192.168.0.200, MAC: 84:38:38:f4:e6:ac, Interface: Bridge0, Age: 35 s. [I] Jan 15 13:49:48 ndm: Hotspot::Manager: 2: IP: 192.168.0.8, MAC: a0:0a:bf:05:ec:77, Interface: Bridge0, Age: 44 s. [I] Jan 15 13:49:48 ndm: Hotspot::Manager: 3: IP: 192.168.0.10, MAC: d8:cb:8a:c3:88:d3, Interface: Bridge0, Age: 62 s. [I] Jan 15 13:49:48 ndm: Hotspot::Manager: 4: IP: 192.168.0.57, MAC: 00:1f:c6:88:a8:f3, Interface: Bridge0, Age: 56 s. [I] Jan 15 13:49:48 ipsec: 03[NET] received packet: from 212.20.13.66[500] to 48.210.2.2[500] [I] Jan 15 13:49:48 ipsec: 03[NET] waiting for data on sockets [I] Jan 15 13:49:48 ipsec: 15[MGR] checkout IKEv1 SA by message with SPIs ea9442eb0a815f48_i 0000000000000000_r [I] Jan 15 13:49:48 ipsec: 15[MGR] created IKE_SA (unnamed)[7] [I] Jan 15 13:49:48 ipsec: 15[NET] received packet: from 212.20.13.66[500] to 48.210.2.2[500] (180 bytes) [I] Jan 15 13:49:48 ipsec: 15[ENC] parsed ID_PROT request 0 [ SA V V V V V ] [I] Jan 15 13:49:48 ipsec: 15[CFG] looking for an ike config for 48.210.2.2...212.20.13.66 [I] Jan 15 13:49:48 ipsec: 15[CFG] candidate: %any...%any, prio 28 [I] Jan 15 13:49:48 ipsec: 15[CFG] found matching ike config: %any...%any with prio 28 [I] Jan 15 13:49:48 ipsec: 15[IKE] received XAuth vendor ID [I] Jan 15 13:49:48 ipsec: 15[IKE] received DPD vendor ID [I] Jan 15 13:49:48 ipsec: 15[IKE] received FRAGMENTATION vendor ID [I] Jan 15 13:49:48 ipsec: 15[IKE] received NAT-T (RFC 3947) vendor ID [I] Jan 15 13:49:48 ipsec: 15[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID [I] Jan 15 13:49:48 ipsec: 15[IKE] 212.20.13.66 is initiating a Main Mode IKE_SA [I] Jan 15 13:49:48 ipsec: 15[IKE] IKE_SA (unnamed)[7] state change: CREATED => CONNECTING [I] Jan 15 13:49:48 ipsec: 15[CFG] selecting proposal: [I] Jan 15 13:49:48 ipsec: 15[CFG] no acceptable ENCRYPTION_ALGORITHM found [I] Jan 15 13:49:48 ipsec: 15[CFG] selecting proposal: [I] Jan 15 13:49:48 ipsec: 15[CFG] no acceptable DIFFIE_HELLMAN_GROUP found [I] Jan 15 13:49:48 ipsec: 15[CFG] selecting proposal: [I] Jan 15 13:49:48 ipsec: 15[CFG] no acceptable ENCRYPTION_ALGORITHM found [I] Jan 15 13:49:48 ipsec: 15[CFG] selecting proposal: [I] Jan 15 13:49:48 ipsec: 15[CFG] no acceptable ENCRYPTION_ALGORITHM found [I] Jan 15 13:49:48 ipsec: 15[CFG] selecting proposal: [I] Jan 15 13:49:48 ipsec: 15[CFG] proposal matches [I] Jan 15 13:49:48 ipsec: 15[CFG] received proposals: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/# [I] Jan 15 13:49:48 ipsec: 15[CFG] configured proposals: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/# [I] Jan 15 13:49:48 ipsec: 15[CFG] selected proposal: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/# [I] Jan 15 13:49:48 ipsec: 15[IKE] sending DPD vendor ID [I] Jan 15 13:49:48 ipsec: 15[IKE] sending FRAGMENTATION vendor ID [I] Jan 15 13:49:48 ipsec: 15[IKE] sending NAT-T (RFC 3947) vendor ID [I] Jan 15 13:49:48 ipsec: 15[ENC] generating ID_PROT response 0 [ SA V V V ] [I] Jan 15 13:49:48 ipsec: 15[NET] sending packet: from 48.210.2.2[500] to 212.20.13.66[500] (148 bytes) [I] Jan 15 13:49:48 ipsec: 04[NET] sending packet: from 48.210.2.2[500] to 212.20.13.66[500] [I] Jan 15 13:49:48 ipsec: 15[MGR] checkin IKE_SA (unnamed)[7] [I] Jan 15 13:49:48 ipsec: 15[MGR] checkin of IKE_SA successful [I] Jan 15 13:49:48 ipsec: 03[NET] received packet: from 212.20.13.66[500] to 48.210.2.2[500] [I] Jan 15 13:49:48 ipsec: 07[MGR] checkout IKEv1 SA by message with SPIs ea9442eb0a815f48_i d8441ce5e4338e6a_r [I] Jan 15 13:49:48 ipsec: 07[MGR] IKE_SA (unnamed)[7] successfully checked out [I] Jan 15 13:49:48 ipsec: 07[NET] received packet: from 212.20.13.66[500] to 48.210.2.2[500] (244 bytes) [I] Jan 15 13:49:48 ipsec: 07[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ] [I] Jan 15 13:49:48 ipsec: 03[NET] waiting for data on sockets [I] Jan 15 13:49:48 ipsec: 07[IKE] remote host is behind NAT [I] Jan 15 13:49:48 ipsec: 07[IKE] linked key for crypto map '(unnamed)' is not found, still searching [I] Jan 15 13:49:48 ipsec: 07[CFG] candidate "EoIP0", match: 1/1/28 (me/other/ike) [I] Jan 15 13:49:48 ipsec: 07[IKE] no shared key found for '48.210.2.2'[46.241.10.2] - '(null)'[212.20.13.66] [I] Jan 15 13:49:48 ipsec: 07[IKE] no shared key found for 48.210.2.2 - 212.20.13.66 [I] Jan 15 13:49:48 ipsec: 07[IKE] queueing INFORMATIONAL task [I] Jan 15 13:49:48 ipsec: 07[IKE] activating new tasks [I] Jan 15 13:49:48 ipsec: 07[IKE] activating INFORMATIONAL task [I] Jan 15 13:49:48 ipsec: 07[ENC] generating INFORMATIONAL_V1 request 1225341663 [ N(INVAL_KE) ] [I] Jan 15 13:49:48 ipsec: 07[NET] sending packet: from 48.210.2.2[500] to 212.20.13.66[500] (56 bytes) [I] Jan 15 13:49:49 ipsec: 07[MGR] checkin and destroy IKE_SA (unnamed)[7] [I] Jan 15 13:49:49 ipsec: 07[IKE] IKE_SA (unnamed)[7] state change: CONNECTING => DESTROYING [I] Jan 15 13:49:49 ipsec: 07[MGR] checkin and destroy of IKE_SA successful [I] Jan 15 13:49:49 ipsec: 04[NET] sending packet: from 48.210.2.2[500] to 212.20.13.66[500]Проверил mytestingkey, со стороны модема и в конфиге линукса написано один в один, только на модеме это без кавычек делается.
В чём может быть проблема? Кто-то на линуксе добился рабочей конфигурации?
-
Добрый день!
На моей Giga II используется NAT. У меня вопрос по автоматической настройке EoIP over IPSec туннеля. Поднимаю интерфейс и что вижу:
Connections:
EoIP0: %any...%any IKEv1, dpddelay=30s
EoIP0: local: [48.210.2.2] uses pre-shared key authentication
EoIP0: remote: uses pre-shared key authentication
EoIP0: child: 48.210.2.2/32[gre] === 0.0.0.0/0[gre] TRANSPORT, dpdaction=restartIPSec туннель в автоматическом режиме настраивается как транспорт, следовательно туннель у меня с NAT на роутере работать не будет?
-
В 08.11.2016 в 16:59, Le ecureuil сказал:
В случае установки компонента ipsec появляется возможность защищать эти туннели при помощи IPsec, причем как в автоматическом, так и в полностью ручном режиме. Ручной режим здесь описан не будет, поскольку продвинутые юзеры сами всегда могут сперва настроить IPsec с правильным режимом, а затем поверх IPsec поднять туннель. В случае автоматической настройки решается сразу несколько проблем ручного режима:
Видимо это мой случай, только до продвинутого мне ещё расти
А в автоматическом режиме можно выбрать алгоритмы шифрования, или там есть всё, просто зависит от того что "клиент" предложит?
ipsec.conf для strongswan как будет выглядеть если будет автоматический режим на роутере применён, например rightid какой указывать?
ipsec.conf # ipsec.conf - strongSwan IPsec configuration file # basic configuration config setup # strictcrlpolicy=yes # uniqueids = no # Add connections here. # Sample VPN connections conn IPSect ikelifetime=3h lifetime=3h ike=aes128-sha1-modp1024! esp=aes128-sha1-modp1024! left=192.168.2.2 leftid=beta@tester.ru # любой подоёдёт т.к. со стороны модема стоит "any" leftauth=psk leftsubnet=192.168.2.2/32 right=48.210.2.2 rightid=alpha@tester.ru # для работы PSK не обязательно чтобы адрес был (может в openswan актуально?) rightsubnet=192.168.0.0/24 rightauth=psk keyexchange=ikev1 auto=startsecurity-level private надо указывать со стороны роутера? А также isolate-private?
Как вообще эти опции отразятся на ipsec.conf на клиенте?
-
Добрый день!
Парни, дайте пожалуйста пример для следующей ситуации:
один офис имеет белый IP, второй нет. В первом где серый IP стоит сервер (linux), к которому нужен доступ из интернет.
Задача, подключить сервер из второго офиса, без белого IP через IPSec/IPIP к первому офису с белым IP, чтобы к нему могли обращаться из интернет, например по 80 порту.
Мои жалкие потуги не увенчались успехом.
Первоначально был настроен IPSec тоннель, работает, но без маршрутизации. Попытался настроить IPIP тоннель поверх него, но что-то пошло не так. Не пингуется удалённая точка IPIP тоннеля. Подозреваю, что проблема с поднятием тоннеля со стороны сервера linux (что с новичка взять, типа меня, кроме проблем).
что сделано:
со стороны роутера всё по канонам:
(config)> interface IPIP0 (config-if)> tunnel destination 192.168.2.2 - ip машины на другом конце тоннеля IPSec (config-if)> ip address 10.0.0.1 255.255.255.0 (config-if)> security-level private (config-if)> upна linux:
ip tunnel add tun0 mode ipip local 192.168.2.2 remote 192.168.0.1 ip addr add 10.0.0.2/24 peer 10.0.0.1/24 dev tun0 ip link set tun0 upping на сервере до 10.0.0.1 не проходит. Соответственно с роутера до 10.0.0.2 тоже. Про маршрутизацию из интернета в тоннель IPIP или IPSec вообще молчу, с этим бы разобраться.
-
Могу предположить ещё один фантастический вариант. Поднять какой-нибудь прозрачный прокси на модеме и завернуть пакеты через него. Есть же там возможность установки свободных пакетов.
Но это именно, что из области фантастики. Даже не знаю есть ли такой пакет в готовом виде.
А что, на 2.09 сразу всё заработает или там какие-то дополнительные настройки сделать придётся? Глупость конечно спросил, пойду читать.
-
PPTP признаётся менее надёжным, вот и полез в IPSec. Надо теперь как-то подумать о надёжности.
-
Каким образом можно подключить web-сервер удалённого офиса к Zyxel Giga II чтобы можно было к нему из интернет обращаться? Провайдер удалёного офиса не может дать белый IP, надо как-то зацепиться сервером к центральному офису с белым IP и при этом иметь доступ из интернет к этому удалённому web-серверу. Есть способы?
-
только теперь вопрос, компьютер подключенный к GIGA не доступен из интернет over IPSec. Правило NAT на КЦ прописал для 192.168.2.2 на порт 80, но telnet не хочет цепляться по прокинутому порту.
Эм... это возможно?
-
Переделал настройки пока так:
в качестве удалённой сети выступает конкретный клиент (сервер 192.168.2.2), так задумано, чтобы вся удалённая сетка не шарилась по локальной, только один сервер.
установил strongswan.
как описано в статье всё, что связано с openssl, я не правил, у меня запуск swanctl не показал ошибку.
поправил только конфигурацию логирования (логи великое дело, по логам нашёл три ошибки в настройках конфигурации)
в итоге рабочая конфига:
ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
# strictcrlpolicy=yes
# uniqueids = no
# Add connections here.
# Sample VPN connections
conn IPSect
ikelifetime=3h
lifetime=3h
ike=aes128-sha1-modp1024!
esp=aes128-sha1-modp1024!
left=192.168.2.2
leftid=beta@tester.ru # любой подоёдёт т.к. со стороны модема стоит "any"
leftauth=psk
leftsubnet=192.168.2.2/32
right=48.210.2.2
rightid=alpha@tester.ru # для работы PSK не обязательно чтобы адрес был (может в openswan актуально?)
rightsubnet=192.168.0.0/24
rightauth=psk
keyexchange=ikev1
auto=startipsec.secrets
# ipsec.secrets - strongSwan IPsec secrets file
192.168.2.2 48.210.2.2 : PSK "12345678"делаем ipsec restart и всё работает
Всякие данные по шлюзам и другим IP адресам со стороны клиента и шлюза провайдера оказались не нужны. (212.20.13.66 и 213.228.116.18, 48.210.2.1)
-
Добрый день!
Спасибо за советы! Настройки делал аналогично этой статье, кроме параметров шифрования - https://zyxel.ru/kb/4881/ но на linux shrew-client-vpn почему-то не взлетел, пакеты не ходили между клиентом и сетью, да и проект не развивается уже 4 года, так что я его тут даже не упоминаю.
По вашим замечаниям есть замечание :) это по поводу "- идентификатором лучше сделать какой-нибудь FQDN или e-mail, использование IP-адресов для этого - прошлый век и в первую очередь вопрос совместимости со всяким старьем." Вчера наткнулся на статью в журнале "Системный администратор" №1-2 2016г. по настройке strongswan, так там так и говорится - "leftid=212.20.5.1 – а это ключевое слово описывает идентификатор. Пусть вас не смущает то, что оно имеет то же значение, что и left, – смысл у него совершенно другой. Это аналог ключевого слова my_identifier в ipsec-tools. Для PSK он должен быть задан равным IP-адресу, иначе соединение не будет установлено." Проверю потом, когда получу рабочий конфиг. Кстати отличная статья впервые за три дня которая растолковывает что к чему на начальном уровне.
-
Здравствуйте!
Помогите пожалуйста с настройками клиентов на linux для начинающих. Хотя бы просто примеры ipsec.conf.
Для следующей конфигурации:
На Giga II поднял IPSec VPN c такими настройками:
Giga II на внешнем интерфейсе имеет адрес 48.210.2.2, шлюз 48.210.2.1, внутренняя сеть 192.168.0.0/24 сидит за NAT, шлюз 192.168.0.1
Клиент находится за натом 192.168.2.2/32, шлюз 192.168.2.1, iptables пустой, без правил, Внешний адрес у клиента 212.20.13.66, шлюз 213.228.116.18
Третий день не могу понять, что и как надо настроить. Во первых сбивает с толку разница в терминологии, там left и right, здесь local и remote (локальная и удалённая сеть). У кинетика это left или right сторона?
Ну и всё в таком духе, в общем первый опыт и пока во всём разберёшся... не работает пока. Прошу помощи.
Как настроить IPSec/GRE туннель c Linux и пробросить по туннелю порт?
in Обсуждение IPsec, OpenVPN и других туннелей
Posted
Добрый день!
Можно сказать почти у цели если бы не одно НО, не работает туннель так как надо.
Между двумя linux машинами эта конфигурация работает, а вот linux в паре с Zyxeleм артачится. Пытаюсь пропинговать другой конец туннеля, мне возвращается:
не пойму, что Zyxel отправляет такого, что linux не может понять куда направить пакет?
Когда между двумя машинками работает схема, то на машине за серым IP трассировка iptables ловит следующую последовательность пакетов:
июл 25 17:37:48 arch2 kernel: TRACE: raw:PREROUTING:policy:5 IN=enp4s0 OUT= MAC=00:1a:64:94:68:74:b8:a3:86:ba:ea:03:08:00 SRC=46.X.Y.Z DST=192.168.2.2 LEN=176 TOS=0x00 PREC=0x00 TTL=56 ID=35069 DF PROTO=UDP SPT=4500 DPT=4500 LEN=156
июл 25 17:37:48 arch2 kernel: TRACE: filter:INPUT:policy:3 IN=enp4s0 OUT= MAC=00:1a:64:94:68:74:b8:a3:86:ba:ea:03:08:00 SRC=46.X.Y.Z DST=192.168.2.2 LEN=176 TOS=0x00 PREC=0x00 TTL=56 ID=35069 DF PROTO=UDP SPT=4500 DPT=4500 LEN=156
июл 25 17:37:48 arch2 kernel: TRACE: raw:PREROUTING:rule:3 IN=enp4s0 OUT= MAC=00:1a:64:94:68:74:b8:a3:86:ba:ea:03:08:00 SRC=192.168.0.1 DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=23868 DF PROTO=47
июл 25 17:37:48 arch2 kernel: TRACE: raw:PREROUTING:policy:5 IN=enp4s0 OUT= MAC=00:1a:64:94:68:74:b8:a3:86:ba:ea:03:08:00 SRC=192.168.0.1 DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=23868 DF PROTO=47
июл 25 17:37:48 arch2 kernel: TRACE: filter:INPUT:rule:1 IN=enp4s0 OUT= MAC=00:1a:64:94:68:74:b8:a3:86:ba:ea:03:08:00 SRC=192.168.0.1 DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=23868 DF PROTO=47
июл 25 17:37:48 arch2 kernel: TRACE: raw:OUTPUT:policy:5 IN= OUT=enp4s0 SRC=192.168.2.2 DST=192.168.0.1 LEN=136 TOS=0x00 PREC=0xC0 TTL=64 ID=39883 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.0.1 DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=23868 DF PROTO=47 ]
июл 25 17:37:48 arch2 kernel: TRACE: filter:OUTPUT:policy:1 IN= OUT=enp4s0 SRC=192.168.2.2 DST=192.168.0.1 LEN=136 TOS=0x00 PREC=0xC0 TTL=64 ID=39883 PROTO=ICMP TYPE=3 CODE=3 [SRC=192.168.0.1 DST=192.168.2.2 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=23868 DF PROTO=47 ]
июл 25 17:37:48 arch2 kernel: TRACE: raw:OUTPUT:rule:4 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=208 TOS=0x00 PREC=0xC0 TTL=64 ID=17995 PROTO=UDP SPT=4500 DPT=4500 LEN=188
июл 25 17:37:48 arch2 kernel: TRACE: raw:OUTPUT:policy:5 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=208 TOS=0x00 PREC=0xC0 TTL=64 ID=17995 PROTO=UDP SPT=4500 DPT=4500 LEN=188
июл 25 17:37:48 arch2 kernel: TRACE: filter:OUTPUT:policy:1 IN= OUT=enp4s0 SRC=192.168.2.2 DST=46.X.Y.Z LEN=208 TOS=0x00 PREC=0xC0 TTL=64 ID=17995 PROTO=UDP SPT=4500 DPT=4500 LEN=188
Между машинками linux последовательность пакетов на машинке за серым IP выглядит так:
Jul 25 04:54:56 H1 kernel: TRACE: raw:PREROUTING:policy:7 IN=ens4 OUT= MAC=52:54:00:c2:cb:4d:52:54:00:fe:8d:e9:08:00 SRC=192.168.2.202 DST=10.0.1.2 LEN=192 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=172
Jul 25 04:54:56 H1 kernel: TRACE: filter:INPUT:policy:2 IN=ens4 OUT= MAC=52:54:00:c2:cb:4d:52:54:00:fe:8d:e9:08:00 SRC=192.168.2.202 DST=10.0.1.2 LEN=192 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=172
Jul 25 04:54:56 H1 kernel: TRACE: raw:PREROUTING:rule:1 IN=ens4 OUT= MAC=52:54:00:c2:cb:4d:52:54:00:fe:8d:e9:08:00 SRC=10.0.2.1 DST=10.0.1.2 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=47914 DF PROTO=47
Jul 25 04:54:56 H1 kernel: TRACE: raw:PREROUTING:rule:5 IN=ens4 OUT= MAC=52:54:00:c2:cb:4d:52:54:00:fe:8d:e9:08:00 SRC=10.0.2.1 DST=10.0.1.2 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=47914 DF PROTO=47
Jul 25 04:54:56 H1 kernel: TRACE: raw:PREROUTING:policy:7 IN=ens4 OUT= MAC=52:54:00:c2:cb:4d:52:54:00:fe:8d:e9:08:00 SRC=10.0.2.1 DST=10.0.1.2 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=47914 DF PROTO=47
Jul 25 04:54:56 H1 kernel: TRACE: filter:INPUT:rule:1 IN=ens4 OUT= MAC=52:54:00:c2:cb:4d:52:54:00:fe:8d:e9:08:00 SRC=10.0.2.1 DST=10.0.1.2 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=47914 DF PROTO=47
Jul 25 04:54:56 H1 kernel: TRACE: raw:PREROUTING:policy:7 IN=grelan OUT= MAC=4a:d6:f9:19:3e:36:32:cf:6f:83:fb:5f:08:00 SRC=192.168.100.2 DST=192.168.100.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=48128 DF PROTO=ICMP TYPE=8 CODE=0 ID=647 SEQ=1
Jul 25 04:54:56 H1 kernel: TRACE: filter:INPUT:policy:2 IN=grelan OUT= MAC=4a:d6:f9:19:3e:36:32:cf:6f:83:fb:5f:08:00 SRC=192.168.100.2 DST=192.168.100.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=48128 DF PROTO=ICMP TYPE=8 CODE=0 ID=647 SEQ=1
Jul 25 04:54:56 H1 kernel: TRACE: raw:OUTPUT:policy:5 IN= OUT=grelan SRC=192.168.100.1 DST=192.168.100.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=26909 PROTO=ICMP TYPE=0 CODE=0 ID=647 SEQ=1
Jul 25 04:54:56 H1 kernel: TRACE: filter:OUTPUT:policy:1 IN= OUT=grelan SRC=192.168.100.1 DST=192.168.100.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=26909 PROTO=ICMP TYPE=0 CODE=0 ID=647 SEQ=1
Jul 25 04:54:56 H1 kernel: TRACE: raw:OUTPUT:policy:5 IN= OUT=ens4 SRC=10.0.1.2 DST=10.0.2.1 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=33368 DF PROTO=47
Jul 25 04:54:56 H1 kernel: TRACE: filter:OUTPUT:policy:1 IN= OUT=ens4 SRC=10.0.1.2 DST=10.0.2.1 LEN=122 TOS=0x00 PREC=0x00 TTL=64 ID=33368 DF PROTO=47
Jul 25 04:54:56 H1 kernel: TRACE: raw:OUTPUT:rule:4 IN= OUT=ens4 SRC=10.0.1.2 DST=192.168.2.202 LEN=192 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=172
Jul 25 04:54:56 H1 kernel: TRACE: raw:OUTPUT:policy:5 IN= OUT=ens4 SRC=10.0.1.2 DST=192.168.2.202 LEN=192 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=172
Jul 25 04:54:56 H1 kernel: TRACE: filter:OUTPUT:policy:1 IN= OUT=ens4 SRC=10.0.1.2 DST=192.168.2.202 LEN=192 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=172
Но в связке linux - Zyxel машина на linux не может понять, что прилетело в GRE пакете от Zyxel, сразу даёт ответ о недостижимости хоста:
Если честно, не могу разобраться, где я делаю ошибку? Или данная схема в принципе в паре linux - Zyxel работать не будет? (ну там чистый GRE нужен, или destination только на внешний интерфейс садить нужно)
В каком случае эта схема будет работать? В чём особенность? Может я зря не завернул всё в чистый GRE на IPSEC? Может поэтому не работает? Или на линуксовой машине что-то надо добавить, чтобы именно в паре с Zyxel заработало?
конфигурация на linux:
ip route:
default via 192.168.2.1 dev enp4s0
46.X.Y.Z via 192.168.2.1 dev enp4s0
192.168.2.0/24 dev enp4s0 proto kernel scope link src 192.168.2.2
192.168.100.0/24 dev grelan proto kernel scope link src 192.168.100.2
ip address:
1: lo: <LOOPBACK,UP,LOWER_UP> ...
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:1a:64:94:68:74 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.2/24 brd 192.168.2.255 scope global enp4s0
....
3: enp6s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:1a:64:94:68:76 brd ff:ff:ff:ff:ff:ff
4: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000
link/gre 0.0.0.0 brd 0.0.0.0
5: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
8: grelan@enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether 02:90:68:cc:4f:47 brd ff:ff:ff:ff:ff:ff
inet 192.168.100.2/24 scope global grelan
...
отладочную информацию прикрепил следом.