Jump to content

Настройка клиента VPNC (CISCO VPN) и маршрутизации


Recommended Posts

Только что, Oleg Borovkov сказал:

Хм. В этом случае возможно я ошибся. Альфу даже не видел, только БЕТы. Значит терпим и ждем....

Если вы не видели альфу, это не говорит о том что её нет! )))

Как только увидите в changelog, что 3.7 вышла стабильная, через сутки, двое парни откроют канал альфа 3.8 и там повеселимся, как обычно...

Link to comment
Share on other sites

4 минуты назад, Oleg Borovkov сказал:

Хм. В этом случае возможно я ошибся. Альфу даже не видел, только БЕТы. Значит терпим и ждем....

а вот теперь, когда 

18 минут назад, Oleg Borovkov сказал:

А то не дошло

но теперь дошло иначе, возможно имеет смысл спрашивать когда выйдет 3.7

Link to comment
Share on other sites

1 час назад, Mamay сказал:

Если вы не видели альфу, это не говорит о том что её нет! )))

Как только увидите в changelog, что 3.7 вышла стабильная, через сутки, двое парни откроют канал альфа 3.8 и там повеселимся, как обычно...

Я бы с удовольствием по пользовал альфу. но по каналу разраба достается только бета.

Возможно, как всякому русскому человеку "дай по мацать"

Link to comment
Share on other sites

1 час назад, enterfaza сказал:

а вот теперь, когда 

но теперь дошло иначе, возможно имеет смысл спрашивать когда выйдет 3.7

Что когда? простите не понял.

 

Так 3.7 вышла. пользую последнюю бету

Link to comment
Share on other sites

4 минуты назад, Oleg Borovkov сказал:

Так 3.7 вышла. пользую последнюю бету

вы и вправду не поняли все ещё

вот же вам сказали

2 часа назад, Mamay сказал:

Вы не поняли. У кинетиков фишка. Пока предыдущая мажорная версия не дорастёт до stable, миновав альфу и бетту, речь не идёт о новой альфе!!!

3.7 в релизе?

Link to comment
Share on other sites

  • 2 weeks later...

Вот тоже, очень интересует эта тема. Ставлю openconnect, туннель до Cisco ASA поднимается, маршруты на keenetic прилетают и даже в отличие от автора темы хосты за ASA отвечают на пинги. Но вот дальше - та же беда, все это не доступно из локалки. Есть подозрение, что NAT для tun1, который поднимается с помощью openconnect не работает. Пробовал руками добавить правило

iptables -t nat -I POSTROUTING -d 172.27.96.0/24 -s 192.168.100.0/24 -o tun1 -j MASQUERADE

не помогает. Счетчик пакетов для данного правила, так и остается нулевым. Может, что-то еще с interface security-level на keenetic следует подкрутить?

Link to comment
Share on other sites

  • 2 weeks later...

Продолжу пока разговор самим с собой. Пробовал ловить трафик на интерфейсах tcpdump-ом. Обнаружил, что пинги с самого роутера ходят до хостов за vpn сервером нормально только с src=ip на tun1. Если попытаться указать src=ip другого интерфейса роутера, например, смотрящим внутрь LAN, echo request уходит с интерфейса tun1 в сторону vpn сервера нормально, но останется без ответа. Если же сначала добавить правило nat-ирования (моё сообщение выше), echo reply начинает приходить нормально и для этого src. Напрашиваются выводы:

1) nat-ирование нужно, т.к. vpn сервер дропает все, что пришло с "неправильного" интерфейса, т.е. src!=ip tun1; 

2) при пингах хостов за vpn-сервером с любого хоста из моей LAN видно, что echo request нормально приходит на интерфейс br0, но на tun1 этот запрос не появляется. Вероятно, он дропается файерволом роутера. Надо разбираться с этим и/или, возможно, как уже писал выше с interface security-level . Позже попробую это подкрутить.

Edited by ale_xb
Link to comment
Share on other sites

Заработало. Дело оказалось, действительно в файрволе роутера. После команды no isolate-private доступ к хостам за vpn сервером из моей LAN появился. Мне это не совсем понятно, т.к. в справочнике CLI Keenetic написано, что всем создаваемым новым интерфейсам присваивается public security-level, а трафик из private (Home LAN) в public (tun1) разрешен по умолчанию. Возможно, здесь что-то работает не совсем так, т.к. интерфейс tun1 создан не средствами CLI, а вовсе доп.пакетом из entware и по команде show interface он (tun1) никак не отображается.  Попробовал отключить nat-ирование, т.е. убрать правило маскарадинга, все работает и без него. Странно, мои проверки в предыдущем посте показывали его необходимость. Впрочем, tcpdump на интерфейсе tun1 показал, что icmp request уходят с src=ip tun1, т.е. nat-ирование все же работает и без моего доп.правила. В справочнике CLI keenetic нашел команду ip nat vpn которая включает/выключает nat-ирование для vpn клиентов. Во-первых, не ясно, работает ли эта команда для любых vpn-клиентов или только, встроенных в прошивку или для части из них, во-вторых, не указано ее значение по умолчанию, но, похоже, что "включено". Вот так выглядит цепочка POSTROUTING в таблице nat. Проверил, команда no ip nat vpn удаляет из этой цепочки последнее 4-е правило, но доступ из моей LAN к хостам за vpn-сервером сохраняется и в этом случае:

 # iptables -t nat -nL POSTROUTING  --line-numbers
Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    _NDM_IPSEC_POSTROUTING_NAT  all  --  0.0.0.0/0            0.0.0.0/0
2    _NDM_SNAT  all  --  0.0.0.0/0            0.0.0.0/0
3    _NDM_MASQ  all  --  0.0.0.0/0            0.0.0.0/0
4    MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0            ndmmark match 0x40/0x40

 

Я не силен в netfilter/iptables, и несколько десятков цепочек/правил в Keenetic понять (пока) не могу, но все равно придется разбираться, как теперь это (файервол) правильно настроить при поднятом туннеле opennconnect, чтобы не попортить настройки безопасности на роутере. Ну и стартовый скрипт для openconnect добавить, конечно.

Edited by ale_xb
Link to comment
Share on other sites

@ale_xb

Все эти public/private и прочее из cli относится только к интерфейсам сознанным в cli

В вашем случае nat/firewall тоже нужно настраивать в еntware

И учитывать что цепочки часто пересоздаются

https://forum.keenetic.com/topic/1355-как-правильно-использовать-netfilter-в-opkg/

Edited by r13
Link to comment
Share on other sites

В этом и сложность, что на систему (приходится) параллельно воздействуют из двух мест - на уровне NDM Shell CLI Keenetic и собственно ОС Linux/bash/...

Edited by ale_xb
Link to comment
Share on other sites

В 17.12.2021 в 10:00, r13 сказал:

В вашем случае nat/firewall тоже нужно настраивать в еntware

Оказалось, что не обязательно. Достаточно добавить стандартными средствами Keenetic Cli или проще через web-интерфейс разрешающее правило (спасибо ТП), цитирую: "на Home сегменте достаточно сделать правило вида источник: локальная сеть, назначение: удалённая сеть, протокол: ip, действие: разрешить"

У меня сразу все заработало. В netfilter правило в моем случае выглядит так (добавляется в таблицу по умолчанию filter, цепочку @Bridge0 )

root@keenetic:/opt/etc$ iptables -nL @Bridge0
Chain @Bridge0 (1 references)
target     prot opt source               destination
ACCEPT     all  --  192.168.100.0/24     172.27.96.0/20

Edited by ale_xb
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...