Недавно мы установили новый АТС-сервер Aterisk на основе нашей предыдущей АТС (также Asterisk), который был установлен сторонней компанией.
Мы сохранили конфигурацию сервера такой же, все, что мы сделали, это добавили поддержку db в Asterisk, что не было реализовано предыдущей компанией. Он работает на Centos 6.4. 1-й порт Ethernet разделен на два vlan, второй vlan - это тот, по которому телефоны подключаются к Asterisk и также получают IP-адреса от dhcp.
На сервере Asterisk работает веб-портал, на котором можно просматривать данные, а также вносить различные изменения в агентов центра обработки вызовов. Это подается на первом влане.
Однако есть некоторые компьютеры, которые не находятся в правильном диапазоне IP-адресов для просмотра портала на первом vlan, но они находятся в том же диапазоне, что и телефоны. До тех пор, пока мы не перешли на нашу новую обновленную АТС, они могли просматривать портал на втором vlan, но это больше невозможно.
Я добавил правила прослушивания для IP-адресов обоих vlan в httpd.conf в формате:
слушайте xxx.xxx.xxx.xxx:80
слушай гггггггггггг: 80
но он все еще не работает.
Мне нужно добавить маршрут с помощью команды маршрута? или реализовать проброс портов? Я не очень разбираюсь в сетевых технологиях и сейчас более или менее учусь на лету.
Любая помощь будет оценена.
Результат cat / proc / sys / net / ipv4 / ip_forward - '0'
и результат ip ro sh:
192.168.244.0/24 dev em2 proto kernel scope link src 192.168.244.250
192.168.12.0/24 через 192.168.20.1 dev em1.20
192.57.4.0/22 dev em1.10 прото ссылка на область видимости ядра src 192.57.7.248
192.168.20.0/22 dev em1.20 ссылка на область области ядра прото src 192.168.20.2
169.254.0.0/16 dev em1 показатель ссылки области действия 1002
169.254.0.0/16 dev em2, показатель ссылки области действия 1003
169.254.0.0/16 dev em1.10 метрика ссылки области видимости 1016
169.254.0.0/16 dev em1.20 метрика ссылки области видимости 1017
В конце концов, это оказалось чем-то очень простым, как добавить шлюз по умолчанию на 2-й виртуальный интерфейс. К сожалению, при моем полном отсутствии знаний в области сетевых технологий для меня это было совсем не очевидно. Мой первоначальный вопрос был очень неясным, потому что я действительно не очень хорошо понимал, в чем проблема на самом деле или как работают vlan. Теперь у меня есть идея получше.
В любом случае спасибо за вашу помощь. Очень признателен.
Сначала вам нужно подтвердить основы:
Многие из этих ответов выглядят как вопросы, но я думаю, что это дает вам то, с чем можно поработать:
Можно ли с сервера asterisk пропинговать устройства, с которых вы хотите получить доступ к порталу? Если нет, поработайте над проблемой маршрутизации, чтобы исправить основное подключение. (Этот сервер существует в тех же подсетях, что и ваш старый, который работал, или вы развернули новое адресное пространство?)
Запустите netstat -tna4 и убедитесь, что сервер действительно прослушивает xxx.xxx.xxx.xxx:80 и yyy.yyy.yyy.yyy: 80, не так ли? Если нет, дважды проверьте конфигурацию httpd и перезапустите ее.
У вас есть активный брандмауэр на хосте? Если да, выключите его и посмотрите, работает ли это, если да, включите его снова и обновите свои правила.
VLAN - это конструкция канального уровня, которая виртуально имитирует физически отдельные сегменты сети. Я могу только предположить, что ваша сеть спроектирована правильно, и каждая виртуальная локальная сеть имеет свою подсеть для назначенных им хостов.
Похоже, ваша проблема, если это предположение верно, связана с маршрутизацией. Скорее всего, ваша УАТС не является также маршрутизатором, который маршрутизирует вашу телефонную VLAN (в которой таинственным образом находятся хосты, не являющиеся телефонными), но это может быть так. В любом случае выполните трассировку IP-адреса хоста, на котором размещен веб-портал, до которого у вас возникли проблемы с доступом, и посмотрите, где происходит сбой маршрутизации. Маршрутизатор необходим для перемещения данных по нескольким сетям, и по какой-либо причине один из маршрутизаторов между вашим хостом в телефонной сети и вашим веб-сервером не передает трафик. Также ищите ошибочные правила брандмауэра.
Обычно вы будете использовать какой-то протокол маршрутизации для управления этими маршрутами, и именно здесь вам следует начать искать проблемы. Однако, если по какой-то причине вы управляете маршрутами статически, вам может потребоваться добавить маршрут вручную.
Предположим, ваша УАТС также выступает в качестве шлюза по умолчанию для телефонной сети. В этом случае, вероятно, УАТС не имеет маршрута к сети сервера веб-портала. Однако может также случиться так, что сервер веб-портала не имеет обратного маршрута (запустите traceroute в обоих направлениях) или что шлюз не настроен для пересылки трафика.
Вам не нужно было бы перенаправлять порт, если бы вы не выполняли NAT между своими внутренними сетями, что было бы несколько необычно.