Подключение к интернет-провайдеру : проблемы и решения

• 13.06.2013
• 4605

Автор
Сергей Калашников, CCIE
Технический директор

Статья опубликована в июньском номере «Журнал сетевых решений/LAN».

• Причины ограничения доступа в Интернет: подмена MAC адресов, протоколы и порты, VPN соединения
• Подключение коммутатора к интернету и протокол STP
• Не забудьте оплатить интернет
• Совместимость оборудования
• Для чего используется протокол ARP? Назначение
• Максимальный размер кадра MTU
• Мониторинг загрузки каналов связи

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

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

Причины ограничения доступа в Интернет: подмена MAC адресов, протоколы и порты, VPN соединения

Одним из самых распространённых случаев, с которым приходилось раньше сталкиваться (2-3 года назад) было ограничение, накладываемое на 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, то с большой вероятностью связи не будет. Это обусловлено тем, что обычно порт в этом случае настраивается в режиме access (предполагает подключение оконечного оборудования). А так как все коммутаторы Cisco для предотвращения образования петель рассылают пакеты BPDU протокола STP, такой пакет попав на порт в режиме access моментально его блокирует. Коммутатор считает, что к порту access подключен другой коммутатор (что собственно на самом деле и происходит), и расценивает такую ситуацию не допустимой, так как для связи между коммутаторами должен использоваться режим trunk. Решается эта проблема настройкой фильтрации пактов BPDU (провайдеру не отсылаем, от провайдера данные пакеты игнорируем). Надо сказать, что ситуация и выход из неё достаточно просты, но на нашей практике был провайдер, который по этой причине утверждал, что к их сети нельзя подключать коммутаторы Cisco. Забавно, но факт!

Не забудьте оплатить интернет

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

Совместимость оборудования

Ещё одним камнем преткновения является вопрос совместимости оборудования провайдера и оборудования, которое мы к нему подключаем. Здесь можно привести множество проявлений подобной несовместимости, начиная с той ситуации, когда интерфейс сетевого оборудования вообще не «поднимается», заканчивая частичной работой сетевого соединения. Причём частичная работа – это отдельный разговор, так как очень часто выявить причину трудно.

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

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

Для чего используется протокол ARP? Назначение

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

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

Максимальный размер кадра MTU

Третий случай (достаточно распространён). Он связан с максимальным размером кадра (MTU) и использованием технологий виртуальных частных сетей VPN. Проблема, связанная с MTU, проявляется следующим образом. Маленькие пакеты ходят через внешний канал, а вот большие пакеты нет. Например, всё «пингуется», можно подключиться к удалённому устройству по 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 необходимо уменьшить. Поэтому далее все пакеты идут уже с меньшим MTU, что исключает их фрагментацию, тем самым оптимизируя передачу их по сети.

В случае использования VPN технологий описанная схема определения MTU видоизменяется в сторону усложнения, но в целом остаётся той же. Добавляется как минимум ещё одно звено – VPN устройство, шифрующее пакеты. В этом случае ICMP сообщение изначально адресуется не оконечному оборудованию (компьютеру), а VPN устройству, от адреса которого идут зашифрованные пакеты. Проблемы начинаются, когда ICMP сообщение, информирующее о необходимости уменьшения MTU, по каким-то причинам не доходит до нашего оборудования. Например, блокируется провайдером. В этом случае оборудование, не получив ICMP сообщение, считает, что текущий размер MTU верен и продолжает посылать пакеты недопустимого размера, которые в конечном итоге сбрасываются. В качестве решения данной проблемы можно использовать изменение MTU на исходящем интерфейсе сетевого оборудования (например, сделав 1440), смотрящего в сеть Интернет, а также манипулирование параметром TCP Maximum Segment Size (MSS). Данный параметр содержится в заголовке пакета SYN протокола TCP и позволяет оконечным устройствам при установлении TCP-сессии согласовать максимальный размер сегмента TCP. При этом оборудование Cisco умеет менять этот параметр для проходящего через него транзитного трафика. В первом случае (изменение размера MTU на интерфейсе), когда «раздутый пакет» дойдёт до вашего пограничного сетевого устройства, оно его сбросит, отправив в обратную сторону сообщение об этом. Вероятность того, что это сообщение дойдёт до отправителя существенно выше, так как оно идёт по вашей сети. Во втором случае размер пакета будет сразу согласован при установлении TCP-соединения. Но второй механизм влияет только на TCP-пакеты. Есть ещё один вариант – это сбрасывание в ноль бита df, но это приводит к увеличению нагрузки на устройства, так как приводит к фрагментации пакетов.

Мониторинг загрузки каналов связи

Четвёртый случай. Настроили, подключили, работает. Проходит день-другой, и на несколько минут связь обрывается. Проходит ещё пара дней, и проблема повторяется. Проведённая диагностика никаких результатов не даёт. А поймать момент отказа, сложно, так как происходит он редко в разное время суток. Обращение к провайдеру никаких результатов не даёт. Провайдер, как обычно, утверждает, что у них всё работает корректно. В таких ситуациях определяющим моментом становится внимательность к работе сети как со стороны нас, инженеров компании CBS, так и со стороны заказчика. Необходимо обращать внимания на все отклонения от стандартной работы сети, которые могут теоретически провоцировать отказы. Для этого настраивается мониторинг в реальном времени как за загрузкой каналов связи, так и за качественным составом трафика (используются протоколы SNMP, Netflow и пр.). Бывают случаи, когда какой-нибудь сервер сбоит и периодически забивает полностью канал связи. Эту ситуацию легко отследить через мониторинг. В том случае, который мы рассматриваем, ситуация была не настолько очевидной, так как чёткой связи между сбоями и всплесками трафика не было найдено. Исход данной проблемы решила внимательность заказчика. Он заметил, что падение канала связано напрямую с обновление WSUS. После запуска обновлений серверов, трафик через канал переставал ходить. Проанализировав это, было решено написать письмо провайдеру с вопросом, а нет ли у них какой-нибудь системы IPS (Intrusion Prevention System) или её аналогов, которая бы блокировала трафик. Ответ, да есть, действительно блокирует. Итог: потраченное время в большом количестве на проверку того, что и так правильно настроено. А не проверить нельзя, так как какими бы мы ни были специалистами, всё равно в определённый момент в голове появляется сомнение, не мы ли ошиблись в настройках.

Итог

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

1. Implementing Cisco Unified Communications Manager, Part 1
2. Implementing Cisco Unified Communications Manager, Part 2