Сергей

У тебя может наружу торчать только один сервер с NGINX-ом, который в зависимости от порта или dns-имени будет перенаправлять запросы хоть на сотню разных внутренних серверов.
Пришел запрос на имя aaa.bbb.ccc - перенаправляем его на сервер xxx.yyy.zzz на порт 666.
Пришел запрос на имя ddd.eee.fff - перенаправляем его на тот же сервер xxx.yyy.zzz, но на порт 777.
Пришел запрос на имя kkk.lll.mmm - перенаправляем его на сервер rrr.sss.ttt.

Как вариант, можно попробовать:
1. Указать в статической маршрутизации не адреса, а конкретные туннели типа
ip route 192.168.0.1 255.255.255.255 Tunnel0
2. Проверить статику на всех устройствах. Скорее всего, на стороне филиала будет правильно использовать в статике 2 записи: 1-я запись для указания маршрута к провайдеру, а вторая запись - завернуть весь траффик на туннель: ip route 0.0.0.0 0.0.0.0 Tunnel0
3. Попробуйте keepalive 2 3 поставить на туннелях. У нас на некоторых кошках с некоторыми ИОСами была проблема, когда туннель не работал без постоянных keepalive-пакетов.
4. Включите дебаг и посмотрите, где что проходит, а где - нет

У меня есть один знакомый, который в лучшем смысле этого слова является компьютерным гиком, фанатом, маньяком своего дела. Пару лет назад задал я ему этот же вопрос. Он пытался мне что то объяснить, почему не получится, но прозвучало малоубедительно. Затарились мы с ним пивом, железом и начали тестировать. Интересовал только RAID-0, т.к. нужна была максимальная скорость, а не надежность. Коллега работает "ремонтником", поэтому у него выбор железа под руками оказался приличным. 3 разных контроллера и конфигурации от 2 до 4 дисков были опробованы нами. Скорость - практически такая же, как у одного из дисков. После моего безмерного удивления, собрали на обычных жестких дисках формата 2,5. При конфигурации из 2-х дисков на том же самом контроллере скорость возросла процентов до 190 от скорости одного диска. Три диска дали нам примерно 270 процентов скорости от скорости одного диска. 4 диска- 330-350% от скорости одного диска. Теоретическое обоснование сейчас не вспомню, т.к. не понял его и тогда. Но резюме следующее: сборка SSD в нулевой рейд скорости тебе не прибавит, только уменьшится надежность. Сборка SSD в рейды другого уровня намного быстрее угробит твои диски.

Вроде бы с помощью системы костылей и какой то матери вопрос частично решил.
1. В настройках действия кроме самого триггера указываю дополнительное условие "если состояние триггера PROBLEM".
2. В настройках действия задаю время этого шага длиной в сутки. В этом случае, еще одно сообщение придет через 24 часа. Если событие типа "принтеру требуется сервис" или "на ИБП требуется замена батареи", то одно сообщение в сутки - это приемлемо. На более динамичных участках такой вариант не подходит, пока копаю дальше.

Прошу прощения, не совсем понял: писать именно так или менять под мои данные? У меня есть текстовое поле с местом установки (ups.filial), адресом установки (ups.address), имя хоста (ups.hostname), модель ИБП (ups.model), серийный номер (ups.serial), дата изготовления (ups.factory) и т.д. А есть данные с триггерами и действиями, типа "отсуствует фаза" (ups.phase). Подскажете, как в моем случае в шаблоне письма оповещения будет выглядеть список:
место установки: ups.filial
адресо установки: ups.address
имя хоста: ups.hostname
модель ИБП: ups.model

Я столько вариантов перепробовал, ничего пока не подобрал для вывода этих элементов.

Они не "торчат" в интернет. Шлюз за PPPoE туннелем до провайдера, диапазон получаемых адресов динамический. Сами компы за НАТом на фряхе, акцесс-листы и все такое. Если не поднимать VPN до компьютера по разрешенным портам, то в сеть снаружи не пробиться.

Про самоподписанные сертификаты я не говорю, их вообще не проблема нагенерировать. Я говорю именно про официальные, выданные доверенным центром. Стоят дорого, но серверное брэндовое оборудование, сетевое оборудование cisco, лицензионное ПО - все дорого стоит.

Сами говорите, что уже год костыль убираете и не можете убрать. Я сразу хочу красиво сделать, чтобы в будущем, при любым расширениях, не иметь проблем.

В будущем, я планирую раширить канал, уйти от провайдера, вынести в корневой домен COMPANYNAME.ru зону DMZ с почтовиком, файловым сервером, веб-сервером и т.д., а компы за файрволом будут в office.COMPANYNAME.ru. ИМХО нормально. Или есть еще подводные камни?

Я слабо представляю, как различный софт обрабатывает эту запись, но за идею спасибо. Я в эту сторону даже и не думал. COMPANYNAME.loc решил не делать, мало ли что будет в будущем? Захотим сертификат в будущем сделать, а он, насколько я помню, на левые домены не делается. Решил из "рекомендованного" диапазона имен сделать, остановился на методе office.COMPANYNAME.ru. А какие подводные камни могут в этом случае вылезти? Я навскидку пока проблем не придумал, а то может быть стоит еще что то переделать, пока компы в домен не повгонял?

Почему очень часто обсуждение технических вопросов переходит в хамство? А еще находится "самый умный начальник", который решает, кто и что должен делать. Я задавал вопрос: "как НАИБОЛЕЕ ПРАВИЛЬНО решить этот вопрос", а не "каких костылей можно нагородить, чтобы сегодня от меня отстали". Я сам навскидку придумал штук 5 решений из разряда "костылей". Просто хотелось узнать мнение знающего и более опытного специалиста, а не решение тяп-ляпкина, работающее с оговорками или в определенных рамках. Некоторые предложенные решения я не считаю костылями, но они не вписались в мои планы по расширению структуры сети. Но все равно очень интересно почитать рекомендации коллег.

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

Пара комментариев. Типовое решение - это не всегда правильное решение. Правильное решение, это когда админ забыл о способе решения или пришел другой админ и в случае любых проблем, корень ее находится за несколько минут. В некоторых организациях видел костыли, которые до поры до времени работают, но про которые все забыли или не знают. Потом поиск проблемы и ее устранение займут лишние часы.

По фен-шую серверов должно быть 2. Сейчас его нет, т.к. не предусматривали выделение финансов на него в этом году. На второй деньги заложены в бюджете следующего года. Надеюсь, существующий проживет несколько месяцев до получения второго. Придет второй сервер - добавлю одну строчку в настройках DHCP и все будет работать нормально. Где вы проблему увидели?

Вы писали

Работ системного администратора и заключается в том что заниматься подобным. А ваша формулировка делает из этого трагедию. Если запись не нужна, то ее тупо сносят. Заводят новую. И всё снова стает на рельсы. И это не является "сбоем" как вы пишите. Решение с www как раз и есть общеупотребительным.

Для любого вменяемого админа важна максимальная автономность системы. Постоянно вручную отслеживать, не изменился ли адрес у веб-сервера. Виртуальный сервер будет мигрировать на другое железо при превышении порога нагрузки на железе, при выходе из строя комплектующих, а я буду отслеживать и переписывать записи в ДНС? Для этого есть ДНС сервера хостера, где хранится самая актуальная информация. А на них указывает как раз тот самый сервер 8.8.8.8, который у меня указан вторым или третьим по списку.

Почему меня не устроил костыль в виде записи www.companyname.ru в AD компании? Могу пояснить. На веб-сервере могут быть кнопки или ссылки, указывающие на имя "companyname.ru". Оператор, занимающийся обновлением информации на сайте, нажмет на такую ссылку и опять будет звонить мне, чтобы я разобрался, почему сайт не работает. Чтобы этого не случалось, надо отслеживать содержимое сайта. Завтра захотим поменять движок или прикрутить какой-нибудь плагин и опять отслеживать их исходники? Я могу забыть или сменить место работы, а в случае чего мозг вынесут мне. Зачем держать такой костыль, который будет работать только в определенных условиях и про который всегда надо помнить?

Прокси на 80-м порту контроллера тоже не рассматриваю. Серверов не так много, мало ли, захочу вывесить на цеб-страницу обновляемый из AD телефонный справочник или другую лабуду.

Спасибо всем. Я прочитал кучу информации по костылям, изобретаемым народом, но красивого решения проблемы не нашел. Решил потерять несколько часов работы, грохнул домен COMPANYNAME.ru и создал office.COMPANYNAME.ru. Пока далеко все не зашло, решил сразу сделать нормально, чтобы через годы не вылезли разные неисправимые проблемы.

Когда несколько контроллеров домена, то при пинге ИМЕНИ ДОМЕНА отвечает случайный контроллер. Если же он один в домене, то он и отзывается.