Здравствуйте, уважаемые хабровчане. Веду небольшой проект по мониторингу автотранспорта, но это к делу не имеет особого отношения. Суть в следующем — в оборудовании установлены сим-карты компании МТС, используются сотовые модемы WISMO 228. В течение нескольких лет все шло хорошо, но недавно, а конкретно с 21.07.2015 стал замечать странности в поведении некоторых объектов:
При въезде автомобиля в какой либо из регионов — Татарстан, Башкортостан, Пензенская область, начинаются странные глюки со связью, а именно:
UDP пакеты от устройств доходят до сервера.
TCP пакеты от устройств доходят до сервера (сервер показывает открытый TCP коннект).
В обратном же направлении данные не доходят.
Девайсы работают с сервером по FTP протоколу, при этом они не могут дождаться приветствия от FTP сервера, чтобы начать авторизацию.
Пробовал принудительно начинать авторизацию на FTP — в логах сервера нет даже упоминания о попытках авторизации с таких устройств.
Замечены следующие закономерности:
Основная масса устройств имеет «внешний» IP адрес из диапазона 213.87.хх.хх (шлюз выхода в интернет), глючащие же устройства имеют IP адрес 85.140.хх.хх, или 95.153.167.хх (волгоградская область). Адрес этот присваивается автоматически, т.е. девайс при поднятии сессии PPP берет то, что ему скажет APN, само ничего не выдумывает.
При покидании глючных регионов работа по обмену данными полностью восстанавливается.
В других регионах, например дальний восток, адрес устройства имеет вид 80.83.237.хх, при этом обмен идет нормально.
В казахстане тоже работает нормально (с казахстанской сим-картой).
Ради интереса построил трассу до IP адреса.
traceroute 85.140.0.87
traceroute to 85.140.0.87 (85.140.0.87), 64 hops max, 52 byte packets
1 gw.ispsystem.net (37.230.113.254) 0.318 ms 0.287 ms 0.286 ms
2 edge.webdc.ru (92.63.108.97) 14.326 ms 7.129 ms 0.579 ms
3 213.219.206.17 (213.219.206.17) 1.082 ms 1.235 ms 15.737 ms
4 vl–709.sr5.msk7.ip.di–net.ru (213.248.3.133) 0.969 ms 0.932 ms 0.835 ms
5 m9–cr03–ae10.995.msk.stream–internet.net (212.188.60.173) 1.258 ms 1.241 ms 1.246 ms
6 bek–cr01–ae7.52.nnov.stream–internet.net (212.188.28.70) 8.423 ms 7.997 ms 7.996 ms
7 pgag–cr02–ae5.52.nnov.stream–internet.net (195.34.59.97) 10.143 ms 7.984 ms 7.968 ms
8 * * *
9 * * *
10 * * *
это «глючащий» IP. Когда строю трассу до этого диапазона адресов, она всегда обрывается на хосте из 7й строки. Причем не важно откуда я пытаюсь пробить трассу, с сервера, с которого осуществляется обмен, либо с любого другого компьютера, подключенного к другим провайдерам.
Трасса
~ traceroute 213.87.123.66
traceroute to 213.87.123.66 (213.87.123.66), 64 hops max, 52 byte packets
1 gw.ispsystem.net (37.230.113.254) 0.433 ms 0.401 ms 0.393 ms
2 edge.webdc.ru (92.63.108.97) 0.358 ms 0.386 ms 0.356 ms
3 213.219.206.17 (213.219.206.17) 5.998 ms * 130.690 ms
4 vl–709.sr5.msk7.ip.di–net.ru (213.248.3.133) 1.000 ms 0.899 ms 0.961 ms
5 m9–cr03–ae10.995.msk.stream–internet.net (212.188.60.173) 1.354 ms 1.374 ms 1.337 ms
6 m9–cr05–ae1.199.msk.stream–internet.net (195.34.53.49) 53.896 ms 53.863 ms 53.900 ms
7 psnmich–cr01–ae4.62.rzn.stream–internet.net (212.188.42.70) 60.579 ms 128.957 ms
psnmich–cr01–ae6.62.rzn.stream–internet.net (212.188.29.194) 98.938 ms
8 pstamb–cr01–ae5.68.tam.stream–internet.net (212.188.28.202) 54.318 ms
pstamb–cr01–ae7.68.tam.stream–internet.net (212.188.29.186) 53.930 ms 54.087 ms
9 pspenz–cr01–ae4.58.pen.stream–internet.net (212.188.29.182) 54.744 ms
pspenz–cr01–ae3.58.pen.stream–internet.net (212.188.28.246) 54.070 ms 54.829 ms
10 psulnsk–cr01–ae2.73.uln.stream–internet.net (212.188.28.210) 63.088 ms 57.998 ms
psulnsk–cr01–ae5.73.uln.stream–internet.net (212.188.42.34) 54.026 ms
11 pskir–cr01–ae1.63.sam.stream–internet.net (212.188.28.226) 54.266 ms 54.288 ms
pskir–cr01–ae3.63.sam.stream–internet.net (212.188.42.30) 56.315 ms
12 psbek–cr01–ae4.2.ufa.stream–internet.net (212.188.42.82) 53.956 ms 66.351 ms
psbek–cr01–ae2.2.ufa.stream–internet.net (212.188.28.50) 53.901 ms
13 psshag–cr01–ae3.74.chel.stream–internet.net (212.188.42.98) 31.250 ms 31.555 ms 31.370 ms
14 psber–cr01–ae4.72.tum.stream–internet.net (212.188.29.226) 60.442 ms 54.279 ms 54.335 ms
15 pstav–cr01–ae5.55.omsk.stream–internet.net (212.188.28.162) 53.861 ms 63.988 ms 53.835 ms
16 psvost–cr01–ae6.54.nsk.stream–internet.net (212.188.28.158) 52.932 ms 53.157 ms 53.471 ms
17 stn–cr03–be3.54.nsk.stream–internet.net (212.188.29.133) 58.571 ms 57.156 ms 73.175 ms
18 mts–siberia.nsk.stream–internet.net (195.34.36.58) 81.223 ms 53.714 ms 53.786 ms
19 217.8.224.126 (217.8.224.126) 54.576 ms 54.527 ms 54.414 ms
20 * * *
21 213.87.117.245 (213.87.117.245) 56.088 ms 56.120 ms 55.998 ms
22 * * *
Службу поддержки терзаю уже неделю, но они могут только сказать, что «баланс на вашем счете положительный». Надежды на них нет.
К технарям не подпускают. Определить где проблема, не могу.
Может есть кто из сообщества, имеющий возможность помочь отследить баг? Спасибо.
— Update от 06.08.2015 —
В общем дело такое — удалось «поймать» машинку на подлете к проблемному региону и переписать ей конфиг FTP на другой порт.
На сервере переписал конфиг FTP, заменив одно значение — номер порта.
— Update от 07.08.2015 —
После написания поста откликнулось несколько человек, в том числе специалисты компании МТС, проблему удалось решить. За что им огромное спасибо.
Комментарии (36)
dom1n1k
05.08.2015 13:45+4Поддержка у мтс — это кунсткамера и потемкинская деревня в одном лице
shaman3D
05.08.2015 22:30В Мегафоне и технари такие же. Обращение в ТП №292340047 переданное «технарям» рассматривает с 29.06.15. Проблему решают — за ежедневное снятие абон. платы не предоставляется включённый в плату пакет минут и смс. В итоге оплачиваю ежесуточно абон. плату «за просто так» плюс за минуты и смс отдельно.
dom1n1k
05.08.2015 22:40О, это мне знакомо. 3 месяца яйцеголовые решали проблему как-то. Поддержка на многочисленные звонки говорила «специалисты работают», хотя позднее выяснилось, что никто даже не почесался в этом направлении (не знаю, по чьей вине, да и не хочу знать). Дело сдвинулось с мертвой точки только после написания письменной претензии в офисе (да, надо было раньше догадаться, но я чо-та верил, что мне не врут...)
Rondo
05.08.2015 13:53+1Вспоминается история, как МТС блокировали мобильное приложение Yota, там целое исследование с Wireshark`ом и эмулятором приложения.
subver
05.08.2015 14:02Вот поведение очень похоже. Коннект идет, обмен данными — не идет. Ладно бы еще была возможность под отладчиком посидеть во время глюков, но мне до того места, где «глючит» почти 2тыс. км. Но я не думаю, что это какая то акция мтс, ибо проект небольшой, и конкуренцию вряд ли кому то составит. Скорее какой то баг в шлюзовании трафика.
Rondo
05.08.2015 14:05+1Потратьте ваш «положительный баланс» и купите сим-карты другого оператора, можно даже номера перенести. Вроде вас ничего не держит на МТС`е, судя по тексту поста.
subver
05.08.2015 14:08Изначально зона покрытия была поинтереснее, сейчас надо посравнивать. Проблема в другом — при смене оператора придется ловить все девайсы и перевтыкать симки.
alexpaknix
05.08.2015 14:28У МТСа, в Татарстане, инет неюзабельный уже года как два-три. Обращался в техподдержку, но с их стороны блокировок трафика нет (с) их ответ
subver
05.08.2015 14:30Да как бы до 21.07.15 работало, меня интересует то только FTP, остальное — не важно.
fido_max
05.08.2015 15:14В Пензе года два три назад тоже ушел по этой же причине от МТС. До определенного момента все работало как часы, а потом они то-ли с шейпером перемудрили… то ли еще что… В итоге было так: коннект есть, пинги идут, трассировка тоже, а интернета почти нет.
NorthFighter
06.08.2015 20:09В Норильске такая же картина и могу с точностью 100% уверить, что да, дело в шейпере ибо имел возможность беседовать с их технарем из макрорегиона и в телефонном режиме он вносил правки, а я на своем канале видел результат. Макрорегион Сибирь с центром в Новосибирске.
ValdikSS
15.08.2015 21:30Уверены, что в шейпере? Пару лет назад, как раз в Сибири, я наблюдал интересную ситуацию, когда то устройство, которое делает NAT, внезапно забывало его делать для сайтов, к которым вы чаще всего обращаетесь и взаимодействуете. На сервер приходил трафик от внутреннего IP 10.x.x.x, причем ICMP работает нормально. Пытался решить проблему в течение 2 месяцев, звонил и писал в МТС каждую неделю, так и не починили, пришлось уйти от МТС.
toster.ru/q/21737
cc: fido_max
bitterman
05.08.2015 15:00У нас то же самое, только связь вообще держится порядка 30 секунд после подъёма GPRS-сессии (проверяем через ping ya.ru).
Отлаживаем с двух сторон. М2М симки не помогают. Технаря из МТС уже дали (через полтора месяца ругани). Результатов пока нет, при этом воспроизводимость проблемы — 99%. Попутно берём колдовские утилиты от поставщика модемов, будем снимать логи, как выглядит ситуация с точки зрения самого модема.
Альтернативные операторы — работают, что подстёгивает МТС решить таки нашу проблему.
reallord
05.08.2015 15:56+2Тоже пару лет назад в Нижнем Новгороде была проблема именно с FTP на МТС.
Сеть магазинов, обмен с ними перестал внезапно работать. По итогам общения с МТС, через 3 недели сменили все 48 СИМ карт на другого оператора.
С их стороны все пули вылетают. По нашему анализу, проблема где-то была внутри МТС с маршрутизацией через один из узлов.
Переподключение СИМ карты иногда давало шанс получить нормальный, рабочий IP, на котором FTP начинал внезапно работать.
Viacheslav01
05.08.2015 18:10Была проблема с МТС нам по пути рвали соединение, выглядело как зависший TCP, в итоге нашли в промежутке оператора который рвал соединение потому, что считал трафик подозрительным. И да проблема была только с картами МТС, с другими операторами все было хорошо.
Asgoret
05.08.2015 20:52Аналогичная проблема была у билайна (у меня дома). Инет идет, но где-то на уровне районного (или административного округа) роутер начинает творить несусветную чушь. Чтобы кратко:
1-звонок:
1-ая линия: все зарегистрировала, сразу перебросила на вторую (была ночь, поэтому вторая что-то потыкала, но безуспешно. сказали отдадут куда-то глубже).
2-звонок:
1-ая линия: несмотря на номер заявки пришлось пройти все повторно (не страшно заявки связали и перебросили снова на вторую)
2-ая линия: что-то потыкали, я повисел на линии, затем перебросили на 3.
3-ая линия: долго и нудно бодались со специалистом.он проверял, я делал. он ребутал порты, проверял связь, потери, целостности, маршрутизации (долго, нудно, но с его слов проблема не у них, а на конечной стороне).
3-звонок.
1-2: аналогично 2 звонку
3 линия: долго бодались.сказали отдадут в отдел «маршрутизации» или как-то там.
Ожидание 2-3 дня.
4-звонок:
1-2 линия тоже самое.
3 линия: объяснили, что маршрутизатор пускает дублирует трафик сразу на оба канала. на основной и на резервный. зачем так нужно-мне не понятно.
Итог: скорость восстановили. видимо что-то починили, но мне не сказали. Со слов друга который там работал: отдел который занимается настройкой маршрутизации ленивый до одного места.По срокам где-то 2-3 недели решалось.с учетом того, что я не всегда был дома и звонил с разрывом в 2-3 дня.перезванивали мне, откладывали на неделю заявки(хотя максимум 2-3 дня.думаю SLA все знают). пообщался просто с рук-вом группы. В общем на тот момент извинений не было, все валили на меня или сторону, но починили и, на тот момент, люди были умные *даже первая линия, что редкость*. даже попросили прислать скрины трасы и еще чего-то)
justaguest
05.08.2015 21:04Я так понимаю, IP серый? Просто предположение — может быть это как-то связано с типами NAT? Возможно в проблемных регионах он отличается?
icCE
06.08.2015 06:29Быстрое решение проблемы, это поднятие VPN.
Как поднять OpenVPN в интернете статей тысячи.
А так похоже, что криво работает FTP за NATsubver
06.08.2015 06:32+3Отлично. На устройстве нет операционной системы, и несколько кб ОЗУ. Есть ссылка на реализацию OpenVPN? Учитывая, что почти вся ОЗУ занята под реализацию стека TCP/IP
icCE
06.08.2015 10:01Я только сейчас посмотрел, что это за модемы. К сожалению, такого поворота я не ожидал.
С другой стороны, я не знаю, что вы храните на ftp — но ftp сам по себе не надежен и является дырой. (если только не ftp+tls)
С другой стороны я понимаю всю вашу боль с такими устройствами, но подумать о реализации своего туннеля стоит.
subver
06.08.2015 07:01+1В общем дело такое — удалось «поймать» машинку на подлете к проблемному региону и переписать ей конфиг FTP на другой порт.
На сервере переписал конфиг FTP, заменив одно значение — номер порта.
Все работает. Но «проблема не у МТС», да.icCE
06.08.2015 10:06Я тут еще раз перечитал пост. Проблема в реализации активного и пасивного ftp + глюки с выделенными ip у провайдера. Там поверьте своя кухня и атмосфера у NOC происходит парой.
Я правильно понимаю, что у вас ftp работает в активном режиме?
Те когда клиент устанавливает соединение на 21 порт сервера и передает команду PORT, в которой указывает свой адрес и порт для передачи данных, а потом сервер устанавливает соединение с 20 порта на указанный в команде порт клиента.?
Если да, надо попробовать пасивный режим работы ftp.
subver
07.08.2015 14:08+2После написания поста откликнулось несколько человек, в том числе специалисты компании МТС, проблему удалось решить. За что им огромное спасибо.
Rondo
07.08.2015 18:36subver, а рассказали, из-за чего была проблема? интересно было бы узнать технические подробности
belovictor
07.08.2015 21:30+1Проблема в NAT у Juniper. Никаких особых подробностей, просто глюк в софте производителя…
ValdikSS
15.08.2015 21:38Вы из МТС? Почему фрагментированные пакеты не ходят, и когда почините? Я заявку оставлял еще в ноябре и пару раз подпинывал, обещали в феврале еще починить.
Krey
5 баллов за картинку!