Перейти к содержанию

ale_xb

Участники форума
  • Постов

    50
  • Зарегистрирован

  • Посещение

Весь контент ale_xb

  1. Продолжу пока разговор самим с собой. Пробовал ловить трафик на интерфейсах 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 . Позже попробую это подкрутить.
  2. Вот тоже, очень интересует эта тема. Ставлю 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 следует подкрутить?
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.