2 LAN (VLAN) & SIP



  • Ещё один частный случай - есть две сети (физический LAN и VLAN внутри этого физического LAN) с IP 192.168.0.XXX/24 и 172.31.0.XXX/24, соответственно. В MyPBX (192.168.0.XXX) на Asterisk обе сети указаны как домашние, для клиентов выставлен NAT и "удалённая регистрация". Клиент из VLAN (172.31.0.XXX) подключается к АТС и может спокойно получать вызовы любой длительности, но исходящий вызов обрывается через 10-15 секунд.

    Вполне логично, что NAT чудит. Уже по всякому по измывался над правилами - ничего не добился. Сети друг друга видят, а вот SIP пакеты дропаются.

    Делал по этому ману https://www.youtube.com/watch?v=b2w1Ywt081o&t

    Тут читал, но много лишнего нагородили и вопрос у меня более узкоспецилизированный.



  • @ptz-m Доброго дня
    Помочь тут может Packet Capture на lan интерфейсе 192.168.0.0/24 . Очень интересно посмотреть sip трафик во время обрыва соединения .
    Я бы больше грешил на телефон или АТС, чем на PF ( но это мое личное субъективное поверхностное мнение, пока слишком мало вводных данных)
    Не совсем понятны слова про NAT , что имеется в виду.



  • @konstanti нечего тут смотреть классический косяк с NAT. Да и АТС, как раз, отлично пашет, а PfSense снова прикидывается дурачком.

    По дефолту IP-АТС - FXS/VoIP-номера - Номер - Редактирование - VoIP-настройки

    0_1552394101808_Voip.jpg

    Пока решил "костыльно" попробовать сделать Межсетевой экран - Сетевая Трансляция Адресов - Проброс Порта
    Интерфейс Wi-Fi
    Протокол TCP/UDP
    Назначение WAN adress
    Диапазон портов назначения 5060-5061
    Перенаправьте целевой IP 192.168.0.XXX
    для RTP-трафика аналогично

    0_1552394461358_SIP.jpg

    Работает, если в настройках клиента указывать не MyPBX (192.168.0.XXX), а белый IP на WAN. Что ОПЯТЬ указывает на то, что PfSense, не смотря на кажущуюся лёгкость в настройке, большой гемор. Виртуалка в виртуалке, эмулирующая виртуалку - вот реальная сущность всего этого. Или если обыденнее - брандмауэр виндовс усложнённый правилами маккафи под надзором антивируса касперского. 😵



  • @ptz-m У Вас неверно настроена АТС , по-моему . Галочка NAT используется в настройке номера при условии , что сам телефон физически находится за NAT . Тогда в SIP сообщении вместо 192.168.0.XXX будет подставлен Ваш внешний ip , на который телефон будет слать RTP трафик .

    https://voipnotes.ru/instrukcii/nastroika-ip-ats-yeastar-mypbx-soho/

    Вот классическое SIP сообщение без NATa от АТС для установки RTP соединения ( connection Address)
    0_1552398927074_a3819938-eb18-4cee-89b0-eb870cf1d52e-image.png

    т е сообщение для всех внутренних номеров , которые находятся внутри сети

    Попробуйте для номера,который находится в сети 172.31.0.xxx отключить галку NAT в настройках АТС и вернуть настройку в телефоне , что IP АТС - 192.168.0.XXX ( и в телефоне тоже проверьте настройки NAT - они тоже не должны быть активны)
    И посмотрите , что будет
    В этой схеме проброс портов вообще не нужен ( PF здесь должен выполнять только пересылку пакетов из одной сети в другую , больше ничего )



  • @PTZ-M
    Говорено-говорено про voip, nat и pfsense. По сотому разу - одно и тоже (
    Есть оф. мануал. Оч. хороший, кстати. Его бы в закладки добавить да почитывать иногда. Но дело "не барское".

    По фразе nat voip pfsense в гугле сразу:

    https://docs.netgate.com/pfsense/en/latest/nat/configuring-nat-for-a-voip-pbx.html
    https://docs.netgate.com/pfsense/en/latest/nat/configuring-nat-for-voip-phones.html

    Выполнено? На 146% уверен, что нет.

    Далее. Если ваша voip-коробка нах-ся за NAT, то обязательно в ее настройках указывать и внутреннюю сеть, к к-ой она и ее voip-клиенты принадлежат и внешний реальный IP (или dns\dyndns-имя).

    Что ОПЯТЬ указывает на то, что PfSense, не смотря на кажущуюся лёгкость в настройке, большой гемор. Виртуалка в виртуалке, эмулирующая виртуалку - вот реальная сущность всего этого. Или если обыденнее - брандмауэр виндовс усложнённый правилами маккафи под надзором антивируса касперского.

    Так смените его. Предлагаю iptables nftables в чистом виде. И никаких менюшечек. Осилите? Снова теже 146% на то, что нет.

    Ни копейки не заплатив за труд тем, кто работает над ним еще и требовать решать за вас ваши проблемы, к-ые лишь отчасти относятся к пф? Ау, капитализм на дворе. Просыпаемся. Платите, если не можете решить. Как сантехнику, повару, врачу, автослесарю. Лень оф. доки читать? Платите. Занянчили с нытьём.



  • @konstanti на вопрос "почему так?", всегда есть ответ "потому что!". Вы невнимательно прочитали первое сообщение в теме. Ваш вариант тут не рабочий, инфа 100% 😉



  • @werter да-да-да, мы все очень рады, что тут есть специалист по стандартным мануалам. К этому списку ОБЯЗАТЕЛЬНО надо добавить мануалы от Yealink и русские редакции от IPmatika.
    Вопрос в теме не в том, как настраивать Asterisk, а в том почему из VLAN работает проброс на WAN, а вот аналогичное на LAN - нет.
    По сути и такой вариант работы меня устраивает, тут вопрос чисто из исследовательского интереса. И да "Исходящий Сетевой Трансляции Адресов (NAT)" я не использую по политическим и религиозным мотивам, ибо в других железках он не требуется.

    P.S. и чем iptables-то не угодил? Нормально правила в консоли пишутся, и ведут себя вполне предсказуемо. nftables, да не юзал, нет у меня таких железок пока в парке.



  • @PTZ-M

    К этому списку ОБЯЗАТЕЛЬНО надо добавить мануалы от Yealink и русские редакции от IPmatika.

    Так это претензии не к пф.

    Вопрос в теме не в том, как настраивать Asterisk, а в том почему из VLAN работает проброс на WAN, а вот аналогичное на LAN - нет.

    Подскажу. Проблема в настраивающем.

    И да "Исходящий Сетевой Трансляции Адресов (NAT)" я не использую по политическим и религиозным мотивам, ибо в других железках он не требуется.

    Сказки.
    Любой voip-продукт за любым фаерволом и без vpn между voip-сервером и его клиентами требует настройки NAT. И от ваших "хотелок" это не зависит.
    Или выдавайте voip-серверу белую статику\динамику и суйте этот сервер в DMZ. Либо выставляйте его вообще без фаервола в мир.



  • @ptz-m Добрый день
    Хотел вернуться к Вашему изначальному вопросу
    Я верно понимаю , что Вы используете порт PF как транковый порт ? С vlan 1(физ сеть) + vlan (с каким-то номером) ?? И провод от PF идет дальше к коммутатору . Который уже в свою очередь разделяет трафик .
    Если это так , то , возможно , проблема именно в этом . Разработчики PF настоятельно не рекомендуют в транковый порт "засовывать" vlan1. Пакеты могут теряться



  • @konstanti я ссылку давал на видео-мануал, по которому делал. В данном случае имеется не транковый, а тегированный порт.

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



  • @ptz-m
    38-40 секунда Вашего видео ( там точно называется порт в коммутаторе , в который приходит кабель от PF )

    Я просто предполагаю , в чем может быть проблема , если Вы уверены , что все остальное настроено верно
    Просто в реальной ситуации без использования VLAN , у меня все работает отлично и RTP трафик ходит в обе стороны между сетями без проблем и без NATа на маршрутизаторе. NAT на PF используется только при звонках из-за пределов локальной сети.



  • @konstanti на видео написано (на входящем порту) - All LAN & VLANs Traffic.

    0_1552640109971_правила.jpg

    Для понимания правил. 2-ва верхних сгенерированы, через NAT.

    "между сетями" - имеете ввиду 2 сети на 1-ом интерфейсе LAN? Дык они и должны ходить без проблем, они ж на одном шлюзе висят. Или у Вас 2 сетевых карты под разные LAN?



  • @ptz-m
    Транковый порт (38-40 сек ) четко сказано .Транковый порт - это понятие было введено Cisco ( а так , это синонимы ) как и access-порт (нетегированные порты).
    Вот в моем понимании , при правильной настройке и следованию рекомендациям разработчиков PF , никакой NAT (проброс портов ) при маршртузации между внутренними сетями не нужен . ( а на чем висят эти сети разницы особой нет , vlan или отдельный физ порт)
    Верхние 2 правила сгенерированы PF автоматом при пробросе портов ( тут нет ничего удивительного )

    Повторюсь еще раз , удивительно то , что вы используете этот прием при соединении 2-х сетей .

    А при условии , что , похоже, NAT используется Вами не только для VOIP телефонии , то я бы лично рассмотрел вариант отказа от использования VLAN1 на транковом (тегированном) порту .
    Это выдержка из официальной документации PF

    Using the default VLAN1
    Because VLAN 1 is the default (“native”) VLAN, it may be used in unexpected ways by the switch. It is similar to using a default-allow policy on firewall rules instead of default deny and selecting what is needed. Using a different VLAN is always better, and ensure that only the ports are selected that must be on that VLAN, to better limit access. Switches will send internal protocols such as STP (Spanning Tree Protocol), VTP (VLAN Trunking Protocol), and CDP (Cisco Discover Protocol) untagged over the native VLAN, where the switches use these protocols. It is generally best to keep that internal traffic isolated from data traffic.

    If VLAN 1 must be used, take great care to assign every single port on every switch to a different VLAN except those that must be in VLAN 1, and do not create a management interface for the switch on VLAN 1. The native VLAN of the switch group should also be changed to a different, unused, VLAN. Some switches may not support any of these workarounds, and so it is typically easier to move data to a different VLAN instead of fussing with making VLAN 1 available. With VLAN ID 2 through 4094 to choose from, it is undoubtedly better to ignore VLAN 1 when designing a new VLAN scheme.

    Using a trunk port’s default VLAN
    When VLAN tagged traffic is sent over a trunk on the native VLAN, tags in the packets that match the native VLAN may be stripped by the switch to preserve compatibility with older networks. Worse yet, packets that are double tagged with the native VLAN and a different VLAN will only have the native VLAN tag removed when trunking in this way and when processed later, that traffic can end up on a different VLAN. This is also called “VLAN hopping”.

    As mentioned in the previous section, any untagged traffic on a trunk port will be assumed to be the native VLAN, which could also overlap with an assigned VLAN interface. Depending on how the switch handles such traffic and how it is seen by pfSense, using the interface directly could lead to two interfaces being on the same VLAN.



  • @werter said in 2 LAN (VLAN) & SIP:

    Любой voip-продукт за любым фаерволом и без vpn между voip-сервером и его клиентами требует настройки NAT.

    Но только PfSense оперирует понятием Manual Outbound NAT. Повторюсь - я не использую его, поскольку нафиг он мне не нужен. Всё железо уровня Home и SOHO прекрасно NAT-ируется самостоятельно, только укажи что и куда передать на входе. А объяснять коллегам находясь в отпуске (случись что), на кой ляд, я делал обратную дырку и как им теперь переконфигурировать под другое - мне вообще влом.



  • @ptz-m
    Удивительно )))
    Спорить не буду , но Вы используете NAT в автоматическом режиме , когда PF сам создает нужные правила , чтобы облегчить Вам жизнь. Но при этом утверждаете , что NAT не используете . Manual Outbound Nat служит для более гибкой настройки маршрутизатора . Куча примеров уже была приведена в соседних ветках . Не поленитесь , почитайте .

    Всё железо уровня Home и SOHO прекрасно NAT-ируется самостоятельно, только укажи что и куда передать на входе - это относится к Port Forwarding и никак не относится к NAT Outbound



  • @konstanti я возможно Вас запутал. Я ДЕЛАЛ по тому мануалу, но не говорил, что на том же оборудовании!

    0_1552641599647_vlan.jpg

    В ролике используют UniFI от Ubiquiti, я же реализовал такую задачу на HP 1820 и TpLink EAP-110.
    Как видно на картинке, я не использую транки, зачем? Мне сейчас достаточно выделения одного vlan в сеть! Вот когда я захочу гонять более 2-х vlan, тогда да, буду юзать транк.

    P.S. насчёт VLAN hopping, ну для SIP теоретически такое возможно... Если нет других идей, примем за основную версию.



  • @ptz-m не совсем понял Ваши слова. Если Вы не используете тэги, как комм и маршрутизатор различают трафик для разных vlan?

    Транковый порт — это канал точка-точка через который передается трафик всех VLANов. Траковый порт не принадлежит ни к одному VLANу, этот порт передает тегированный трафик. Транк может быть настроен между свичами или свичем и маршрутизатором.



  • @konstanti а что не понятного? Вы же сами кидали выдержки из оф. мана. Тэги никуда не деваются, все пакеты имеют №1 в обычной сети, но принудительно я ставлю №10, для гостевого wifi. Любой же порт и trunk, для конкретного vlan, может быть представлен в 3-х состояниях: Tagged, Untagged, Excluded. Поскольку мы не прогоняем толпу vlan до соседнего маршрутизатора, то и trunk не настраиваем.
    Честно говоря, вообще не знаю зачем мы тут обсуждаем устройство сетей...



  • Ок , убедили ))))


Log in to reply