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

[Mamay]

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

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

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

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

[enterfaza]

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

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

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

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

А то не дошло

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

[Oleg Borovkov]

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

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

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

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

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

[Oleg Borovkov]

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

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

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

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

 

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

[enterfaza]

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

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

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

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

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

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

3.7 в релизе?

[Oleg Borovkov]

2 минуты назад, enterfaza сказал:

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

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

3.7 в релизе?

Извиняюсь. Виноват

[ale_xb]

Вот тоже, очень интересует эта тема. Ставлю 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 следует подкрутить?

[ale_xb]

Продолжу пока разговор самим с собой. Пробовал ловить трафик на интерфейсах 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 . Позже попробую это подкрутить.

Изменено 16 декабря, 2021 пользователем ale_xb

[ale_xb]

Заработало. Дело оказалось, действительно в файрволе роутера. После команды 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 добавить, конечно.

Изменено 16 декабря, 2021 пользователем ale_xb

[r13]

@ale_xb

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

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

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

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

Изменено 17 декабря, 2021 пользователем r13

[ale_xb]

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

Изменено 17 декабря, 2021 пользователем ale_xb

[ale_xb]

В 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

Изменено 21 декабря, 2021 пользователем ale_xb