The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Помогите разобраться с pf, !*! resus, 30-Янв-21, 00:44  [смотреть все]
Доброе время суток всем!

Помогите разобраться с pf: произошло слияние двух географически разнесённых контор. У каждой была (и осталась своя сетка), был настроен канал обмена данными через openvpn. В каждом филиале (теперь) был свой админ. Недавно админ смежного филиала уволился и мне поручили следить за вторым филиалом, пока туда не возьмут нового человека. На той стороне, к счастью, тоже стоит FreeBSD. Я привык к ipfw, а с той стороны - pf. Ещё одна проблема в том, что основные рабочие сетки у нас одинаковые - 192.168.0.0/24.

Пытаюсь настроить мониторилку состояния серверов/шлюзов той сети. Адреса openvpn: 192.168.5.1 - сервер с той стороны, 192.168.5.22 - мой; 192.168.0.8 - один из объектов мониторинга на той стороне (напоминаю, что и у меня сетка 192.168.0.0/24)

На той стороне добавляю в pf.ctl
rdr log on ovpn_if inet proto tcp from 192.168.5.22 to 192.168.10.8 ->192.168.0.8
pass log quick proto udp from 192.168.5.22 to 192.168.0.8
pass log quick proto udp from 192.168.5.22 to 192.168.10.8

ping на 192.168.10.8 отбивается с ответом from 192.168.5.1: Destination Host Unreachable
В pflog ничего не попадает. :( man pf курю уже по третьему кругу, но пока не понимаю, где я не прав.
pf.ctl:

int_if="re0"
int_ip="192.168.0.1"
vid_ip="10.0.0.112"
ext_if="fxp0"
ovpn_if="tun0"

srv="{192.168.0.2, 192.168.0.29, 192.168.0.155}"

1c_otch="{31.13.60.76, 89.188.115.186, 91.239.5.33}"
1c_port="{110, 465}"
mail_port="{25, 110, 465, 993, 995}"
mail_nic_ru="{194.85.88.224/27, 91.189.116.32/28}"
smtp_mail_ru="{94.100.180.160, 217.69.139.160}"

localnet="{192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 192.168.5.0/24, 192.168.33.0/24, 192.168.7.242/32, 192.168.7.239/32}"
client_out="{ssh, domain, http, https, 8000, 3128, 8080, ntp}"
udp_services="{domain, ntp, 32769}"
icmp_types="{echoreq, unreach}"

table <1c_ruser> persist file "/etc/1c_ruser"

set skip on lo0
set block-policy drop
set ruleset-optimization basic
set loginterface re0
scrub in all

### mail nic.ru ###
nat on $int_if from $localnet to $mail_nic_ru port $mail_port ->$int_ip
nat on $int_if from 192.168.0.30 to $smtp_mail_ru port {25,465} ->$int_ip

# RDP 1C
nat on $ovpn_if from <1c_ruser> to 192.168.5.22 ->192.168.5.1
# 2 old buserver
nat on $ovpn_if from {192.168.0.2, 192.168.0.46, 192.168.0.65} to 192.168.4.10 ->192.168.5.1
nat on $ovpn_if from {192.168.0.2, 192.168.0.46, 192.168.0.65} to 192.168.4.106 ->192.168.5.1
nat on $ovpn_if from {192.168.0.2, 192.168.0.46, 192.168.0.65} to 192.168.4.165 ->192.168.5.1

###
nat on $int_if from 192.168.2.0/24 to any port 5190 ->$int_ip
### for security scan
nat on vlan3 from 192.168.0.29 to 192.168.2.0/24 -> 192.168.2.154
###

rdr log on ovpn_if inet proto tcp from 192.168.5.22 to 192.168.10.8 ->192.168.0.8

block log all
block quick proto ipv6
block quick proto icmp6 all

pass quick from $localnet to any
pass on $int_if inet proto udp from any to any port $udp_services
pass on $int_if inet proto tcp from any to 192.168.0.1 port 47365
pass in quick on $int_if inet proto tcp from any port 8000 to 192.168.0.1
pass in on $int_if inet proto tcp from any to any port 22
pass in on $int_if inet from 192.168.7.0/24 to 192.168.0.1
pass out quick on $ext_if from $ext_if to any
pass from 192.168.0.164 to any

pass quick proto tcp from 192.168.0.46 to 192.168.4.10 port 3389

pass log quick proto udp from 192.168.5.22 to 192.168.0.8
pass log quick proto udp from 192.168.5.22 to 192.168.10.8

pass quick proto udp from any to 192.168.0.1 port {22, 53, 67}

### Agent ###
pass quick proto tcp from 192.168.15.0/28 to any port {22,53,80,443,4244,5242,8000,8080,8081,8082,8083,8084,8085,8086,8087,8088,8089,8090,8291}
pass quick proto udp from 192.168.15.0/28 to any port {53,123,5243,7987,7985,9785}
pass quick proto tcp from 192.168.15.0/28 to 81.24.214.144 port 10058
pass quick proto icmp from any to 192.168.15.0/28
pass quick proto icmp from 192.168.15.0/28 to any
block in on $ext_if  inet proto icmp all

pass quick proto tcp from 192.168.50.0/30 to any port {22,53,80,443,4244,5242,8000,8080,8081,8082,8083,8084,8085,8086,8087,8088,8089,8090}
pass quick proto udp from 192.168.50.0/30 to any port {53,123,5243,7987,7985,9785}
pass quick proto icmp from any to 192.168.50.0/30
pass quick proto icmp from 192.168.50.0/30 to any
block in on $ext_if  inet proto icmp all

  • Помогите разобраться с pf, !*! ACCA, 20:06 , 02-Фев-21 (1) +1
    Ничего хорошего из этого не получится. У вас не "одинаковые сетки 192.168.0.0/24", у вас одна сетка 192.168.0.0/24. См. RFC7020.

    Пока не уйдёте от неё, так и придётся заниматься глупостями с каждым адресом хоста.

    Дешёвое решение - поставь tinc и сделай VPN на 2 уровне OSI. "Корпоративное" решение - MPLS и гонять Ethernet через него.

    • Помогите разобраться с pf, !*! resus, 23:13 , 02-Фев-21 (2) –1
      > Ничего хорошего из этого не получится. У вас не "одинаковые сетки 192.168.0.0/24",
      > у вас одна сетка 192.168.0.0/24. См. RFC7020.

      Не согласен. (С) За исключением некоторых общих серверов типа 1С, базы законов, корпоративной почты, сетки никак не пересекаются. Хотя основное адресное простраство одинаковое.

      > Пока не уйдёте от неё, так и придётся заниматься глупостями с каждым
      > адресом хоста.

      А мне их надо-то мониторить - штук 5 всего. И как завещал товарищ Сухов - "Лучше, конечно, помучиться..." Мало ли - вдруг в жизни на какого-нибудь зверя типа openBSD нарвусь...

      > Дешёвое решение - поставь tinc и сделай VPN на 2 уровне OSI.

      А вот тут снова не согласен. Не знаю точно, что такое tinc (почитаю), но раз речь пошла про 2-й уровень OSI, то, полагаю, это похоже на бридж или eoip у микротика. У меня размер сетки под 150 человек. С той стороны, возможно, меньше. Плюс - и у меня есть дополнительные сетки, и там свой зоопарк подсетей, с которым разбираться пока нет желания. Ловить конфликты и давить "левые" пакеты, мне кажется, - большее зло.

      > "Корпоративное" решение - MPLS и гонять Ethernet через него.

      MPLS, как мне кажется, это провайдер уровня *телекома. Наш провайдер подобную услугу не даёт. Строить EthernetVPN (или закрытый канал) силами двух провайдеров - мою зарплату пустят на оплату подобной услуги. :( Мне-то оно надо на месяц, думаю, пока новый человек там не появится. А уж он-то пусть свой сегмент потом перекраивает как захочет.


      Но, спасибо за вариант решения.

      • Помогите разобраться с pf, !*! ACCA, 01:04 , 03-Фев-21 (3)
        >> Ничего хорошего из этого не получится. У вас не "одинаковые сетки 192.168.0.0/24",
        >> у вас одна сетка 192.168.0.0/24. См. RFC7020.
        > Не согласен. (С) За исключением некоторых общих серверов типа 1С, базы законов,
        > корпоративной почты, сетки никак не пересекаются. Хотя основное адресное простраство одинаковое.

        Я сейчас буду ругаться на твой ЕГЭ.

        Перечитай RFC7020 - не бывает "одинакового" пространства, в Internet только одно адресное пространство и все IP адреса обязаны быть уникальными. Пока у тебя сети были изолированы, у тебя было два Internet, не знающие друг о друге.

        Теперь ты их объединил в один. И в этом одном Internet ты обязан иметь уникальные unicast адреса и сети. Все протоколы расчитаны именно на уникальность адресов unicast.


        > А мне их надо-то мониторить - штук 5 всего. И как завещал
        > товарищ Сухов - "Лучше, конечно, помучиться..." Мало ли - вдруг в

        Для 5 штук заряди маршруты /32 на хостах и на маршрутизаторах. Даже с приоритетами не придётся возиться. pf не нужен.

        • Помогите разобраться с pf, !*! fantom, 11:42 , 03-Фев-21 (4)
          >[оверквотинг удален]
          > пространство и все IP адреса обязаны быть уникальными. Пока у тебя
          > сети были изолированы, у тебя было два Internet, не знающие друг
          > о друге.
          > Теперь ты их объединил в один. И в этом одном Internet ты
          > обязан иметь уникальные unicast адреса и сети. Все протоколы расчитаны именно
          > на уникальность адресов unicast.
          >> А мне их надо-то мониторить - штук 5 всего. И как завещал
          >> товарищ Сухов - "Лучше, конечно, помучиться..." Мало ли - вдруг в
          > Для 5 штук заряди маршруты /32 на хостах и на маршрутизаторах. Даже
          > с приоритетами не придётся возиться. pf не нужен.

          Далеко не лучшее решение.
          Хотя в поставленной задаче любое решение без изменения адресного пространства ИМХО костыльный костыль из костылей слепленный, соплями клееный.

          Если вам всего-то мониторить доступность серверов на другой площадке -- на втором шлюзе проброс портов сваяйте на нужные сервера и мониторьте на здоровье не по ICMP, а по tcp.
          Тем же пробросом вопрос управления решается.

          Ну или поизучать вашу мониторилку.
          Например у zabbix есть такая фишка как proxy. И вот через него вопрос мониторинга в описанной ситуации решаем гораздо проще.


          • Помогите разобраться с pf, !*! resus, 13:56 , 04-Фев-21 (5)
            > не по ICMP, а по tcp.
            > Тем же пробросом вопрос управления решается.
            > Ну или поизучать вашу мониторилку.
            > Например у zabbix есть такая фишка как proxy. И вот через него
            > вопрос мониторинга в описанной ситуации решаем гораздо проще.

            У меня mrtg опрашивает состояние/нагрузку по snmp.

            > Если вам всего-то мониторить доступность серверов на другой площадке -- на втором
            > шлюзе проброс портов сваяйте на нужные сервера и мониторьте на здоровье

            Вот я и пытаюсь. Но с pf до этих пор дел не имел, а сейчас в простых действиях разобрался, а вот проброс портов не получился, как задумывался. :(

            Мне нужен, например, хост 192.169.0.8 дальнего от меня филиала.
            Я добавляю в pf.conf, как я указывал ранее, строки (протоколы потом добавлю):

            rdr log on ovpn_if inet from 192.168.5.22 to 192.168.10.8 -> 192.168.0.8
            pass log quick inet from 192.168.5.22 to 192.168.10.8 flags S/SA keep state

            Т.е., по моей задумке, pf должен перехватить пакеты от 192.168.5.22 к 192.168.10.8 и перенаправить их на 192.168.0.8. В туннеле я входящие пакеты вижу, а на выходе в сторону 192.168.0.8 ничего нет. :(

        • Помогите разобраться с pf, !*! resus, 22:17 , 21-Фев-21 (6)
          >>> Ничего хорошего из этого не получится. У вас не "одинаковые сетки 192.168.0.0/24",
          >>> у вас одна сетка 192.168.0.0/24. См. RFC7020.
          >> Не согласен. (С) За исключением некоторых общих серверов типа 1С, базы законов,
          >> корпоративной почты, сетки никак не пересекаются. Хотя основное адресное простраство одинаковое.
          > Я сейчас буду ругаться на твой ЕГЭ.

          А смысл?

          > Перечитай RFC7020 - не бывает "одинакового" пространства, в Internet только одно адресное
          > пространство и все IP адреса обязаны быть уникальными. Пока у тебя

          Ты упускаешь слово "public"! В публичном адресном пространстве - да. Здесь же мы имеем дело с внутренними сетями. Все известные мне RFC требуют уникальности адреса в пределах одного физического сегмента ethernet.

          > сети были изолированы, у тебя было два Internet, не знающие друг о друге.

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

          > Теперь ты их объединил в один. И в этом одном Internet ты обязан иметь уникальные
          > unicast адреса и сети. Все протоколы расчитаны именно на уникальность адресов unicast.

          Ну как "объединил"? Построил туннель всего лишь. Причем, у меня нет проблем с обращением к паре условно "моих" серверов клиентов из обоих сегментов. NAT спасает ситуацию. Мне совсем не нужна полноценно-одноранговая сеть.

          >> А мне их надо-то мониторить - штук 5 всего. И как завещал
          >> товарищ Сухов - "Лучше, конечно, помучиться..." Мало ли - вдруг в
          > Для 5 штук заряди маршруты /32 на хостах и на маршрутизаторах. Даже
          > с приоритетами не придётся возиться. pf не нужен.

          "В России нет дорог - есть направления" (С). В современном интернете очень мало Единственно Верных Решений. Как реализовать свою хотелочку на ipfw я зна. Теперь я хочу разобраться с pf. Товарищи в интернете пишут, что pf - "мощный инструмент, позволяющий тонко настраивать"... и "ничуть не уступающий остальным аналогичным средствам". Значит, на нём можно сделать то же, что и на ipfw.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру