OpenVPN, SIP и один доступный IP



  • Всем добрый день!
    Ситуация такая: есть удалённый сотрудник, есть сервер телефонии, есть openvpn туннель между сотрудником и pfsense, звонки ходят, всё прекрасно. НО тот удалённый сотрудник должен видеть, пинговать и тд только сервер телефонии, больше ничего из сети. Подскажите, возможно ли это реализовать?



  • Да.
    1. Сотрудник должен получать постоянный IP в туннеле.
    2. На закладке  Firewall->Open OVPN создается правило(а) для этого IP выше, чем общее разрешающее.



  • Я то же так думал, да не выходит..
    Сотрудник пингует компы в сетке, может посканировать и тд.
    Правда у меня в соурсе указана подсеть этого подключения openvpn.




  • С подсетью туннеля не пробовал.

    Вместо своего создайте запрещающее правило так:

    IPv4 * 10.0.254.0/29 * ! 192.168.12.81

    ! - это галка Invert match в Destination.

    Ниже этого правила можно оставить на будущее

    IPv4 * * * * * * none



  • Точно же! Спасибо большое! :)



  • Доброе.
    Есть еще вариант.
    Откл. NAT на Вашем ВПН туннеле. И тогда останется создать одно разреш. правило fw на OpenVPN, где в source будет его ip в своей сети (или целая его "родная" подсеть), а в dst - адрес SIP-сервера.



  • Мне кажется, что у ТС NAT для OpenVPN не включен.



  • Он автоматом вкл. Т.е. в логах виден не родной лок. адрес клиента, а его туннельный IP.
    Это легко можете проверить у себя.



  • Т.е. в логах виден не родной лок. адрес клиента, а его туннельный IP.
    Да, вы правы, виден туннельный IP и это естественно для "мобильного" пользователя.
    Поправьте, если неправ, но в случае NAT клиент попадал бы в LAN с IP серверного конца OVPN-сервера, а не со своим, полученным в туннеле.

    где в source будет его ip в своей сети (или целая его "родная" подсеть),
    И эта "родная" сеть запросто (не обязательно у ТС, а вообще) может пересечься с сетью LAN за pfSense, особенно если используется любимый всеми 192.168.x.x

    И если пользователь меняет места вызова, придется правило(а) дополнять\редактировать.
    IMHO, правильнее привязать пользователя к конкретному IP туннеля и не зависеть от адресации LAN в месте вызова.



  • Поправьте, если неправ, но в случае NAT клиент попадал бы в LAN с IP серверного конца OVPN-сервера, а не со своим, полученным в туннеле.

    Если он поднимает туннель сам, то виден его туннельный ip, т.е. его конец туннеля. Опять же можно отмониторить.

    И эта "родная" сеть запросто (не обязательно у ТС, а вообще) может пересечься с сетью LAN за pfSense, особенно если используется любимый всеми 192.168.x.x

    Верно. Но тут в любом случае возможны проблемы , если удален. лок. адрес, к к-му обращается внешний клиент пересекается с таким же адресом в его родной лок. сети.

    И если пользователь меняет места вызова, придется правило(а) дополнять\редактировать.
    IMHO, правильнее привязать пользователя к конкретному IP туннеля и не зависеть от адресации LAN в месте вызова.

    Верно. Если учесть все выше сказанное - лучший вариант.

    В своем же совете исхожу из самого простого случая - внешний клиент работает стационарно и у него есть постоянный локальн. ip, к-ым можно "оперировать" при создании правил fw на пф.