Ygvuvgugu
-
Posts
12 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by Ygvuvgugu
-
-
21 hours ago, vasek00 said:
Возможно попробовать в направление
есть диаграмма на которой показано взаимодействие интерфейсов между собой. По default настройкам ПО в наличие
Увы, это попробовал - не помогло...
21 hours ago, vasek00 said:Вы не рассматривали вопрос по переходу с WG на IPIP/EoIP.
Рассматривал, и более того планирую это внедрить. EoIP хорошо работает между двумя Keenetic или двумя Mikrotik.
Однако, мне нужно подружить Keenetic и Mikrotik - и тут сталкиваюсь с проблемами...видимо, скоро будет еще один пост на форуме)
19 hours ago, qmxocynjca said:В CLI есть такая штука, она позволяет DHCP серверу отдавать дополнительные данные клиентам:
Большое спасибо за наводку! Это именно то, что нужно, задача полностью решилась.
-----
Для тех, кому пригодится информация из данной темы, мне помогла команда:
ip dhcp pool _WEBADMIN option 121 ascii 192.168.5.0/24,192.168.7.1где 192.168.5.0/24 - куда я хочу иметь доступ, 192.168.7.1 - шлюз, через который доступ нужно организовать.
-
По какой-то причине keenetic не раздает маршрут в локальную сеть.
Для эксперимента настроил все те же самые параметры на mikrotik, маршрут пришел.
Но хочется всё же оставить keenetic, поэтому просьба о помощи все еще актуальна...
-
7 hours ago, vasek00 said:
А можно полную вашу схеме кто где и куда хочет, а то есть упоминания в маршрутах про 192.168.4.х, 192.168.5.х, 192.168.7.х ?
192.168.4.0/22 - общая сеть, объединяющая несколько локаций.
Все её сегменты (кусками по /24), кроме описываемых ниже, работают без проблем. /22 нужен для общего broadcast и связности на уровне L2 (в сетях ниже использовалось до недавнего времени, будет использоваться в будущем).192.168.5.0/22 - удаленный сегмент, куда хочу иметь доступ (далее - удаленная сеть)
Роутер keenetic,
шлюз 192.168.5.1/22,
Конец WG - 172.16.1.3192.168.7.0/22 - локальный сегмент, откуда доступ тестируется (далее - локальная сеть)
Роутер keenetic.
Шлюз 192.168.7.1
Конец WG - 172.16.1.2172.16.1.0/24 - сервисная сеть, используется для Wireguard.
Wireguard сервер поднят на mikrotik.
Конец WG - 172.16.1.1Прилагаю примерную схему, где зеленым выделил работающие маршруты, красным - то, что не удается достичь.
Spoiler
Машртуты кинетика в удаленной сети.
Spoiler{ "route": [ { "destination": "0.0.0.0/0", <-- весь трафик идет через WG "gateway": "0.0.0.0", "interface": "Wireguard0", "metric": 0, "proto": "boot", "floating": false }, { "destination": "xxxx/32", <-- провайдер "gateway": "0.0.0.0", "interface": "PPPoE0", "metric": 0, "proto": "kernel", "floating": false }, { "destination": "172.16.1.0/24", <-- автоматически создается при подключении WG (сервисная сеть WG) "gateway": "0.0.0.0", "interface": "Wireguard0", "metric": 0, "proto": "kernel", "floating": false }, { "destination": "xxx/32", "gateway": "0.0.0.0", "interface": "PPPoE0", "metric": 0, "proto": "boot", "floating": false }, { "destination": "192.168.4.0/22", "gateway": "0.0.0.0", "interface": "Home", "metric": 0, "proto": "kernel", "floating": false }, { "destination": "192.168.5.128/25", <-- все работает (соединение со второй, "дальней", частью удаленной сети) "gateway": "172.16.1.100", <-- все работает (конец WG второй, "дальней", частью удаленной сети) "interface": "Wireguard0", "metric": 0, "proto": "boot", "floating": false }, { "destination": "192.168.7.0/24", <-- соединение с локальной сетью, о которой говорил в посте. С роутера 192.168.5.1 пинг идет в роутер локальной сети и в саму локальную сеть. Проверить, идет ли пинг с устройств удаленной сети к устройствам локальной сети не могу. "gateway": "0.0.0.0", "interface": "Wireguard0", "metric": 0, "proto": "boot", "floating": false } ],Маршртуты кинетика в локальной сети (выкладывал ранее, дублирую):
Spoiler{ "route": [ { "destination": "0.0.0.0/0", "gateway": "Внешний IP", "interface": "ISP", "metric": 0, "proto": "boot", "floating": false }, { "destination": "Подсеть /29 провайдера", "gateway": "0.0.0.0", "interface": "ISP", "metric": 0, "proto": "kernel", "floating": false }, { "destination": "172.16.1.0/24", <--- маршрут до сети WG, который пришлось добавить "gateway": "0.0.0.0", "interface": "Wireguard0", "metric": 0, "proto": "boot", "floating": false }, { "destination": "172.16.1.0/24", <--- маршрут до сети WG, создается автоматически "gateway": "0.0.0.0", "interface": "Wireguard0", "metric": 0, "proto": "kernel", "floating": false }, { "destination": "xxxxxxx/32", <--- маршрут для подключения к WG серверу "gateway": "xxxx", "interface": "ISP", "metric": 0, "proto": "boot", "floating": false }, { "destination": "192.168.4.0/22", "gateway": "0.0.0.0", "interface": "Home", "metric": 0, "proto": "kernel", "floating": false }, { "destination": "192.168.5.0/24", <--- маршрут, который не видят устройства в локальной сети. При этом маршруте пинг с роутера 192.168.7.1 до устройств удаленной сети идет, пинг с устройств локальной сети до устройств удаленной сети не идет. "gateway": "0.0.0.0", "interface": "Wireguard0", "metric": 0, "proto": "boot", "floating": false } ], "prompt": "(config)" } -
1 hour ago, vasek00 said:
На обоих концах туннеля где адреса стоят 172.16.1.0/24 замените на реальные у которых маска /32, т.е. что там у вас будет конкретно 172.16.1.1/32 а на другой стороне так же 172.16.1.Х/32
Для сравнения так же "show ip route"
Заменил на маску /32.
Также пришлось добавить в разрешенные подсети отдельно подсеть WG и прописать для нее route, иначе роутеру и устройства в локальной сети было не видно других узлов в сети WG, только текущего клиента и сервер.
Симптомы остались все те же: я все также могу с устройств в локальной сети пинговать только сеть WG, но не могу пинговать удаленную сеть.
show ip route
Spoiler{ "route": [ { "destination": "0.0.0.0/0", "gateway": "Внешний IP", "interface": "ISP", "metric": 0, "proto": "boot", "floating": false }, { "destination": "Подсеть /29 провайдера", "gateway": "0.0.0.0", "interface": "ISP", "metric": 0, "proto": "kernel", "floating": false }, { "destination": "172.16.1.0/24", <--- маршрут до сети WG, который пришлось добавить "gateway": "0.0.0.0", "interface": "Wireguard0", "metric": 0, "proto": "boot", "floating": false }, { "destination": "172.16.1.0/24", <--- маршрут до сети WG, создается автоматически "gateway": "0.0.0.0", "interface": "Wireguard0", "metric": 0, "proto": "kernel", "floating": false }, { "destination": "xxxxxxx/32", <--- маршрут для подключения к WG серверу "gateway": "xxxx", "interface": "ISP", "metric": 0, "proto": "boot", "floating": false }, { "destination": "192.168.4.0/22", "gateway": "0.0.0.0", "interface": "Home", "metric": 0, "proto": "kernel", "floating": false }, { "destination": "192.168.5.0/24", <--- маршрут, который не видят устройства в локальной сети "gateway": "0.0.0.0", "interface": "Wireguard0", "metric": 0, "proto": "boot", "floating": false } ], "prompt": "(config)" }конфиг:
Spoileraccess-list _WEBADMIN_Wireguard0 permit icmp 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 permit ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 interface Wireguard0 description nl security-level public ip address 172.16.1.2 255.255.255.0 ip mtu 1324 ip access-group _WEBADMIN_Wireguard0 in ip tcp adjust-mss pmtu wireguard peer [ключ] ![имя] endpoint [IP сервера]:[порт] keepalive-interval 30 allow-ips 172.16.1.1 255.255.255.255 <--- изменил на маску /32 allow-ips 192.168.5.0 255.255.255.0 allow-ips 172.16.1.0 255.255.255.0 <--- пришлось добавить для доступа к другим узлам сети WG ! up ! ip route 192.168.5.0 255.255.255.0 Wireguard0 auto ip route 172.16.1.0 255.255.255.0 Wireguard0 autoПри этом, если отказаться от доступа к другим узлам сети WG (и соответственно, от сети 172.16.1.0/24 в разделе "разрешенные подсети" и от маршрута) то роутер выдает ошибку An I/O error occurred: unknown error 161. при попытке пинга, скажем, 172.16.1.3.
По сути же темы ничего не меняется, доступа к сети 192.168.5.0/24 все также нет для устройств в локальной сети. Роутер все также доступ к этой сети имеет без проблем.
-
Разрешенные сети прописаны корректно. Также пробовал 0.0.0.0/0 в качестве разрешенной сети, результат такой же (неудачный).
Перезагрузка всех участников процесса, и переподключение WG, не помогла...
-
3 minutes ago, vasek00 said:
Как и написал выше и в добавок два роутера соединены по WG, клиенты лок.сети каждого роутера видят клиентов друг друга.
Тогда почему, при аналогичных настройках, в моем случае схема буксует? Буду благодарен за подсказку.
Маршруты с роутера, который является клиентом WG, и с которым проблема:
Spoiler{ "route": [ { "destination": "0.0.0.0/0", "gateway": "Внешний IP", "interface": "ISP", "metric": 0, "proto": "boot", "floating": false }, { "destination": "Подсеть /29 провайдера", "gateway": "0.0.0.0", "interface": "ISP", "metric": 0, "proto": "kernel", "floating": false }, { "destination": "172.16.1.0/24", <== тоннель WG "gateway": "0.0.0.0", "interface": "Wireguard0", "metric": 0, "proto": "kernel", "floating": false }, { "destination": "192.168.4.0/22", <== домашняя сеть "gateway": "0.0.0.0", "interface": "Home", "metric": 0, "proto": "kernel", "floating": false }, { "destination": "192.168.5.0/24", <== маршрут, которым не могут воспользоваться устройства в локальной сети "gateway": "0.0.0.0", "interface": "Wireguard0", "metric": 0, "proto": "boot", "floating": false } ], "prompt": "(config)" }
Маршруты с клиента в локальной сети, который не видит нужный маршрут:
Spoiler➜ ~ netstat -nr Routing tables Internet: Destination Gateway Flags Netif Expire default 192.168.7.1 UGScg en0 127 127.0.0.1 UCS lo0 127.0.0.1 127.0.0.1 UH lo0 127.255.255.255 127.0.0.1 UHW3I lo0 20 169.254 link#4 UCS en0 ! 172.24.100/24 link#12 UC feth410 ! 192.168.4/22 link#4 UCS en0 ! 192.168.7.1/32 link#4 UCS en0 ! 192.168.7.1 1c:74:d:10:16:a0 UHLWIir en0 1200 192.168.7.80/32 link#4 UCS en0 ! 224.0.0/4 link#4 UmCS en0 ! 224.0.0.251 1:0:5e:0:0:fb UHmLWI en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI en0 255.255.255.255/32 link#4 UCS en0 !tracert до и после прописывания маршрута вручную:
Spoiler➜ ~ traceroute 192.168.5.1 traceroute to 192.168.5.1 (192.168.5.1), 64 hops max, 52 byte packets 1 * * * ^C➜ ~ sudo route -n add -net 192.168.5.1/24 192.168.7.1 Password: add net 192.168.5.1: gateway 192.168.7.1 ➜ ~ traceroute 192.168.5.1 traceroute to 192.168.5.1 (192.168.5.1), 64 hops max, 52 byte packets 1 192.168.7.1 (192.168.7.1) 3.675 ms 2.056 ms 1.445 ms 2 172.16.1.1 (172.16.1.1) 44.963 ms 56.290 ms 45.207 msМаршруты с клиента в локальной сети, который не видит нужный маршрут - после указания маршрута вручную:
Spoiler➜ ~ netstat -nr Routing tables Internet: Destination Gateway Flags Netif Expire default 192.168.7.1 UGScg en0 127 127.0.0.1 UCS lo0 127.0.0.1 127.0.0.1 UH lo0 169.254 link#4 UCS en0 ! 172.24.100/24 link#12 UC feth410 ! 172.24.100.28 link#12 UHLWIi feth410 ! 172.24.100.255 ff:ff:ff:ff:ff:ff UHLWbI feth410 ! 192.168.4/22 link#4 UCS en0 ! 192.168.5 192.168.7.1 UGSc en0 <-- нужный маршрут 192.168.7.1/32 link#4 UCS en0 ! 192.168.7.1 1c:74:d:10:16:a0 UHLWIir en0 1198 192.168.7.37 link#4 UHLWIi en0 ! 192.168.7.59 90:dd:5d:c3:d2:23 UHLWI en0 1195 192.168.7.80/32 link#4 UCS en0 ! 192.168.7.255 ff:ff:ff:ff:ff:ff UHLWbI en0 ! 224.0.0/4 link#4 UmCS en0 ! 224.0.0.251 1:0:5e:0:0:fb UHmLWI en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI en0 255.255.255.255/32 link#4 UCS en0 !
-
2 hours ago, vasek00 said:
Кто мешает прописать маршруты на сервер WG поднятый на mikrotik и на клиенте WG
Как я написал в посте, route прописан уже: клиент WG (в виде роутера keenetic) видит все, что нужно, и пингует все, что нужно.
Проблема на уровень ниже: устройства в локальной сети за клиентом WG не видят ничего, кроме сети WG. То есть маршрут, прописанный на роутере, они не получают.
-
Добрый день, сообщество.
Имею проблему с роутингом.
Сети:
- Удаленная сеть 192.168.5.0/22
- Домашняя сеть 192.168.7.0/22
Сети соединены по WireGuard, 172.16.1.0/24, где 172.16.1.1 - сервер WG, поднятый на mikrotik. Сервер расположен вне указанных сетей (в локации №3).
Ситуация:
Могу пинговать из сети Wireguard в удаленную и домашнюю сети.
Могу пинговать из удаленной сети в сеть Wireguard и в домашнюю сеть
С устройств, находящихся в домашней сети, могу пинговать только в сеть Wireguard, но не в удаленную сеть.
При этом с роутера в домашней сети пинг идет и в сеть Wireguard, и в удаленную сеть (то есть route прописан корректно).
Что сделано:
Временно могу решить проблему только прописывая маршрут
route -n add -net 192.168.5.1/24 192.168.7.1на устройствах в домашней сети, где 192.168.7.1 - роутер в домашней сети. Но на ТВ приставках такого не сделаешь.
Что хочу достичь:
Пинг с устройств в домашней сети доходит до устройств удаленной сети без необходимости прописывать вручную маршруты на клиентских устройствах домашней сети.
Нужна помощь
-
Попробовал не указывать для Keenetic режим ikev2 - судя по мануалу, в этом режиме должен использоваться режим ikev1 main.
В логах mikrotik:
phase1 negotiation failed due to time up [IP микротик на интерфейсе WAN (до второго NAT)][4500]<=>[keenetic][4500] 7aeb923aeeeb8ea6:2a30a26e5bddae41В логах Keenetic:
Spoiler02[IKE] received NAT-T (RFC 3947) vendor ID Aug 30 18:58:00 ipsec 02[IKE] received draft-ietf-ipsec-nat-t-ike-08 vendor ID Aug 30 18:58:00 ipsec 02[IKE] received draft-ietf-ipsec-nat-t-ike-07 vendor ID Aug 30 18:58:00 ipsec 02[IKE] received draft-ietf-ipsec-nat-t-ike-06 vendor ID Aug 30 18:58:00 ipsec 02[IKE] received draft-ietf-ipsec-nat-t-ike-05 vendor ID Aug 30 18:58:00 ipsec 02[IKE] received draft-ietf-ipsec-nat-t-ike-04 vendor ID Aug 30 18:58:00 ipsec 02[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID Aug 30 18:58:00 ipsec 02[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID Aug 30 18:58:00 ipsec 02[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID Aug 30 18:58:00 ipsec 02[IKE] received draft-ietf-ipsec-nat-t-ike-00 vendor ID Aug 30 18:58:00 ipsec 02[IKE] received Cisco Unity vendor ID Aug 30 18:58:00 ipsec 02[IKE] received DPD vendor ID Aug 30 18:58:00 ipsec 02[IKE] [IP mikrotik после второго NAT] is initiating a Main Mode IKE_SA Aug 30 18:58:00 ipsec [truncated] 02[CFG] received proposals: IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_521, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_256, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/(4), IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/(3), IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_8192, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_6144, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_4096, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_3072, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_768, IKE:CAMELLIA_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_521, IKE:CAMELLIA_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384, IKE:CAMELLIA_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_256, IKE:CAMELLIA_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/(4), IKE:CAMELLIA_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/ Aug 30 18:58:00 ipsec 02[CFG] configured proposals: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_256, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_256, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 Aug 30 18:58:00 ipsec 02[CFG] selected proposal: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 Aug 30 18:58:00 ipsec 02[IKE] sending XAuth vendor ID Aug 30 18:58:00 ipsec 02[IKE] sending DPD vendor ID Aug 30 18:58:00 ipsec 02[IKE] sending NAT-T (RFC 3947) vendor ID Aug 30 18:58:01 ipsec 05[IKE] remote host is behind NAT Aug 30 18:58:01 ipsec 05[IKE] linked key for crypto map '(unnamed)' is not found, still searching Aug 30 18:58:01 ipsec 12[IKE] message parsing failed Aug 30 18:58:01 ipsec 12[IKE] ID_PROT request with message ID 0 processing failed Aug 30 18:58:11 ipsec 02[IKE] message parsing failed Aug 30 18:58:11 ipsec 02[IKE] ID_PROT request with message ID 0 processing failed Aug 30 18:58:15 ndhcps DHCPREQUEST received (STATE_INIT) for 192.168.7.10 from d8:9e:f3:72:e4:90. Aug 30 18:58:16 ndhcps sending ACK of 192.168.7.10 to d8:9e:f3:72:e4:90. Aug 30 18:58:21 ipsec 08[IKE] message parsing failed Aug 30 18:58:21 ipsec 08[IKE] ID_PROT request with message ID 0 processing failed Aug 30 18:58:30 ipsec 10[JOB] deleting half open IKE_SA with [IP mikrotik после второго NAT] after timeoutТо есть обрыв еще на phase 1. Вот только как исправить проблему я не знаю.
-
3 hours ago, Le ecureuil said:
>> Keenetic устанавливает режим ikev2
Это вы сами включили, поменяйте настройки.
Да, включил сам: как я понял, ikev2 поддерживает NAT traversal, в то время как ikev1 - не поддерживает.
Понял неправильно?
-
Добрый день. Нужна помощь с настройкой EoIP между Keenetic и Mikrotik.
Дано:
Keenetic Ultra 2, KeeneticOS 3.5.10, белый IP, без NAT.
Сеть 192.168.7.0/22, адресное пространство 192.168.7.1-192.168.7.100Имеются успешные подключения к другому Keenetic через EoIP, где сеть 192.168.5.0/22. Интерфейсы добавлены в бриджи, DHCP запросы блокированы. В итоге все работает как одна огромная локальная сеть.
Mikrotik, RouterOS 6.48.1., серый IP, за NAT.
Сеть 192.168.6.0/22, адресное пространство 192.168.6.1-192.168.6.254Ранее:
Удавалось подключить Keenetic и Mikrotik: тогда были разные сегменты сети (192.168.4.0/24 и 192.168.100.0/24), и в режиме объединения сетей через IPsec работала связка. Но сейчас требуется L2.Сейчас:
При настройке подключения через добавление интерфейсов EoIP со встроенным IPSec соединение не устанавливается: Keenetic устанавливает режим ikev2, Mikrotik устанавливает режим "main" (и поменять его нельзя). В итоге на этапе фазы 2 всё разваливается.Пробовал также объединить сети, чтобы в дальнейшем уже по готовому IPsec проложить тоннель. Однако, Keenetic ругается: IP address is in conflict with an existing connection.
Пробовал подключать не используемые сети (192.168.99.0/24 и 192.168.99.0/24), чтобы добиться подключения и хотя бы роутингом завернуть трафик - тоже не получается, пинги не ходят не смотря на маршруты. Да и цель таким образом не достигну.
Пробовал L2TP/Ipsec (Keenetic в качестве сервера). Соединение устанавливается, пинг от Микротика до Кинетика идет (TTL 64). Однако пинги от Мироктика до устройствами за Кинетиком либо отсутсвуют, либо TTL 254, что не есть норма. Также в этом сценарии я так и не понял как поднять EoIP - у меня ни разу не запустилось.
Я не слишком силен в сетях, поэтому идеи что может быть не так уже закончились. Нужна помощь. Логи выложу, если подскажете какие именно нужны.
Маршрутизация
in Обсуждение IPsec, OpenVPN и других туннелей
Posted
Интересно, что если добавить опцию 121 в DHCP, то роутер перестает раздавать default route: он пропал на нескольких ubuntu. В настройках default route есть, но устройствами в сети он не принимается...