Jump to content

Search the Community

Showing results for tags 'linux'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Keenetic Community
    • Forum policy
    • Community Support & Knowledge Exchange
    • Off-topic lounge
  • Keenetic Updates
    • KeeneticOS
    • Keenetic mobile application
    • Keenetic RMM system
  • Форум пользователей Keenetic
    • Обмен опытом
    • KeeneticOS
    • Мобильное приложение
    • Keenetic RMM

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Location


Web-site


Interests


Occupation


AOL Account


ICQ Account


WLM


YAHOO


Facebook Account


Twitter Account


Skype Account


Youtube Account


Google+ Account


Keenetic

Found 6 results

  1. Провожу эксперименты с Yggdrasil, столкнулся с тем, что между роутером и другими устройствами в сети не работает связь по IPv6. Между устройствами (подключены через роутер) всё в порядке, ходит пинг, работает обнаружение по мультикасту и т.д. В Keenetic вставлена флешка с установленным дебианом по инструкции, добавлен модуль IPv6, да и собственно Yggdrasil скомпилированный вручную под MIPS запускается и работает нормально, только локальное обнаружение не работает. Я уже несколько зашёл в тупик, поэтому прошу помощи, это какая-то мистика. Пускаю пинг до хранилища: # ping fe80::76d4:35ff:fe07:12e9%eth2.1 PING fe80::76d4:35ff:fe07:12e9%eth2.1(fe80::76d4:35ff:fe07:12e9%eth2.1) 56 data bytes From fe80::5ef4:abff:fecf:f88%eth2.1 icmp_seq=1 Destination unreachable: Address unreachable From fe80::5ef4:abff:fecf:f88%eth2.1 icmp_seq=2 Destination unreachable: Address unreachable From fe80::5ef4:abff:fecf:f88%eth2.1 icmp_seq=3 Destination unreachable: Address unreachable From fe80::5ef4:abff:fecf:f88%eth2.1 icmp_seq=4 Destination unreachable: Address unreachable Параллельно смотрю трафик в tcpdump: # tcpdump -ns 0 -i eth2.1 icmp6 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth2.1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 18:47:08.133306 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 18:47:08.133487 IP6 fe80::76d4:35ff:fe07:12e9 > fe80::5ef4:abff:fecf:f88: ICMP6, neighbor advertisement, tgt is fe80::76d4:35ff:fe07:12e9, length 32 18:47:09.133236 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 18:47:09.133510 IP6 fe80::76d4:35ff:fe07:12e9 > fe80::5ef4:abff:fecf:f88: ICMP6, neighbor advertisement, tgt is fe80::76d4:35ff:fe07:12e9, length 32 18:47:11.157229 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 18:47:11.157364 IP6 fe80::76d4:35ff:fe07:12e9 > fe80::5ef4:abff:fecf:f88: ICMP6, neighbor advertisement, tgt is fe80::76d4:35ff:fe07:12e9, length 32 18:47:12.157406 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 18:47:12.157546 IP6 fe80::76d4:35ff:fe07:12e9 > fe80::5ef4:abff:fecf:f88: ICMP6, neighbor advertisement, tgt is fe80::76d4:35ff:fe07:12e9, length 32 18:47:12.202065 IP6 fe80::76d4:35ff:fe07:12e9 > fe80::5ef4:abff:fecf:f88: ICMP6, neighbor solicitation, who has fe80::5ef4:abff:fecf:f88, length 32 18:47:13.157340 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 18:47:13.157487 IP6 fe80::76d4:35ff:fe07:12e9 > fe80::5ef4:abff:fecf:f88: ICMP6, neighbor advertisement, tgt is fe80::76d4:35ff:fe07:12e9, length 32 18:47:13.226045 IP6 fe80::76d4:35ff:fe07:12e9 > fe80::5ef4:abff:fecf:f88: ICMP6, neighbor solicitation, who has fe80::5ef4:abff:fecf:f88, length 32 18:47:14.250330 IP6 fe80::76d4:35ff:fe07:12e9 > fe80::5ef4:abff:fecf:f88: ICMP6, neighbor solicitation, who has fe80::5ef4:abff:fecf:f88, length 32 То есть, устройство отвечает, но Keenetic почему-то игнорирует neighbor advertisement. Ещё интереснее, когда пинг идёт (а точнее, не идёт) в обратную сторону, с устройства до роутера: # ping fe80::5ef4:abff:fecf:f88%eth0 PING fe80::5ef4:abff:fecf:f88%eth0(fe80::5ef4:abff:fecf:f88%eth0) 56 data bytes From fe80::76d4:35ff:fe07:12e9%eth0 icmp_seq=1 Destination unreachable: Address unreachable From fe80::76d4:35ff:fe07:12e9%eth0 icmp_seq=2 Destination unreachable: Address unreachable From fe80::76d4:35ff:fe07:12e9%eth0 icmp_seq=3 Destination unreachable: Address unreachable From fe80::76d4:35ff:fe07:12e9%eth0 icmp_seq=4 Destination unreachable: Address unreachable From fe80::76d4:35ff:fe07:12e9%eth0 icmp_seq=5 Destination unreachable: Address unreachable From fe80::76d4:35ff:fe07:12e9%eth0 icmp_seq=6 Destination unreachable: Address unreachable На Keenetic трафик такой: # tcpdump -ns 0 -i eth2.1 icmp6 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth2.1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 18:50:06.009992 IP6 fe80::76d4:35ff:fe07:12e9 > ff02::1:ffcf:f88: ICMP6, neighbor solicitation, who has fe80::5ef4:abff:fecf:f88, length 32 18:50:07.016951 IP6 fe80::76d4:35ff:fe07:12e9 > ff02::1:ffcf:f88: ICMP6, neighbor solicitation, who has fe80::5ef4:abff:fecf:f88, length 32 18:50:08.040972 IP6 fe80::76d4:35ff:fe07:12e9 > ff02::1:ffcf:f88: ICMP6, neighbor solicitation, who has fe80::5ef4:abff:fecf:f88, length 32 18:50:09.065076 IP6 fe80::76d4:35ff:fe07:12e9 > ff02::1:ffcf:f88: ICMP6, neighbor solicitation, who has fe80::5ef4:abff:fecf:f88, length 32 18:50:10.088973 IP6 fe80::76d4:35ff:fe07:12e9 > ff02::1:ffcf:f88: ICMP6, neighbor solicitation, who has fe80::5ef4:abff:fecf:f88, length 32 18:50:11.112972 IP6 fe80::76d4:35ff:fe07:12e9 > ff02::1:ffcf:f88: ICMP6, neighbor solicitation, who has fe80::5ef4:abff:fecf:f88, length 32 18:50:12.136971 IP6 fe80::76d4:35ff:fe07:12e9 > ff02::1:ffcf:f88: ICMP6, neighbor solicitation, who has fe80::5ef4:abff:fecf:f88, length 32 18:50:13.160913 IP6 fe80::76d4:35ff:fe07:12e9 > ff02::1:ffcf:f88: ICMP6, neighbor solicitation, who has fe80::5ef4:abff:fecf:f88, length 32 18:50:14.184931 IP6 fe80::76d4:35ff:fe07:12e9 > ff02::1:ffcf:f88: ICMP6, neighbor solicitation, who has fe80::5ef4:abff:fecf:f88, length 32 Т.е. он даже не пытается отвечать на запросы, хотя они приходят. У меня есть подозрение на бридж, eth2.1 входит в br0 (у них также одинаковый MAC и link-local адрес IPv6). При пинге с Кинетика через br0 трафик такой: # tcpdump -ns 0 -i br0 icmp6 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 18:57:16.417233 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 18:57:17.417346 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 18:57:19.425234 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 18:57:20.425229 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 Т.е. запросы уходят, но ответов нет. Но устройство эти ответы отсылает (tcpdump на устройстве): 18:57:16.999506 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 18:57:16.999522 IP6 fe80::76d4:35ff:fe07:12e9 > fe80::5ef4:abff:fecf:f88: ICMP6, neighbor advertisement, tgt is fe80::76d4:35ff:fe07:12e9, length 32 18:57:17.999496 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 18:57:17.999529 IP6 fe80::76d4:35ff:fe07:12e9 > fe80::5ef4:abff:fecf:f88: ICMP6, neighbor advertisement, tgt is fe80::76d4:35ff:fe07:12e9, length 32 18:57:18.999637 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 18:57:18.999660 IP6 fe80::76d4:35ff:fe07:12e9 > fe80::5ef4:abff:fecf:f88: ICMP6, neighbor advertisement, tgt is fe80::76d4:35ff:fe07:12e9, length 32 18:57:21.007498 IP6 fe80::5ef4:abff:fecf:f88 > ff02::1:ff07:12e9: ICMP6, neighbor solicitation, who has fe80::76d4:35ff:fe07:12e9, length 32 Хотя iptables не должен влиять на захватываемый трафик, я всё же добавил правило в INPUT: # ip6tables-legacy -nvL Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 38 5776 ACCEPT all * * ::/0 ::/0 ... И совсем уж непонятно то, что при включении IPv6 для ISP он отчасти работает — роутер получает адрес, но не делегирует префикс в локалку (не знаю, у ТТК криво настроено или Кинетик что-то не так делает), пинг до ipv6.google.com с роутера работает, например. И в том числе пингуется шлюз провайдера по link-local! Что ещё пробовал: echo 0 > /sys/class/net/br0/bridge/multicast_snooping brctl stp br0 on Без эффекта. В ebtables и arptables пусто. Нагуглить ничего по такому поведению не удалось. Ещё по параметрам интерфейсов: # sysctl net/ipv6/conf/all net.ipv6.conf.all.accept_dad = 1 net.ipv6.conf.all.accept_ra = 1 net.ipv6.conf.all.accept_ra_defrtr = 1 net.ipv6.conf.all.accept_ra_pinfo = 1 net.ipv6.conf.all.accept_redirects = 1 net.ipv6.conf.all.accept_source_route = 0 net.ipv6.conf.all.autoconf = 1 net.ipv6.conf.all.dad_transmits = 1 net.ipv6.conf.all.disable_ipv6 = 0 net.ipv6.conf.all.force_mld_version = 0 net.ipv6.conf.all.force_tllao = 0 net.ipv6.conf.all.forwarding = 1 net.ipv6.conf.all.hop_limit = 64 net.ipv6.conf.all.max_addresses = 16 net.ipv6.conf.all.max_desync_factor = 600 net.ipv6.conf.all.mc_forwarding = 0 net.ipv6.conf.all.mtu = 1280 net.ipv6.conf.all.proxy_ndp = 0 net.ipv6.conf.all.regen_max_retry = 3 net.ipv6.conf.all.router_solicitation_delay = 1 net.ipv6.conf.all.router_solicitation_interval = 4 net.ipv6.conf.all.router_solicitations = 3 net.ipv6.conf.all.temp_prefered_lft = 86400 net.ipv6.conf.all.temp_valid_lft = 604800 net.ipv6.conf.all.use_tempaddr = 0 Для br0 и eth2.1 всё идентично, только mtu 1500.
  2. Задался вопросом... А можно ли сделать глобальный доступ к ssh по keendns ? Подскажите , пожалуйста, если кто-то делал... Ответ поддержки не дал результата... Может какой-то переброс портов ?
  3. Здравствуйте! Помогите пожалуйста с настройками клиентов на 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 сторона? Ну и всё в таком духе, в общем первый опыт и пока во всём разберёшся... не работает пока. Прошу помощи.
  4. Здравствуйте! Случилась оказия завести сервер который сидит за серым 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 route default 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
  5. Здравствуйте! Вопрос собственно в теме: Как на 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, со стороны модема и в конфиге линукса написано один в один, только на модеме это без кавычек делается. В чём может быть проблема? Кто-то на линуксе добился рабочей конфигурации?
  6. Здравствуйте. Помогите разобраться с подключением к VPN-серверу на роутере Keenetic Viva. 2 недели бьюсь и понять не могу где ошибка. Печали прибавляет то, что ради впн zyxel и купил) Keenetic Viva, NDMS v2.05(AANT.5)C4 Суть проблемы: впн-клиенты не получают маршрут до локальной сети за роутером, только до узла 192.168.1.1 1. Проверял на 3-х ПК (ОС Ubuntu 14.04 и Linux Mint 17), результат одинаковый. Техподдержка проверяла с ПК (ОС Windows): у них всё работает и маршрут до удаленной сети приходит. 2. Ранее я использовал роутер tp-link. На нем был проброшен порт до одной из локальных машин с ОС Ubuntu 14.04, где стоял pptpd. Так вот: те же самые клиенты подключались к тому pptp-серверу и получали автоматически маршрут до подсети, использовал обязательное шифрование 128 бит. Для удобства пулы впн и локальных клиентов имели одну подсеть и разные диапазоны. Но впн-сервер в роутере даже при такой же настройке пулов не выдает маршрут linux-клиентам. 3. Настроить 128-битное шифрование в впн-сервере не смог, нет там такой роскоши. Хотя дело вряд ли в этом, но всё же. 4. При добавлении вручную маршрута в свойствах vpn-подключения на клиентах всё начинает работать. Спасибо всем кто отзовется.
×
×
  • Create New...