Доброго времени суток, коллеги.
Сразу хочу оговориться, что данная заметка… это просто заметка по некоей технической проблеме, которая, как кажется автору, имеет некоторое отношение к тематике раздела, где она публикуется.
Вот здесь habrahabr.ru/post/148200 уже затрагивалась тема проксирования через бесплатные VPN сервисы, теперь речь пойдет о мобильном интернете.
Вообще, автор заметки мало пересекался с такими «зверьми», как всякие там GPRS/2G/3G и прочее. Но однажды пришлось.
Однажды на одном удаленном объекте пропал канал (а точнее все каналы) до объекта головного. И это было очень плохо. Срочно требовалось временное решение и учитывая всю массу сопутствующих факторов (весьма нерадостных), не «вытанцовывалось» ничего лучше, чем pptp через обычный USB-«свисток». Но заработает ли? И автора заметки и коллег «по цеху» взяли сомнения. Поди сотовый оператор все это дело режет. Но попробовать решили. Попробовали. Когда модемное соединение завелось, выяснили по-быстрому, через какой реальный IP натится наш трафик у оператора, посмотрели whois, получили сетку с маской /21, открыли ее на файрволе пограничного оборудования, где должен был терминироваться pptp туннель, попробовали — VPN завелся.
Приятная новость, оператор не режет TCP 1723 и GRE. Временная схема отработала свое, каналы починились. Но в один «прекрасный» момент упали опять, при этом испытанная ранее временная схема не заработала. Небольшой траблшутинг и результат, который слегка удивил.
Трафик, отличный от pptp (тестовый ping, коннект на произвольные нестандартные порты) у оператора натится через один внешний IP (ну не вообще один, ясно, что их некий пул, имеется в виду один и тот же для конкретного модемного соединения), а pptp — через некий другой. Причем этот другой отстоит от gprs-пула (/21), выявленного ранее и открытого в аксесс листах достаточно серьезно. И не резолвится в имя, в отличие от IP из gprs-пула. И whois ничего не проясняет.
Подправили аксесс листы, туннель завелся. Так как риск повторной аварии на обычных каналах какое-то время был велик, этот «костыль» совсем убирать не стали. И в результате набралась любопытная статистика. При падениях и повторных коннектах «свистка» выдавались, естественно, разные серые IP, внешний IP, от которого натился обычный трафик менялся, но IP, с которого оператор натил pptp оставался постоянным.
При этом туннель периодически падал и не хотел заводиться, иногда весьма долго, вплоть до рабочей смены и даже пару раз до нескольких дней. Затем вдруг опять начинал работать как ни в чем не бывало.
Автор заметки долго отгонял разные мыслишки, убеждая себя, что нечего паранойей страдать, мало ли чего там накручено в «черном ящике» операторской сети, но… решил все же подебажить ситуацию более детально.
Ничего подозрительного с pptp-трафиком замечено в итоге не было (кроме изначальной ситуации с натом от непонятного IP). Но вот во время этого дебага всплыли интересные подробности относительно трафика HTTP.
Факты.
1. Коннект на IP некоего подконтрольного автору сервера на закрытый/непрослушиваемый 80 порт успешно проходил (при полном отсутствии входящего трафика на сервере-цели в момент установления коннекта).
2. Такое было не всегда, какая либо тенденция не прослеживалась.
3. Когда на сервере-цели был запущен netcat на 80 порту, выявилось, что проксирование то присутствует в явном виде, то — непонятно.
В случае, когда его предположительно нет, ничего на L7 лишнего не появляется и не модифицируется, версия протокола, заголовки и т. п. Причем, если посылать в канал, например, ошибочные запросы, они передаются как есть «насквозь», к разрыву соединения это не приводит.
Когда проксирование точно есть, при посылаемом минималистичном «GET /» netcat на сервере выдавал прелюбопытное
GET / HTTP/1.1
X-Via: Harmony proxy
Host: xx.xx.xx.xx
а телнет при разрыве по таймауту
Сразу хочу оговориться, что данная заметка… это просто заметка по некоей технической проблеме, которая, как кажется автору, имеет некоторое отношение к тематике раздела, где она публикуется.
Вот здесь habrahabr.ru/post/148200 уже затрагивалась тема проксирования через бесплатные VPN сервисы, теперь речь пойдет о мобильном интернете.
Вообще, автор заметки мало пересекался с такими «зверьми», как всякие там GPRS/2G/3G и прочее. Но однажды пришлось.
Однажды на одном удаленном объекте пропал канал (а точнее все каналы) до объекта головного. И это было очень плохо. Срочно требовалось временное решение и учитывая всю массу сопутствующих факторов (весьма нерадостных), не «вытанцовывалось» ничего лучше, чем pptp через обычный USB-«свисток». Но заработает ли? И автора заметки и коллег «по цеху» взяли сомнения. Поди сотовый оператор все это дело режет. Но попробовать решили. Попробовали. Когда модемное соединение завелось, выяснили по-быстрому, через какой реальный IP натится наш трафик у оператора, посмотрели whois, получили сетку с маской /21, открыли ее на файрволе пограничного оборудования, где должен был терминироваться pptp туннель, попробовали — VPN завелся.
Приятная новость, оператор не режет TCP 1723 и GRE. Временная схема отработала свое, каналы починились. Но в один «прекрасный» момент упали опять, при этом испытанная ранее временная схема не заработала. Небольшой траблшутинг и результат, который слегка удивил.
Трафик, отличный от pptp (тестовый ping, коннект на произвольные нестандартные порты) у оператора натится через один внешний IP (ну не вообще один, ясно, что их некий пул, имеется в виду один и тот же для конкретного модемного соединения), а pptp — через некий другой. Причем этот другой отстоит от gprs-пула (/21), выявленного ранее и открытого в аксесс листах достаточно серьезно. И не резолвится в имя, в отличие от IP из gprs-пула. И whois ничего не проясняет.
Подправили аксесс листы, туннель завелся. Так как риск повторной аварии на обычных каналах какое-то время был велик, этот «костыль» совсем убирать не стали. И в результате набралась любопытная статистика. При падениях и повторных коннектах «свистка» выдавались, естественно, разные серые IP, внешний IP, от которого натился обычный трафик менялся, но IP, с которого оператор натил pptp оставался постоянным.
При этом туннель периодически падал и не хотел заводиться, иногда весьма долго, вплоть до рабочей смены и даже пару раз до нескольких дней. Затем вдруг опять начинал работать как ни в чем не бывало.
Автор заметки долго отгонял разные мыслишки, убеждая себя, что нечего паранойей страдать, мало ли чего там накручено в «черном ящике» операторской сети, но… решил все же подебажить ситуацию более детально.
Ничего подозрительного с pptp-трафиком замечено в итоге не было (кроме изначальной ситуации с натом от непонятного IP). Но вот во время этого дебага всплыли интересные подробности относительно трафика HTTP.
Факты.
1. Коннект на IP некоего подконтрольного автору сервера на закрытый/непрослушиваемый 80 порт успешно проходил (при полном отсутствии входящего трафика на сервере-цели в момент установления коннекта).
2. Такое было не всегда, какая либо тенденция не прослеживалась.
3. Когда на сервере-цели был запущен netcat на 80 порту, выявилось, что проксирование то присутствует в явном виде, то — непонятно.
В случае, когда его предположительно нет, ничего на L7 лишнего не появляется и не модифицируется, версия протокола, заголовки и т. п. Причем, если посылать в канал, например, ошибочные запросы, они передаются как есть «насквозь», к разрыву соединения это не приводит.
Когда проксирование точно есть, при посылаемом минималистичном «GET /» netcat на сервере выдавал прелюбопытное
GET / HTTP/1.1
X-Via: Harmony proxy
Host: xx.xx.xx.xx
а телнет при разрыве по таймауту
Error 504 Gateway Timeout
HTTP ERROR: 504
Gateway Timeout
RequestURI=http://xx.xx.xx.xx/
4. Такие параметры, как TTL для IP и MSS для TCP явно модифицируются во всех случаях трафика на 80 порт. Так, снифер на хосте с модемом показывает для исходящих IP пакетов стандартное для Win значение TTL 128, принятые же сервером эти пакеты уже имеют TTL 167. Пакеты, отправляемые в ответ сервером, на хосте имеют значение 194, что так же больше изначального значения для моего сервера. Стандартное значение MSS превращается в 1210. Причем описанный эффект наблюдается только для трафика через 80 порт. Если брать произвольные высокие порты, то MSS в порядке, TTL меньше начального стандартного на разумное число хопов.
Что скажете, уважаемые хаброжители? Что за зверь Harmony proxy и чем он облегчает жизнь оператору?
Непонятка же с pptp вполне актуальна до сих пор, т. к. на момент написания заметки туннель не работает, а хотелось бы.
UPD: Может господа-рулевые уважаемого оператора прочли этот топик и подняли наконец упавший линукс-"тазик"? VPN завелся :)