Обнаружено искажение файла apn crg обратитесь к вашему администратору сети
В этой статье речь пойдет о небольшой хитрости, к которой может прибегнуть некий виртуальный ОпСоС, чтобы обмануть своих абонентов в процессе предоставления услуг пакетной передачи данных. Центром нашего внимания будет процесс выбора и использования Access Point Name [APN].
Как мы помним из статьи GPRS изнутри. Часть 2, APN используется во время процедуры активации PDP Context'а и предназначена для определения услуги, запрашиваемой абонентом.
- Mobile internet
- Intranet VPN access
- MMS
- Wap
- LAN over GPRS [Push-To-Talk]
- SMS over GPRS*
APN также должна начинаться с алфавитно-цифровой последовательности символов и не чувствительна к регистру символов на стороне SGNS'а.
Функционально APN предназначена для определения IP адреса GGSN, который будет предоставлять сервис, запрошенный абонентом при активации PDP context'a.
Опционально APN состоит из двух частей – идентификатора сети (обязательная часть) и идентификатора оператора (не обязательная часть):
- идентификатор сети определяет IP адрес GGSN или нескольких GGSN и в первом приближении определят тип сети, к которой имеет выход GGSN;
- идентификатор оператора представляет собой параметры сети оператора, в которой расположен обслуживающий GGSN и состоит из MNC и MCC (например, mnc009.mcc255.gprs — некоторый оператор, Украина — который также называется GOI [GGSN Operator Identifier]), если же в названии APN отсутствуют эти данные, то для абонентов домашней сети оператора SGSN добавит так называемый Default APN Operator Identifier, прописанный в SGSN'е для домашней сети абонента, т.н. HPLMN*;
* — для абонента мобильной сети, есть понятие домашней сети [HPLMN], т.е. сети в которой будут действовать тарифы указанные в договоре по предоставлению услуг сети, но также есть понятие гостевой или роуминговой сети [VPLMN], в которой будут действовать тарифы согласно роумингового соглашения между операторами. При этом домашняя сеть для абонента будет только одна, а гостевых сетей может быть несколько.
- Получен от абонента при активации PDP Context'a (прописан в самой APN).
- Сгенерирован из IMSI абонента, если гостевой пользователь находящийся в роуминге и запрашивает доступ к своей домашней сети.
- Получен из параметра GOI [Default APN Operator Identifier], который прописан на SGSN для сети к которой принадлежит абонент
Для каждой PLMN, будь то Home PLMN или Visitor PLMN, большинство вендоров позволяет прописать на SGSN'е, т.н. Default APN Operator Identifier [DEFAPN], который автоматически подставляется в качестве Идентификатора Сети, т.е. фактически заменяя APN, запрошенную абонентом, но лишь в том случае если абонент ошибся в написании APN, либо указан не существующую в сети оператора APN. Основная задумка использования параметра DEFAPN направлена на уменьшение количества неудачных попыток активации PDP Context'a, в случае если абоненты ошиблись, т.е. указали неправильную APN в настройках подключения. Использование параметра DEFAPN является опциональным и никак не влияет на общую функциональность, т.е. оператор может и не приобретать лицензии на использовании этой функциональности. В дополнение к настройкам DEFAPN, обычно обязательной настройкой на SGSN'e является разрешение на перезапись запрошенной APN [Override of the requested APN], а также отдельные настройки замещения запрошенной APN для роуминговых абонентов [Override of roaming APN].
Но, что мешает оператору использовать дополнительную функциональность себе на пользу… :)
-
DEFAPN Activated, Override of Requested APN Permited
В этом случае, т.к. на стороне SGSN'а будет получен профиль абонента с HLR'a, определится первая APN в списке и активируется PDP Context по этой первой APN.
Вот здесь есть небольшой нюанс, т.к. абонент не имеет права как-то вмешиваться в изменение своего профиля, то есть вероятность, что первой в списке разрешенных ему APN «окажется» APN тарифы пользования которой окажутся не совсем маленькими.
З.Ы.: при написании статьи не пострадал ни один абонент сотовой связи, т.к. в нашей стране все операторы «честные» и пушистые :-)
Небольшой помощник:
APN — Access Point Name
GGSN — Gateway GPRS Support Node
GOI – GGSN Operator Identifier
GPRS — General Packet Radio Service
HLR — Home Location Register
HPLMN — Home PLMN
IMSI – International Mobile Subscriber Identity
LAC — Location Area Code
MCC — Mobile Country Code
MNC — Mobile Network Code
PDN — Packet Data Networks
PDP — Packet Data Protocol
PLMN — Public Land Mobile Network
RAC — Routing Area Code
RNC — Radio Network Controller
SGSN — Serving GPRS Support Node
VPLMN — Visitor PLMN
В связи с, появившейся после CVE-2013-3496, "Политикой ответственного разглашения" хочу заранее сообщить, что уязвимость давно исправлена и ей подвержены только определённые версии ViPNet Client, только под определённой версией ОС Windows. Но…, к сожалению, эти версии достаточно популярны и могут быть легко встречены в учреждениях, которые не озаботились об обновлении данного СЗИ.
Немного об уязвимости
В некоторых версиях линейки 3.1.x ViPNet Client из-за, допущенной разработчиками (случайно ли…?), ошибки, на локальной машине имеется возможность выполнения произвольного кода от имени самой системы, до полной загрузки ОС Windows.
Условия для эксплуатации уязвимости
Уязвимость имеет СЗИ, работающее на русской версии Windows 7 x64, что не такая уж и редкость. На выбранных англоязычных версиях Windows воспроизвести данную уязвимость не получилось.
Проверенные версии ViPNet Client, подверженные уязвимости: 3.1(2.6318), 3.1(3.7878), 3.1(4.8344).
Версии 3.1(5.xxxx) и выше уже исправлены.
В связи с тем, что определённые версии ViPNet Client довольно сложно найти, то не получилось проверить все начальные версии линейки 3.1.x (включая бывшую сертифицированную 3.1(1.xxxx)), но смею предположить (на основе повторяемости результатов), что они так же имеют, вышеуказанную ошибку.
Эксплуатируем уязвимость
В нашем случае была использована Windows 7 x64 RUS, с установленным и активированным ViPNet Client 3.1(4.8344). Данная версия ViPNet Client линейки 3.1.x одна из самых популярных и используется до сих пор.
После перезагрузки системы нас встречает окно авторизации ViPNet Client. И тут мы можем обнаружить, допущенную разработчиками, ошибку. Они оставили активным пункт меню «Первичная Инициализация».
Данный пункт используется для первоначальной активации ViPNet Client при помощи специально подготовленных dst-файлов. Вроде бы есть пункт и ничего страшного. Но! Разработчики оставили возможность выбора любого файла, а не только с расширением *.dst. Так же осталась возможность вызова контекстного меню по правой кнопке мыши.
Данная возможность даёт нам право запустить любой исполняемый файл и выполнить любое действие от имени учётной записи под которой работает меню авторизации ViPNet Client. А работает оно из под системной учётной записи.
Выводы
Как было показано выше, уязвимость не только реальна, но и легко реализуема любым пользователем локального ПК. Несмотря на то, что данные версии ViPNet Client уже морально устарели, они до сих пор в ходу и могут быть легко встречены на просторах нашей необъятной родины.
VipNet Client 3.2 Обнаружены несанкционированно измененные файлы
Версия хоть уже и под устарела но ей много кто пользуется и естественно сталкивается с проблемами. Для начала для чего эта программа - для связи с другим компьютером через интернет как по локальной сети и естественно с защитой данных. А раз обеспечивается защита данных - то и соответственно эту программу ставить надо с умом (не браузер же устанавливаем), где любая мелочь приводит к невозможности установки или настройке к подключению.
Бывает что вчера работали нормально, а сегодня ничего ни работает.
Первым делом надо вспомнить не устанавливали чего мы вчера? Бывают случаи установки других программ мешающим уже установленным - в этом случае может помочь вариант с де инсталляцией (удалением) недавно установленной программы, или откат системы на более ранее состояние где программа уже работала.
Это было отступление. Теперь рассмотрим попавшийся случай неполадки нам на руки с диагнозом ошибки "обнаружены несанкционированно измененные файлы". Пробороздив по данной ошибке в интернете (ПОДСКАЗКА КОТОРАЯ ПОМОГЛА НАМ ) выяснили, что с вероятностью в 90% был скачек света или не дождались завершения работы - выключили компьютер.
Удалось реанимировать просто достав архив или файлы первоначальной конфигурации в папку C:\Program Files\InfoTeCS\ViPNet Client\log\data\ses файла ses.cfg и в придачу всего содержимого в папке. Алеллуя заработало. Рекомендуем на будущее сделать копию программы для реанимации.
Но Этого оказалось мало.Ошибку " Обнаружены несанкционированно измененные файлы " исправили,но небыло связи с в випнет, пришлось попотеть, честно говоря прилично. Дело в том, что мы знали о жестком требовании в ВипНет соответствия компьютерного к текущему времени, естественно время сверялось местное и компьютера чуть ли не по секундам.
Служба поддержки рекомендовала переустановить программу (Деинсталировать, удалить папку с Program Files, перезагрузить, установить заново) - СТАНДАРТНАЯ ОТГОВОРКА АВСЬ ОТСТАНУТ.Тоже не наш случай. А на второй раз в службе попался более адекватный специалист - не поленился и проверил нас на связь и констатировал НЕВЕРНЫЙ ЧАСОВОЙ ПОЯС.
Очень часто к нам на страничку приходят с вопросом- vipnet не ставиться, ошибка
Решений Несколько. Во первых - при повторной установке папку випнета клиент с С:\Рrogram files (х86) надо удалять, можно почистить Ccleaner (ом) или другими утилитами комп от мусора, перезагрузка и повторная установка.
Еще может помочь это - в окне запуска VipNet Client Монитор выбираем "Настройка" и производим "Первичная инициализация", ждем продолжения автоматической установки. Если ничего не происходит, ищем в каталоге "Temp" файл вида abn_xxxx.dst. Если файл не обнаруживаем, то все содержимое удаляем.
Третий вариант тоже может помочь, но не во всех случаях,но пробовать стоить начинасть с него. Это откат системы (восстановление по точке сохранения системы) на тот момент когда система работала корректно.
Жизнь сетевого инженера была счастливой и беззаботной, пока в ней не появился сертифицированный криптошлюз. Согласитесь, разбираться с решениями, предназначенными для шифрования каналов передачи данных по ГОСТу, задача не из легких. Хорошо, если это известные и понятные продукты. Вспомним ту же «С-Терра» (об их «С-Терра Шлюз» мы уже писали). Но что делать с более экзотичными решениями на базе собственных протоколов шифрования, например, «Континент» (от «Кода Безопасности») или ViPNet Coordinator HW (от «Инфотекса»)? В этой статье я постараюсь облегчить погружение в мир ViPNet (про «Континент» тоже когда-нибудь поговорим) и рассказать, с какими проблемами столкнулся сам и как их решал.
Сразу оговорюсь, что мы поговорим о сертифицированной на сегодня ФСБ и ФСТЭК версии 4.2.1. В актуальных версиях 4.3.х появилось много интересного, например, DGD (Dead Gateway Detection) и измененный механизм кластеризации, обеспечивающий практически бесшовное переключение, но пока это будущее. Я не буду глубоко погружаться в недра конфигурационных команд и файлов, акцентировав внимание на ключевых командах и переменных, а подробное описание по этим «ключам» можно будет найти в документации.
Для начала разберемся, как это все работает. Итак, координатор ViPNet выполняет несколько функций. Во-первых, это криптошлюз (КШ), который позволяет реализовать как Site-to-site, так и RA VPN. Во-вторых, он является сервером-маршрутизатором конвертов, содержащих зашифрованные служебные данные (справочники и ключи) или данные клиентских приложений (файловый обмен, деловая почта). Кстати, именно в справочниках хранятся файлы, содержащие информацию об объектах сети ViPNet, в том числе об их именах, идентификаторах, адресах, связях. Координатор также является источником служебной информации для своих клиентов.
Помимо этого, он может туннелировать трафик от компьютеров сети, где не установлено ПО ViPNet. Кстати, специалисты, работающие с этим решением, часто называют открытые хосты не «туннелируемыми узлами», а просто «туннелями». Это может сбить с толку инженеров, которые привыкли к другим VPN-решениям, где под туннелем подразумевают PtP-соединение между КШ.
В качестве протокола шифрования в ViPNet используется IPlir, также разработанный «Инфотексом». Для инкапсуляции трафика применяются транспортные протоколы IP/241 (если трафик не покидает широковещательный домен), UDP/55777 и TCP/80 (при недоступности UDP).
В концепции построения защищенных соединений лежат так называемые «связи», которые бывают двух типов. Первые (на уровне узлов) нужны для построения защищенного соединения между узлами, вторые (на уровне пользователей) необходимы для работы клиентских приложений. Но есть исключение: узлы администратора сети ViPNet требуют обоих типов связи.
Что же может в этой схеме пойти не так? Как показывает практика, особенностей работы действительно много, и далеко не все проблемы можно решить интуитивно, без «помощи зала», а что-то нужно просто принять как данность.
(Un)split tunneling
Конверт не доставлен
Из этого следуют два вывода. Во-первых, между клиентами не обязательно должна проверяться связь (по нажатию на F5 и соответствующей иконки в меню) для доставки конвертов. Во-вторых, если связь межу ними все-таки проверяется, это не гарантирует доставку, так как проблема может быть в одном из межсерверных каналов.
Диагностировать прохождение конвертов межсерверным каналам или между клиентом и координатором в неочевидных случаях можно с помощью журнала и очереди конвертов, а также логов на координаторе. Также транспортный модуль ViPNet-клиента можно настроить на прямую доставку конвертов, доставку через общую папку или SMTP/POP3 (но это совсем экзотичный вариант). Погружаться в эти настройки мы не будем.
Неинформативные конфиги
Основным конфигурационным файлом HW является «iplir.conf», однако он не всегда отражает текущие параметры. Дело в том, что в момент загрузки драйвера IPlir происходит интерпретация этого конфига в соответствии с заложенной логикой, и не вся информация может быть загружена в драйвер (например, при наличии конфликтов IP-адресов). Инженеры, работавшие с программным координатором для Linux, наверняка знают о существовании команды «iplirdiag», которая отображает текущие настройки узлов, прогруженные в драйвер. В HW эта команда также присутствует в режиме «admin escape».
Немного остановимся на режиме «admin escape». По сути это выход из ViPNet shell в bash. Тут я солидарен с вендором, который рекомендует использовать данный режим только для диагностики и вносить какие-либо модификации только под присмотром техподдержки вендора. Это вам не обычный Debian, здесь любое неосторожное движение может вывести из строя ОС, защитные механизмы которой воспримут вашу «самодеятельность» как потенциальную угрозу. В связке с заблокированным по умолчанию BIOS это обрекает вас на негарантийный (читай «дорогой») ремонт.
Пересечения адресов
В нашей практике нередко встречается пересечение туннелируемых адресов за разными координаторами.
Именно для таких случаев в продуктах ViPNet существует виртуализация адресов. Виртуализация – это своеобразный NAT без контроля состояния соединения один к одному или диапазон в диапазон. По умолчанию на координаторах эта функция выключена, хотя потенциальные виртуальные адреса вы можете найти в iplir.conf в строке «tunnel» после «to» в секциях соседних координаторов. Для того, чтобы включить виртуализацию глобально для всего списка, необходимо в секции [visibility] изменить параметр «tunneldefault» на «virtual». Если же хотите включить для конкретного соседа, то необходимо в его секцию [id] добавить параметр «tunnelvisibility=virtual». Также стоит убедиться, что параметр tunnel_local_networks находится в значении «on». Для редактирования виртуальных адресов параметр tunnel_virt_assignment необходимо перевести в режим «manual». На противоположной стороне нужно выполнить аналогичные действия. За настройки туннелей также отвечают параметры «usetunnel» и «exclude_from_tunnels». Результат выполненной работы можно проверить с помощью утилиты «iplirdiag», о которой я говорил выше.
Конечно, виртуальные адреса приносят некоторые неудобства, поэтому администраторы инфраструктуры предпочитают минимизировать их использование. Например, при подключении организаций к информационным системам (ИС) некоторых госорганов этим организациям выдается DST-файл c фиксированным диапазоном туннелей из адресного плана ИС. Как мы видим, пожелания подключающегося при этом не учитываются. Как вписываться в этот пул, каждый решает для себя сам. Кто-то мигрирует рабочие станции на новую адресацию, а кто-то использует SNAT на пути от хостов к координатору. Не секрет, что некоторые администраторы применяют SNAT для обхода лицензионных ограничений младших платформ. Не беремся оценивать этичность такого «лайфхака», однако не стоит забывать, что производительность самих платформ все-таки имеет предел, и при перегрузке начнется деградация качества канала связи.
Нешифрованный трафик вместо зашифрованного
Новичкам бывает сложно понять природу 22 события – Non-encrypted IP Packet from network node – в журнале IP-пакетов. Оно означает, что координатор ждал с этого IP-адреса шифрованный трафик, а пришел нешифрованный. Чаще всего это происходит так:
- пользователь забыл залогиниться в ViPNet-клиент, или случайно разлогинился, но при этом пытается попасть на защищаемые ресурсы. В этом случае драйвер IPlir неактивен, а трафик, который по маршрутизации дошел до координатора, не был зашифрован на АРМ пользователя. По заголовкам пакета координатор видит, что все легально: адрес источника принадлежит АРМ с ViPNet-клиентом, адрес назначения – защищенному или туннелируемому узлу. Значит, и трафик должен приходить зашифрованным, но это не так, поэтому его надо заблокировать. Частным случаем данного сценария является ситуация, когда в сети поменялись адреса, и на том адресе, на котором был защищенный ViPNet-клиент, АРМ оказался туннелируемый. Но координатор все еще считает, что на этом адресе есть ViPNet-клиент, и поэтому нешифрованный трафик блокируется;
- с одной стороны взаимодействия отсутствуют связи. Например, вы связали два координатора, а справочники и ключи отправили только на один (или до второго они не дошли). В этом случае первый будет ждать зашифрованный трафик, но второй, так как не знает о существовании первого, будет присылать только незашифрованный;
- туннели прописываются вручную локально на КШ. Чтобы смоделировать такой сценарий, нужно два связанных координатора. На одном прописываем собственные туннели и туннели соседа, на втором «забываем» это сделать. При такой настройке трафик, исходящий от туннелей второго координатора к туннелям первого, шифроваться не будет, и на первом координаторе возникнет 22 событие.
В заключение
Я постарался рассмотреть самые злободневные проблемы, обозначить их корни и рассказать о решениях. Конечно, это далеко не все особенности ViPNet, поэтому рекомендую не стесняться – обращаться в поддержку и спрашивать совета в коммьюнити (на форуме вендора, в телеграмм-канале, в комментариях под этим постом). А если вам не хочется погружаться во все сложности работы с ViPNet или это слишком трудозатратно, то всегда можно отдать управление вашей ViPNet-сетью в руки профессионалов.
Автор: Игорь Виноходов, инженер 2-ой линии администрирования «Ростелеком-Солар»
Обработка прикладных протоколов (ALG)
На многих межсетевых экранах, включая ViPNet Coordinator, могут возникать проблемы с прохождением SIP через NAT. С учетом того, что виртуальные адреса – это внутренний NAT, проблема может возникать, даже когда в явном виде NAT не используется, а используются только виртуальные адреса. Координатор обладает модулем обработки прикладных протоколов (ALG), который должен эти проблемы решать, но не всегда это работает так, как хотелось бы. Не буду останавливаться на механизме работы ALG (на эту тему можно написать отдельную статью), принцип одинаков на всех МСЭ, изменяются лишь заголовки прикладного уровня. Для корректной работы протокола SIP через координатор необходимо знать следующее:
- при использовании NAT должен быть включен ALG;
- при использовании виртуальной адресации ALG должен быть включен на обоих узлах, участвующих во взаимодействии (координатор-координатор, координатор-клиент), даже если виртуальная видимость установлена только с одной стороны;
- при использовании реальной видимости и отсутствии NAT необходимо выключить ALG для того, чтобы он не вмешивался в работу SIP;
- ALG-линейки 3.х и 4.х несовместимы (строго говоря, в линейке 3.х вообще не было возможности как-то им управлять). В таком сценарии гарантировать корректную работу SIP вендор не может.
ViPNet ошибка
Корректировка даты и времени
Еще одна причина — некорректно установленное время в системе Windows. Обратите внимание на часовой пояс, он должен соответствовать поясу, в котором вы находитесь (но точно не скажу, не проверялось) , и отключите синхронизацию времени с сервером time windows.
Для этого, в окне Настроек даты и времени во вкладке Дата и время нажмите Изменить часовой пояс…
Выберите нужный часовой пояс и нажмите Ок.
При необходимости сверьте и откорректируйте время в данный момент.
Перейдите на вкладку Время по интернету, нажмите Изменить параметры.
Снимите флажок с пункта Синхронизировать с сервером времени в Интернете.
Сохраните изменения и перезапустите ViPNet Client. Возможно потребуется перезагрузить компьютер.
Есть еще один момент. При установке ViPNet Client на компьютер либо при повторной установке, сделайте резервную копию каталога Info TeCS — просто скопируйте содержимое папки куда-нибудь. И при возникновении ошибки в следующий раз, просто скопируйте с заменой содержимое папки ses в соответствующую папку с программой.
ViPNet войти в режим администратора или завершить работу
Существует полностью рабочий способ, как избавиться от этой проблемы. Однако он не всегда приемлем, так как подразумевает под собой полную переустановку ViPNet. А это занимает время. Данный способ хорошо изложен в статье ViPNet не работает, не запускается, нет доступа, ошибка.
Замена координатора
Рано или поздно встает вопрос о замене координатора на более производительный или временный вариант. Например, замена HW1000 на HW2000 или программного координатора – на ПАК и наоборот. Сложность заключается в том, что у каждого исполнения своя «роль» в ЦУС (Центре управления сетью). Как правильно изменить роль, не потеряв связность? Сначала в ЦУС меняем роль на новую, формируем справочники, но не отправляем(!) их. Затем в УКЦ выпускаем новый DST-файл и проводим инициализацию нового Координатора. После производим замену и, убедившись, что все взаимодействия работоспособны, отправляем справочники.
Кластеризация и сбой ноды
Горячий резерв – это must have для любой крупной площадки, поэтому на них всегда закупался кластер старших моделей (HW1000, HW2000, HW5000). Однако создание кластера из более компактных криптошлюзов (HW50 и HW100) было невозможно из-за лицензионной политики вендора. В итоге владельцам небольших площадок приходилось серьезно переплачивать и покупать HW1000 (ну, или никакой отказоустойчивости). В этом году вендор, наконец, сделал дополнительные лицензии и для младших моделей координаторов. Так что с выходом версий 4.2.x появилась возможность собирать в кластер и их.
При первичной настройке кластера можно серьезно сэкономить время, не настраивая интерфейсы в режиме мастера или командами CLI. Можно сразу вписывать необходимые адреса в конфигурационный файл кластера (failover config edit), только не забудьте указать маски. При запуске демона failover в кластерном режиме он сам назначит адреса на соответствующие интерфейсы. Многие при этом боятся останавливать демон, предполагая, что адреса сменяются на пассивные или адреса сингл-режима. Не волнуйтесь: на интерфейсах останутся те адреса, которые были на момент остановки демона.
В кластерном исполнении существует две распространенные проблемы: циклическая перезагрузка пассивной ноды и ее непереключение в активный режим. Для того чтобы понять суть этих явлений, разберемся в механизме работы кластера. Итак, активная нода считает пакеты на интерфейсе и в случае, если за отведенное время пакетов нет, отправляет пинг на testip. Если пинг проходит, то счетчик запускается заново, если не проходит, то регистрируется отказ интерфейса и активная нода уходит в перезагрузку. Пассивная нода при этом отправляет регулярные ARP-запросы на всех интерфейсах, описанных в failover.ini (конфигурационный файл кластера, где указаны адреса, которые принимает активная и пассивная ноды). Если ARP-запись хоть одного адреса пропадает, то пассивная нода переключается в активный режим.
Вернемся к кластерным проблемам. Начну с простого – неперключение в активный режим. В случае если активная нода отсутствует, но на пассивной в ARP-таблице (inet show mac-address-table) ее mac-адрес все еще присутствует, необходимо идти к администраторам коммутаторов (либо так настроен ARP-кэш, либо это какой-то сбой). С циклической перезагрузкой пассивной ноды немного сложнее. Происходит это из-за того, что пассивная не видит ARP-записи активной, переходит в активный режим и (внимание!) по HB-линку опрашивает соседа. Но сосед-то у нас в активном режиме и аптайм у него больше. В этот момент пассивная нода понимает, что что-то не так, раз возник конфликт состояний, и уходит в перезагрузку. Так продолжается до бесконечности. В случае возникновения данной проблемы необходимо проверить настройки IP-адресов в failover.ini и коммутацию. Если все настройки на координаторе верны, то пришло время подключить к вопросу сетевых инженеров.
Последствия перепрошивки
Невозможность работы GRE
Само собой, у каждого решения в IT есть свои ограничения по поддерживаемым сценариям использования, и ViPNet Coordinator не исключение. Достаточно назойливой проблемой является невозможность работы GRE (и протоколов, которые его используют) от нескольких источников к одному адресу назначения через SNAT. Возьмем, к примеру, систему банк-клиент, которая поднимает PPTP-туннель к публичному адресу банка. Проблема в том, что протокол GRE не использует порты, поэтому после прохождения трафика через NAT, socketpair такого трафика становится одинаковым (адрес назначения у нас одинаковый, протокол тоже, а трансляцию адреса источника мы только что произвели также в один адрес). Координатор реагирует на такое блокировкой трафика на фоне ошибки 104 – Connection already exists. Выглядит это так:
Поэтому, если вы используете множественные GRE-подключения, необходимо избегать применения NAT к этим подключениям. В крайнем случае выполнять трансляцию 1:1 (правда, при использовании публичных адресов это достаточно непрактичное решение).
Служебные порты и TCP-туннель
Однажды я столкнулся с приложением, которое ни в какую не хотело работать через координатор. Так я узнал, что у координатора есть служебные порты, по которым незашифрованный трафик блокируется без возможности какой-либо настройки. К ним относятся UDP/2046,2048,2050 (базовые службы ViPNet), TCP/2047,5100,10092 (для работы ViPNet Statewatcher) и TCP/5000-5003 (MFTP). Тут подвела функции TCP-туннеля. Не секрет, что провайдеры любят фильтровать высокие порты UDP, поэтому администраторы, стремясь улучшить доступность своих КШ, включают функцию TCP-туннеля. Ресурсы в зоне DMZ (по порту TCP-туннеля) при этом становятся недоступны. Это происходит из-за того, что порт TCP-туннеля также становится служебным, и никакие правила межсетевых экранов и NAT (Network Address Translation) на него уже не действуют. Затрудняет диагностику тот факт, что данный трафик не регистрируется в журнале IP-пакетов, как будто его вовсе нет.
Обнаружены несанкционированно измененные или проверенные с ошибкой файлы
Файл расположен в каталоге с установленным клиентом, в папке
1. Завершаем работу ViPNet (если он был запущен).
2. Открываем папку ses в каталоге с программой, видим несколько файлов.
3. Приготовьте резервную копию этой папки.
4. Все, что нужно сделать, это удалить все файлы из старой нерабочей папки ses (той, которая сейчас находится в папке с установленной программой), после чего скопировать содержимое из резерва.
5. Теперь можно запустить ViPNet Монитор, ввести пароль и… пользоваться!
Минус данного способа только в том, что этой самой резервной копии папки ses у вас скорее всего нет. Отсюда — только переустановка? Не всегда. Попробуйте скопировать аналогичную папку, например с другого рабочего места (с другого компьютера, где имеется ViPNet). Программа на том компьютере должна работать исправно. Если повезет, вы получите рабочий ViPNet без ошибок.
Не забываем про время
Тему блокировок продолжаем событием номер 4 – IP packet timeout. Тут все банально: это событие возникает при расхождении абсолютного (без учета часовых поясов) времени между узлами сети ViPNet (координаторы и ViPNet-клиенты). На координаторах HW максимальная разница составляет 7200 секунд и задается в параметре «timediff» конфигурационного файла IPlir. Я не рассматриваю в этой статье координаторы HW-KB, но стоит отметить, что в версии KB2 timediff по умолчанию 7 секунд, а в KB4 – 50 секунд, и событие там может генерироваться не 4, а 112, что, возможно, собьет с толку инженера, привыкшего к «обычным» HW.
Координатор недоступен
«У нас недоступен координатор/клиент/туннель. Что делать?» – самый частый вопрос, с которым приходят новички при настройке ViPNet. Единственно верное действие в такой ситуации – включать регистрацию всего трафика на координаторах и смотреть в журнал IP-пакетов, который является важнейшим инструментом траблшутинга всевозможных сетевых проблем. Этот способ спасает в 80% случаев. Работа с журналом IP-пакетов также помогает лучше усвоить механизмы работы узлов ViPNet-сети.
Читайте также: