Странный рутинг
-
Ситуация следующая:
pfSense стоит как рутер в среде VMware ESXi 5.0, за ней - куча виртуальных машин. Всё работает, хвала богам и создателям сего продукта, но проявилась странность следующего вида - необходимо обеспечить доступ к внутренним машинам клиентам, попадающим в сеть через VPN. Сервер, на котором работает OpenVPN находится в одной сети (VLAN) с сервером ESXi и, соответственно, внешним (WAN) интерфейсом pfSense но не совпадает с дефолтным рутером. Вроде ничего особенного, но!
Прописываю дополнительное правило рутинга, всё равно как - через веб интерфейс или в командной строке10.8.0.0/24 GWvpn - 192.168.21.214 WANполучаю для IP4
netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default corerouter-21 UGS 0 7476867 le0 10.8.0.0 basebsd UGS 0 246 le0 localhost link#6 UH 0 229 lo0 192.168.0.0 link#2 U 0 99388697 le1 virtbuff link#2 UHS 0 0 lo0 192.168.1.0 link#3 U 0 0 em0 192.168.1.1 link#3 UHS 0 0 lo0 192.168.21.0 link#1 U 0 49814580 le0 virtbuff link#1 UHS 0 0 lo0сеть 10.8.0.0/24 - это адреса внутри VPN, basebsd (192.168.21.214) - адрес интерфейса сервера с OpenVPN.
Результат: пакеты по этому правилу не идут, точнее какие-то туда попадают, но случайным образом. При попытке трассировки изнутри получаем трассу в дефолтный рутер -traceroute 10.8.0.2 traceroute to 10.8.0.2 (10.8.0.2), 64 hops max, 40 byte packets 1 corerouter-21 (192.168.21.100) 0.366 ms 0.225 ms 0.207 ms 2 gwb (172.16.7.181) 0.227 ms 0.202 ms 0.203 ms ...............соответвенно, там таких адресов нет.
Вопрос: что за …? На BSD, линуксе и даже винде (!) такие правила работают без проблем. -
Скорее всего вместо маршрутизации у вас срабатывает правило NAT
-
Нужна схема сети, ничего не понятно из ваших слов. С какой машины трассируете и кто для нее шлюз по умолчанию?
-
Мне в свою очередь не понятно что непонятно.
Трассирую изнутри pfSense к одному из хостов подключенных через VPN, чисто для демонстрации, т.к. сразу было очевидно что пакеты в VPN от pfSense не возвращаются. Шлюз по умолчанию == default, сабинтерфейс Cisco, 192.168.21.100Правило NAT на возвращаемые пакеты действовать не могут, точнее, должны действовать автоматически создаваемые "обратные" правила.
-
Тут телепатов нету, многие вещи, которые очевидны вам, могут быть не очевидны другим.
Если правильно понимаю, Cisco, pfSense и сервер OpenVPN смотрят своими интерфейсами в один свитч, причем pfSense смотрит в него интерфейсом WAN, а Cisco - LAN. Все находятся в одной подсети 192.168.21.0/?? и все влезают в маску.
Теперь озвучте версию pfSense и как вы добавляли маршрут через WEBGUI. Через коммандную строку лучше не делать т.к. это не чистая FreeBSD (pf например тут пропатчен по-своему) и могут быть подводные камни.
Если версия 2.0.1, то в System -> Routing нужно добывить Gateway с адресом сервера OpenVPN (192.168.21.214) и там же в Routes маршут через этот Gateway в сеть 10.8.0.0/24. -
Никакой телепатии не потребовалось, рассматриваем именно такую линейную схему. Все интерфейсы в сети 192.168.21.0/24. Маршрут к серверу OpenVPN в конечном итоге был прописан именно через System -> Routing (версия как раз 2.0.1), т.е. описан второй гейт (не дефолтный) и прописан маршрут: отправлять пакеты в сеть 10.8.0.0/24 через него. pfSense не перегружал, правило не работает. Пришлось поднять прокси в той же сети и пустить юзеров из VPN через него, но это паллиатив.
-
Я бы попросил вас неприличными словами тут не выражаться) По сути вопроса, маршруты, в том виде как вы их заводите, работают у тысяч и сотен тысяч пользователей pfSense. Единственное, что следует учитывать - это policy routing. Правилами Firewall -> Rules можно переназначить gateway и это переназначение будет иметь приоритет над таблицей маршрутизации.
Если у вас policy routing'а нет, то все должно работать. Все вы сделали правильно. -
Именно это я имел в виду. Такие правила работают на линуксе, FreeBSD и даже винде (извините за повтор), а здесь ядро просто игнорирует частное правило и сразу шлёт пакеты по дефолтному.
Ещё раз повторюсь: правилами Firewall -> Rules невозможно назначить маршрут куда-то налево, не введя понятие ещё одного гейта. Правильно? Именно так в конечном счёте и было проделано, был опрелён доп. гейт, в него прописан маршрут, отправлять туда пакеты назначенные в "левую" сеть. В результате в таблице рутинга появляется тоно такая же запись, как при определении маршрута командой route add (специально смотрел), и результат совершенно аналогичный. Т.е. либо всё же бага в ядре в 2.0.1, либо где-то сидит здоровенный побочный эффект.
То, что я "всё сделал правильно" - не утешает ;) -
Все это странно конечно, при том, что у меня например такие маршруты не первый год нормально работают. Одно скажу, ядро тут не при чем.
Пара мыслей. Маршруты нужно определять не через Firewall -> Rules, а через System -> Routing вкладка Routes. Тогда они будут действительны не только для машин за pfSense, но и для самого pfSense. Иначе трассировка с pfSense даст то, что вы и наблюдаете.
Отзывается ли сервер OpenVPN на пинг с pfSense? Если нет, то определенный вами gateway может расценен как недоступный. Проверьте это в Status -> Gateways. -
Пара мыслей. Маршруты нужно определять не через Firewall -> Rules, а через System -> Routing вкладка Routes.
Такие маршруты будут действительны только для самого pfSense. А станции в сети - по правилам FW Rules отдельно работают.
Я уже нарывался на такое, отписывался здесь в какой-то теме.
-
Вот это уже интересно, нужно попробовать.
Гейт/сервер vpn естественно пингуется и с базовой машины и из pfSense. -
Пара мыслей. Маршруты нужно определять не через Firewall -> Rules, а через System -> Routing вкладка Routes.
Такие маршруты будут действительны только для самого pfSense. А станции в сети - по правилам FW Rules отдельно работают.
Я уже нарывался на такое, отписывался здесь в какой-то теме.
Эти маршруты будут действительны для всех, если иное не определено в Firewall -> Rules. Иными словами, если в правиле Firewall -> Rules gateway выставлен как default, то будет действовать таблица маршрутизации pfSense, включая то, что пользователь прописал в System -> Routing [Routes].
Если вы хотите чтобы для определенного трафика действовала дефолтная таблица маршрутов, то правило для этого трафика в Firewall -> Rules нужно поставить выше правил, для которых определен альтернативный gateway и под которые подпадает этот трафикю -
Прекрасный пример ответа "вообще", не читая вопроса. :)
В общем, только после того как прописал особое правило рутинга во "Floating rules", появился контакт к хостам подключенным через OpenVPN сервер (выделенный).
-
Мда, чудны дела твои…
Поторопился малость. Из машин за гейтом контакт с машинами в OpenVPN есть, а вот если попытаться из VPN подключиться к машине за pfSense, облом. Т.е. пакеты от источника до получателя доходят, тот отвечает, естественно на адреса отправителя, но на сервер VPN эти пакеты не попадают... Загадка. Подключение от машин, находящихся просто в одной сети с выходным интерфейсом pfSense, проходит без сучка и задоринки. Будем смотреть теперь физический интерфейс :) -
У вас cisco - это то, куда все сходится, и для всех она default gateway. Вот на ней я бы на вашем месте и прописал маршрут в 10.8.0.0/24 через 192.168.21.214, а если NAT на pfSense отключен, то и в сети 192.168.0.0/24, 192.168.1.0/24 через WAN IP pfSense. Да, трафик между машинами за pfSense и клиентской сетью OpenVPN ходил бы через cisco, но если он небольшой, то и нормально. Зато весь ручной роутинг в одном месте.
Еще у pfSense есть такой момент, что пакеты от локальных процессов всегда уходят через default gateway. Я к тому, что трассировка с самого pfSense - не показатель, нужно трассировать 10.8.0.0/24 с машины за pfSense. То, что вы прописали floating rule исправило только этот момент. По сути это правило для общения машин за pfSense с клиентской сетью OpenVPN не нужно, достаточно маршрута в System -> Routing -> Routes -
теоретически оно может и так, а практически правило в System -> Routing -> Routes эффекта не даёт, что без "плавающего правила", что с ним. NAT естественно включен, с одной стороны у pfSense сеть .21.0/24, с другой - .0.0/24.
Чуть позже: таки пришлось прописать правило во внутреннем рутере, который виланами рулит и является гейтом для всех. Странновато реализован рутинг в pfSense, при том что это вообще-то рутер по призванию.
-
это вообще-то рутер по призванию.
Нее. По призванию он как раз кусок роутера. А полноценный роутер из него как раз хотят все сделать. Ожидаемо безуспешно.
-
NAT естественно включен, с одной стороны у pfSense сеть .21.0/24, с другой - .0.0/24.
Да? И в чем взаимосвязь?
Странновато реализован рутинг в pfSense, при том что это вообще-то рутер по призванию.
Не надо делать глобальных выводов из вашей частной неудачи. Не то превратитесь в "обиженного", такого как постом выше. Вы очевидно недавно на pfSense, решили сделать все по наитию, не прочитав документацию. Где-то накосячили в конфигурации и не видите этого. Схему сети выкладывать не хотите, скриншоты очевидно тоже. Ну, вал_и_те теперь все на pfSense, это действительно проще чем признать, что чего-то не понимаете.
Ваша ситуация (асимметричный роутинг) яйца выеденного не стоит и элементарно решается. Будет схема, будут скрины, будем говорить. -
2 rubic
Не то превратитесь в "обиженного", такого как постом выше.
Это не обида, это констатация очевидного факта. Концепцию нужно менять. Она себя исчерпала уже в m0n0. Из куска маршрутизатора полноценный роутер не получиться, очевидно-же.
-
Специально для великого Рубика приведу невообразимо сложную схему
Из подписей и предидущих постов вроде должно быть ясно что и куда должно бегать. Единственное пояснение - pfSense и Hosts array - внутри ESXi 5.
NAT естественно включен, с одной стороны у pfSense сеть .21.0/24, с другой - .0.0/24.
Да? И в чем взаимосвязь?
Может великий подскажет способ общения компов, находящихся в разных сетях, в обе стороны, не применяя NAT. Нобелевскую не дадут, но на что-то поменьше можно рассчитывать.