Подключение новых офисов, добавление резервных провайдеров и замена существующих не всегда проходят гладко, при этом не самые сложные операции отнимают много сил и времени. К примеру, смена провайдера может занять от нескольких минут (смена адреса на интерфейсе, изменение политик NAT и межсетевого экрана) до недель.

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

А ВКЛЮЧИТЬ ЗАБЫЛИ…

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

ОГРАНИЧЕНИЯ, О КОТОРЫХ МОЛЧАТ ПРОВАЙДЕРЫ

Раньше — еще два-три года назад — приходилось сталкиваться с ситуацией, когда провайдеры разрешали подключение только с определенного MAC-адреса. Это ограничение проявляется при замене старого устройства на новое: менялся MAC-адрес, вследствие чего доступ для нового устройства блокировался провайдером. Данная проблема решалась путем обращения к специалистам провайдера или подменой MAC-адреса на сетевом оборудовании, благо многие устройства это позволяют делать.

Другое ограничение — на доступ в Интернет по определенным протоколам и портам — более актуально. Нередко провайдеры разрешают использовать только стандартные протоколы, такие как HTTP, HTTPS, FTP и пр. Иногда разрешается всё, кроме некоторых протоколов — например, GRE, работающего поверх IP и используемого для построения незашифрованных туннелей, а также в рамках других протоколов, в частности PPTP.

Данная проблема проявляется и при настройке защищенных соединений VPN, например на базе протокола IPSec. Протокол IPSec (правильнее сказать, набор протоколов) предусматривает использование порта UDP 500 (для установления защищенного соединения), а также протоколов ESP или AH, работающих поверх протокола IP (для передачи защищенных данных). Поэтому, если в каком-либо месте сети провайдера протокол ESP блокируется, соединение VPN на базе протокола IPSec функционировать не сможет: само соединение будет установлено, а вот защищенные пакеты передаваться не будут.

При наличии трансляции адресов в транзитной точке, через которую проходит защищенный трафик, протоколы ESP или AH могут инкапсулироваться в протоколы UDP или TCP (по умолчанию UDP 4500), и тогда, если соответствующие порты закрыты где-либо далее по маршуруту прохождения трафика, возможны проблемы. По нашим наблюдениям, в Москве и Санкт-Петербурге в последнее время такое бывает нечасто, а вот в других уголках нашей Родины еще случается. Поэтому, если VPN настроен, но не работает, не стоит очень долго пытаться найти у себя ошибку в конфигурации. Весьма велик шанс, что проблема «не на нашей стороне».

ПРОБЛЕМЫ ПО ВИНЕ STP

Отдельно стоит сказать о ситуации, когда к Интернету подключается не маршрутизатор или межсетевой экран, а коммутатор, например Cisco Catalyst. Если на стороне у провайдера тоже установлен коммутатор Cisco, то с большой вероятностью данные передаваться не будут. Это обусловлено тем, что в этом случае порт коммутатора у провайдера обычно настраивается в режиме клиентского доступа (Аccess), так как предполагается, что к нему подключается оконечное оборудование. А поскольку для предотвращения образования петель все коммутаторы Cisco рассылают пакеты BPDU протокола STP, такой пакет, попав на порт с включенным режимом Access, вызывает его моментальную блокировку. Коммутатор определяет, что

к порту Access подключен другой коммутатор и расценивает такую ситуацию как недопустимую, поскольку для подобной связи должен использоваться режим Trunk. Решается эта проблема настройкой фильтрации пакетов BPDU на собственном оборудовании (провайдеру данные пакеты не отсылаем, полученные от провайдера игнорируем).

Надо сказать, что выход достаточно прост, но нам приходилось иметь дело с провайдером, который утверждал, что к их сети нельзя подключать коммутаторы Cisco, и в качестве аргументов приводил рассмотренную выше причину. Забавно, но факт!

A + B = ИНОГДА НЕ РАБОТАЕТ

Еще одним камнем преткновения является вопрос совместимости оборудования провайдера и подключаемых к нему устройств. Подобная несовместимость проявляется в самых разных проблемах, начиная от полной неработоспособности интерфейса сетевого оборудования и заканчивая частичным отказом сетевого соединения. Причем последняя ситуация — тема отдельного разговора, так как очень часто причину выявить трудно.

В более простых ситуациях помогает изменение настроек интерфейса: автоматического согласования скорости, дуплекного режима и т. д. Иногда нужно просто поменять соединительный шнур. В более сложных случаях необходимо проводить детальную диагностику, которую следует начинать с проверки общих параметров: количества пакетов, которые поступили и были отправлены через интерфейс, числа коллизий и ошибок на интерфейсе. Далее для диагностики выбирается, например, путь снизу вверх — от физического уровня семиуровневой модели OSI к уровню приложений, после чего начинается кропотливый анализ.

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

НЕДООЦЕНКА ВАЖНОСТИ ARP

Первый случай. Оборудование (маршрутизатор Cisco) было настроено и подключено, все работает корректно, но через некоторое время связь стала пропадать. Детальный анализ показал, что исходящие соединения функционируют стабильно (пакеты передаются в обе стороны). Проблема возникает только с входящими интернет-соединениями (например, при удаленном подключении к маршрутизатору). При этом прослеживается прямая зависимость входящих соединений от исходящих: если есть исходящие, то и входящие начинают функционировать корректно. Однако по прошествии некоторого времени подключиться удаленно или выполнить ping устройства из Интернета снова не удается.

Поскольку с физическим и канальным уровнем вроде бы все было в порядке, на следующем шаге выполнялась диагностика протокола ARP, который отвечает за привязку канального адреса (MAC-адреса) к сетевому (IP-адресу). После запуска трассировки пакетов и событий протокола ARP было установлено, что запросы ARP, поступающие от нашего оборудования, отрабатываются корректно. Иначе говоря, когда нашему маршрутизатору необходимо выяснить MAC-адрес маршрутизатора провайдера, он получает корректный ответ на свой запрос, после чего начинает передаваться трафик. Проблема же проявляется, когда маршрутизатор провайдера отсылает к нашему маршрутизатору запрос ARP, чтобы узнать его MAC-адрес.

Наше оборудование выявило следующую ошибку: IP-адрес в теле запроса ARP не совпадает с заданной подсетью на интерфейсе нашего оборудования, поскольку маршрутизатор провайдера подставлял совсем не тот IP-адрес, который мы от него ожидали. Это происходило из-за того, что в качестве основного адреса на оборудовании провайдера был настроен «серый» адрес (RFC 1918), а «белый» был вторичным. В результате оборудование Cisco считало такие запросы нелегитимными. Офис требовалось запустить в кратчайшие сроки, на выяснение ситуации с провайдером не было времени, и мы решили без согласования с ним указать «серый» адрес из сети провайдера в качестве вторичного — в результате на нашем оборудовании все заработало.

Второй случай. В одном из офисов требовалось заменить маршрутизатор Cisco ISR на межсетевой экран Cisco ASA. Последний был предварительно настроен и отправлен на место установки. После подключения оборудования удаленный доступ к нему оказался невозможен. На первый взгляд, все работало корректно. Межсетевой экран ASA правильно определял MAC-адрес маршрутизатора провайдера. Пакеты отправлялись с внешнего интерфейса устройства в Интернет. На удаленной стороне можно было видеть как эти пакеты, так и отправленные в ответ, при этом до ASA никакие пакеты не доходили. Этот факт фиксировался встроенными в МСЭ средствами перехвата пакетов. Таким образом, при возвращении на ASA пакеты где-то терялись.

После того как вновь был подключен маршрутизатор, трафик опять стал ходить корректно в обе стороны. Это означало, что проблема возникает где-то на стыке между провайдером и межсетевым экраном ASA. После обращения к провайдеру с детальным описанием ситуации удалось выяснить, что его оборудование «не видит» MAC-адрес межсетевого экрана ASA. Собранный демостенд доказал корректность работы ASA (роль провайдера играл маршрутизатор Cisco). По какой-то причине провайдерское устройство просто не воспринимало ответ ARP от Cisco ASA. В итоге провайдеру было предложено сделать статическую привязку в таблице ARP.

Данный случай показал несовместимость оборудования провайдера с межсетевым экраном Cisco ASA. К сожалению, название компании-производителя нам так и не сообщили.

MTU — ЭТО НЕ МАШИННО-ТРАКТОРНЫЙ ЮНИТ

Третья причина возникновения неполадок встречается достаточно часто. Речь идет о максимальном размере кадра (MTU), в частности при использовании технологий виртуальных частных сетей VPN. Проблема, связанная с MTU, проявляется следующим образом: по внешнему каналу доставляются только небольшие пакеты. Например, ping проходит, к удаленному устройству можно подключиться по Telnet через VPN, а подключение RDP не функционирует (RDP использует пакеты больших размеров).

Для того чтобы понять суть проблемы, попробуем более детально разобраться со связью между технологией VPN и MTU. При инкапсуляции пакетов в VPN (IPSec, GRE и пр.) размер пакета увеличивается из-за добавления к нему еще одного или нескольких заголовков. Например, в случае GRE пакет становится длиннее на 24 байта, а при использовании протокола IPSec могут добавиться до 52 байтов. Казалось бы, проблем быть не может, ведь пакеты, размер которых превосходит максимально допустимый, должны фрагментироваться, то есть разбиваться на несколько мелких. Однако необходимо учитывать, что фрагментация пакетов всегда связана с увеличением нагрузки на сетевые устройства, поэтому ее пытаются избегать.

К примеру, компьютер под управлением операционной системы Microsoft Windows при установлении соединения для динамического согласования максимального размера MTU использует механизм Path Maximum Transmission Unit Discovery (PMTUD). Данный механизм устанавливает бит df (don’t fragment) для всех пакетов — такой пакет нельзя фрагментировать. Поэтому сетевое оборудование, получив пакет, который имеет размер больше MTU, используемого на интерфейсе, отсылает в обратную сторону сообщение ICMP, информируя компьютер о необходимости уменьшения максимального размера пакета при передаче в этом направлении. После получения такого сообщения компьютер отправляет все пакеты уже с меньшим MTU, что исключает их фрагментацию, и тем самым оптимизируется их передача по сети.

В случае использования технологии VPN описанная схема определения MTU хотя и усложняется, но в целом остается той же. Как минимум добавляется еще одно звено — устройство VPN, осуществляющее шифрование пакетов. В этом случае сообщение ICMP изначально адресуется не оконечному оборудованию (компьютеру), а этому устройству, с адреса которого поступают зашифрованные пакеты. Проблемы начинаются, когда сообщение ICMP, информирующее о необходимости уменьшения MTU, по каким-то причинам не доходит до целевого оборудования — например, блокируется провайдером. В этом случае оборудование, не получив сообщения ICMP, считает, что текущий размер MTU верен и продолжает посылать пакеты недопустимого размера, которые в конечном итоге сбрасываются.

Для решения данной проблемы можно изменить значение MTU на исходящем интерфейсе сетевого оборудования (например, задать его равным 1440), а также варьировать параметр TCP Maximum Segment Size (MSS). Данный параметр содержится в заголовке пакета SYN протокола TCP и позволяет оконечным устройствам при открытии сеанса TCP согласовывать максимальный размер сегмента TCP. Надо отметить, что оборудование Cisco «умеет» менять этот параметр для проходящего через него транзитного трафика.

В первом случае (изменение размера MTU на интерфейсе) ваше пограничное сетевое устройство, получив «раздутый пакет», сбросит его и отправит в обратную сторону соответствующее сообщение. Вероятность того, что это сообщение дойдет до отправителя существенно выше, так как оно передается по внутренней сети. Во втором случае размер пакета будет сразу согласован при установлении TCP-соединения. Но второй механизм влияет только на TCP-пакеты.

Еще один вариант — полное сбрасывание бита df, но такой подход вызывает увеличение нагрузки на устройства, так как ведет к фрагментации пакетов.

НЕВИДИМЫЕ БОРЦЫ С УГРОЗАМИ

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

Необходимо обращать внимание на все отклонения от стандартной работы сети, которые могут теоретически провоцировать отказы. Для этого в реальном времени следует выполнять мониторинг как загруженности каналов связи, так и качественного состава трафика, для чего используются протоколы SNMP, Netflow и пр. Иногда какой-нибудь сервер работает некорректно и периодически полностью забивает канал связи. Эту ситуацию легко отследить с помощью мониторинга. В рассматриваемом случае все было не столь очевидно, так как четкой связи между сбоями и всплесками трафика не прослеживалось.

Проблема решилась благодаря внимательности заказчика. Он заметил, что недоступность канала напрямую связана с обновлением WSUS. После запуска процесса обновления серверов трафик по каналу переставал ходить. После проведенного анализа провайдеру было написано письмо с вопросом о возможном наличии у него какой-либо системы предотвращения вторжений (Intrusion Prevention System, IPS) или ее аналога, способного блокировать трафик. Как оказалось, такая система действительно имелась.

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

ИТОГ

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

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

Сергей Калашников — технический директор компании «Компьютерные бизнес-системы» (CBS), CCIE. С ним можно связаться по адресу: ksg@cbs.ru.