Доступ к удаленной VPN через WAN pfSense (port forwarding)
-
Выставил статический маршрут XX.XXX.XXX.XX/27 -> WAN_DHCP - 192.168.8.1, вроде работает ! Такое решение вообще корректно ?
Как коcтыль - вполне.
Зы. Так и не увидел скринов правил fw (
Зы2. Вижу, что пф живет на гипер-в (с VLAN в ВМ-ах на нем "поиграйтесь", ага). Блин, ну есть же xen, vmware, KVM. Чего это "чудо" пользовать-то для fw? Лень что-то новое изучать, видимо.
-
@werter
Можно сказать лень, а можно сказать "некогда". В hyper-v есть галочка "Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру." Т.е. физическое соединение отдается под виртуалку, получается виртуальный шлюз межу интернетом и виртуалками. А пфсенс выбран за человеческий гуи, некогда читать толмуды и трах-ся с консолями, надо быстро решить конкретные и тривиальные задачи ... а что это - fw ? -
@Max69
Кстати обнаружился неприятный эффект - после обновления pfSense до 2.4.4 галочка "Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру." стала бесполезной. При запуске виртуалки c 2.4.4 сетевой адаптер становится доступным для хоста вне зависимости от галочки. Т.е. 2.4.4 не поддерживает эту фичу Hyper-V, и вообще локалка на прочих виртуалках пропала, короче обновление виртуального шлюза до 2.4.4 все ломает ... пришлось откатить до 2.3.3 обратно. Надо будет в официальную техподдержку запросить, что за бред ... -
@Max69
Зевает
Обновите hyper-v. Какой там у вас последний-то? Об чем вопрос?
А, забыл. Это ж MS. Это ж целый гемор с мажорными обновлениями-то.
У меня это 3 (буквами - три) команды в shell (после правки sources):
apt-get clean; apt-get update; apt-get dist-upgrade -yМожно сказать лень, а можно сказать "некогда".
Удачи с ленью.
Зы. Может тут чего docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-hyper-v.html
Или пишите в англоветке разрабам. Если это проблема пф, конечно. -
@werter Не знаю какой гемор, винда обновляется автоматом ... хочешь ставь все обновления, хочешь мажорные ...
никакого гемора не было до обновления пф до 2.4.4 -
@werter А есть на других виртуальных платформах аналогичная возможность создать виртуальный шлюз на базе пф для виртуальной локальной сети. Если вы настолько против Hyper-V подскажите альтернативу. Т.е. чтобы виртуалка закрывала физический сетевой порт порт даже для хоста.
-
@Max69 said in Доступ к удаленной VPN через WAN pfSense (port forwarding):
Не знаю какой гемор, винда обновляется автоматом
Попробуйте обновить Hyper-v 2012 до 2019 )
И да. Гипер-в бывает разный - отдельный и КАК РОЛЬ сервера. У вас какой?Т.е. чтобы виртуалка закрывала физический сетевой порт порт даже для хоста.
У PVE есть встроенный firewall c GUI. И без ВМ все можно гибко настроить. Мало того, этим же fw можно запретить\разрешить доступ к опред. портам\протоколам на самих VM. Для этого в настройках ВМ на сетевом интерфейсе есть галка Firewall.
Что такое PVE (и не только) forum.netgate.com/topic/120102/proxmox-ceph-zfs-pfsense-%D0%B8-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5
-
@werter
Клево, как нибудь обязательно испытаю это удовольствие .Однако возвращаясь к вопросу, имею необходимость перенаправить порт с публичного IP через VPN туннель на локальную машину.
На клиенте сделал проброс: 10.0.8.2:8090->192.168.1.18090
На сервере делаю test port: 10.0.8.2 8090 Port test to host: 10.0.8.2 Port: 8090 successful. Т.е. сервер в интернете видит через VPN открытый порт на 192.168.1.1
Делаю на сервере проброс
Public IP:8090->10.0.8.2:8090, однако чрез Public IP соединения с веб-сервером нет. Что упускаю ? -
Зачем на клиенте проброс?
Схему с адресацией в студию.
-
@werter
Дано:
<Интернет> pf Сервер (x.x.x.x) <vpn tun10.0.8.x> pf Клиент <lan> Веб сервер(y.y.y.y)
Надо:
Доступ из Интернет к y.y.y.y:81 через x.x.x.x:81На клиенте проброс 10.0.8.2:81->y.y.y.y:81 работает
На сервере проброс х.х.х.x:81->10.0.8.2:81 не работает -
@Max69
Здр
Если я все верно понял, то
И не будет работать .
При такой реализации ответный пакет всегда будет уходить через шлюз по умолчанию pf Клиента.
Это особенность PF при работе через виртуальные интерфейсы (GRE,VTI,OpenVPN,...) Проблему можно решить , используя NAT Outbound на виртуальном интерфейсе PF сервера ,или изменив шлюз по умолчанию на PF клиенте.Те сейчас Ваша схема функционирует так
Клиент --> <Интернет> pf Сервер (x.x.x.x)--> <vpn tun10.0.8.x>--> pf Клиент --><lan> Веб сервер(y.y.y.y)
Обратно
Веб сервер(y.y.y.y)--> <lan> --> pf Клиент --> <Интернет> --> КлиентРезультат - соединения нет
-
@Konstanti
Ok. Однако почему-то пакет не ловится на клиенте вообще.
Если запускаю Packet Capture на клиенте, на сервере делаю Test Port 10.0.8.2, то все оk, Packet Capture показывает пакеты.
Если же http запрос через браузер то Packet Capture на клиенте вообще ничего не показывает ... т.е. похоже трафик не идет даже в одну сторону. Т.е. с публичного IP не заворачивает в VPN. В fw сервера открыл 81й порт на WAN, сделал редирект на 10.0.8.2, в одну то сторону должен пробрасывать по идее. -
@Max69
Начните отлавливать пакеты с самого начала цепочки- PF сервер WAN ( порт 81)
- PF сервер VPN интерфейс
и тд ....
-
@Konstanti
Попробовал, интересный эффект, трафик на клиенте ловится с других устройств, а если с самого хоста пф клиента, то трафика нет ... веб-гуи сервера есть, а на другом порту трафика нет ... Аааа, епсель-мопсель, на клиенте же fw, ну усе заработало,Мэни сэнкс ...)