Raegdan13 фев 2016 в 13:53

Portgen — обходим фильтрацию портов

4 мин

23K

Программирование *

+12

Комментарии 61

ivan386 13 фев 2016 в 14:02

Если анонимность не критична то можно настроить в VPN роуты к сайтам которые доступны только через него а остальные гонять прямо. Тогда и статистика поправится.

buggykey 13 фев 2016 в 14:49

На мой взгляд, странно иметь свой собственный VPN и не пользоваться всеми плюшками.

ivan386 13 фев 2016 в 14:58

Так зачем по VPN гонять трафик который и напрямую неплохо ходит? Лишний крюк и задержки.

Raegdan 13 фев 2016 в 15:30

Шлюз в Киеве, следовательно максимальный крюк (обращение к серверу в Москве) 1500 км или 5 мс. При обращении в Европу крюка практически не будет, потому что обычная трасса и так где-то в тех краях проходит. При обращении на восток крюк составит маленький процент от общей длины трассы.

Гонять всё по VPN — потому что контора пишет, и потому что у некоторых сайтов два IP у одного пользователя могут вызвать ложную сработку защиты или просто какие-нибудь глюки, если компоненты сайта тянутся с разных доменов и попадут по разные стороны разруливания.

В любом случае у сервера мегабит больше, чем у клиента, поэтому хоть с VPNом, хоть без — узкое место всё равно с моей стороны.

JerleShannara 14 фев 2016 в 01:38

Нынче некоторые провайдеры поняли всё слишком прямо. Я вот с чего-то получил вдруг gateway timeout от nginx на своём собственном сайте, где его отродясь не было и нету, причем этот гейтвей таймаут везду где можно приходит от одной и тойже версии софта. Выводы — либо троян (но откуда под зоопарком систем он), либо провайдер играет в агента 007, и сделал что-то типа ip forward tcp from any to any port 80 to myfsckingproxy.

Varkus 15 фев 2016 в 05:04

У меня вот так билайн «чудит»:

с проводного провайдера через гугл попадаю на нужный мне музыкальный сайт

если всё тоже самое, но через свисток билайна, то с гугла я редиректюсь на билайновскую заглушку: качать любую музыку за 20р в день.

JerleShannara 15 фев 2016 в 14:18

Ну тут может и сам сайт чудить, партнерское соглашение с опсосом например заключено.

701054 15 фев 2016 в 08:25

Необязательно играет в 007, многие по-другому не могут выполнять требования РКН и поэтому делают разные ухищрения типа ацл по ip(чтобы не все заворачивать, а только то что на тех же ip что запрещено), и дальше каким-нибудь wccp на сквида где разбирают по урл пускать или на заглушку кидать. Просто костыли по-моему, а не 007.

JerleShannara 15 фев 2016 в 14:17

Вот тогда вопрос — как частный сервер, на котором выделенный IP, в списках роскомсакса не значащийся (да и как ему там оказаться, если по этому адресу висит тупой мониторинг помещения, причём адрес(IP) не менялся лет семь), с доменом который тоже в списках не значится, влетает в этот самый ACL. Ну не пойму я этого никак, либо крупный acl отжирает слишком много ресурсов на маршрутизаторе, либо провайдер — ленивая жопа, и ему проще весь трафик завернуть на прокси и уже там расхлёбывать все прелести жизни.

SilverHorse 13 фев 2016 в 15:14

«Всеми» это какими, например? Какие плюшки не использует человек, который заворачивает в VPN только критичную часть трафика, не жертвуя скоростью, стабильностью и доступностью для всего остального?

buggykey 13 фев 2016 в 15:22

Извините, не туда написал, мой комментарий здесь: https://geektimes.ru/post/271016/#comment_9018664

Coriander 13 фев 2016 в 15:59

На хабре регулярно появляются темы в стиле: мой провайдер вставляет мне рекламу в http трафик, а мой — заменяет мне кнопки на свои, а мой просто дополняет странички своими элементами. При этом с другой стороны идут топики на тему big data, как можно много извлечь данных из пользовательских страничек, и что навязанный правительством DPI на самом деле может приносить пользу, если знать как. А с третей стороны провайдеры догавариваются с рекламщиками, чтобы получать деньги за свои знания о пользователях, иногда основывают совместные проекты.

Вот чтобы всего этого счастья не было, приходится заворачивать весь трафик в VPN.

buggykey 13 фев 2016 в 15:20

Я имел ввиду ту самую деанонимизацию трафика, идущего помимо VPN.

ed007 13 фев 2016 в 15:31

Интересно, на каком основании провайдер запрещает vpn?

Raegdan 13 фев 2016 в 15:35

Фиг знает. Не факт, что это вообще против VPN сделано — это может быть защита от DDoSных ботнетов, например. Техподдержка клянется, что «мы ничего не режем» и «если вы уверены, что режут — это всё аплинк, мы за него не отвечаем». Ну, в принципе, ответ вполне ожидаемый.

mikes 13 фев 2016 в 15:34

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

Raegdan 13 фев 2016 в 15:37

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

vmchaz 13 фев 2016 в 15:34

Хм… вообще-то, за такие вещи надо сразу подавать жалобу в отдел по защите прав потребителей (конечно, если выход в интернет идёт не через работодателя, к примеру).

Да, по теме скрытия: а что, если трафик делить, например, на 4 части и пускать каждую часть трафика по своему порту, после чего на VPS собирать обратно и перенаправлять уже на порт VPN?

igorsd 13 фев 2016 в 16:17

И что вы в жалобе напишете? «Мне кажется мой оператор фильтрует мой трафик»? Оператор, на этот раз не устно, а в официальном письме, подтвердит: «нет, мы ничего не фильтруем», на этом всё и закончится, а проблема как была — там и останется.

Сначала неплохо подумать хорошенько и источник проблемы точно определить, а не жалобы писать.

«эвристика их фаервола»… надож придумать такое :)

Raegdan 13 фев 2016 в 18:43

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

igorsd 13 фев 2016 в 15:45

Провайдер тут скорее всего не при делах, а вот у хостера может быть какая-нибудь защита от DDOSа, которая считает обилие udp как флуд. Согласитесь, что куча входящего UDP на vps'е — редкость. Непонятно только, почему с такой задержкой…

Raegdan 13 фев 2016 в 15:47

Писал выше.

igorsd 13 фев 2016 в 16:01

Ну так вы сходите с ноутом на «пару-тройку дней» куда-нибудь, что бы IP ноута и порт не менялись — и оттуда заблочит ;)

Провайдеру ваш трафик разгребать и фильтровать смысла никакого нет — в 99,99% случаев провайдеру совершенно по барабану куда, что, как и в каких количествах вы отправляете. Пока вы не мешаете никому жить (а ваши, скажем, 50 мбит исходящего трафика точно никому помешать не могут) — никто в вашем трафике копаться не будет.

В оставшиеся 0,01%, когда оператору может быть интересен трафик пользователя, попадают:
1) запросы из «органов» из серии «а кто ходил туда-то тогда-то», которые, понятное дело, решаются без какого-либо вмешательства в трафик абонента
2) различные жалобы из серии «такой-то адрес используется в NTP amp. ddos, просьба принять меры» — но такие письма как правило все просто игнорируют
3) случаи когда абонент каким-то образом начинает влиять на работоспособность сети — но тут вам просто доступ в интернет закрыли бы и/или порт погасили, а не файрволы городили…

Raegdan 13 фев 2016 в 16:22

Я с этого ноутбука полтора года работал админом. Рабочий вайфай, где внешний адрес статический. Качал разный тяжеляк типа образов ОС, при этом работал на раздачу торрент (он всегда работает т.к. в автозагрузке стоит). Полёт нормальный.

igorsd 13 фев 2016 в 16:23

Становится интереснее :)
traceroute по UDP на нужный порт не поможет в поиске виновника?

зы. а что за провайдер?

Raegdan 13 фев 2016 в 16:44

Кинуть трейс — вы имеете в виду в момент, когда порт окажется заблочен, на этот самый порт? В то время не пробовал, а сейчас не хочется глушить канал ради этого.

igorsd 13 фев 2016 в 16:45

Ну у вас трассировка до ВПН сервера явно пойдёт не через туннель ;)

Вы просто так рьяно кинулись придумывать обходное решение не выяснив причин такого поведения. Мне вот было бы интересно — это трафик от вас до сервера блокируется или же трафик сервера до вас?
Если трафик сервера до вас — может и правда, какая-нибудь железка (например, некоторые DPI умеют) оператор пытается вас от несуществующего флуда защитить, но как-то уж очень странно это.

Raegdan 13 фев 2016 в 16:56

А. Я думал, вы имеете в виду сравнить трейсы, когда работает и когда нет. Ну при рабочем канале всё обычно: провайдер, наши аплинки, украинские аплинки, сеть хостера. А опять пытаться спровоцировать блок неохота. Он может произойти в понедельник, и линк отвалится вместе с возможностью удалённого доступа, т.е. до возвращения с работы всё будет лежать.

Raegdan 13 фев 2016 в 17:21

Именно от меня к серверу. Проверял tcpdump-ом по ssh на обеих сторонах.

igorsd 13 фев 2016 в 19:14

А заблокированные порты через некоторое время перестают блокироваться?

Raegdan 13 фев 2016 в 19:16

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

xut 13 фев 2016 в 15:54

Решение, конечно, отличное и скоро будет весьма актуальным, но в текущий момент времени уместнее было бы разобраться с провайдером.

EmmGold 13 фев 2016 в 17:40

берём условно 6000, прибавляем день в месяце, например 12, прибавляем неделю в месяце, например 2, прибавляем месяц в году, например 5, получаем порт 6019, и каждый день новый порт.
а котиков на ютубчике поглядеть можно и напрямую.

ProstoTyoma 13 фев 2016 в 21:47

А не проще 6000 + номер_дня_в_году?

Xazzzi 14 фев 2016 в 00:32

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

Raegdan 14 фев 2016 в 09:10

То есть, в итоге — хеш от огрублённого времени? Поздравляю, вы пришли примерно к тому же самому, к чему и я :)

701054 13 фев 2016 в 18:50

Интересное решение. Но 3 разных vpn можно и с tcp, если статика — клиент сервер поменяны местами, внутри ospf с разными приоритетами мне бы пришло в голову первым в такой ситуации. Скоро все может пригодиться и ещё заворачивать внутрь https туннеля )

ValdikSS 13 фев 2016 в 20:10

Теоретически, в этот момент соединение уже должно работать на новом порту, однако на практике оно почему-то продолжает использовать старый до перезапуска демона. Буду благодарен, если кто-нибудь объяснит причину такой багофичи, но пока я просто отдаю из скрипта команду на перезапуск. Перебой связи при этом — несколько секунд и неудобства не причиняет.

Предполагаю, что дело в conntrack — соединение запоминается и фильтры не применяются. Можно удалить информацию о соединении через утилиту conntrack (пакет conntrack-tools).

Вообще, конечно, провайдер не должен таким заниматься. У того же IPsec порт просто так не сменишь, а там тоже чаще всего UDP-инкапсуляция.
Что за провадер? Вы в России?

Raegdan 14 фев 2016 в 09:23

Спасибо за объяснение.

Да, в России. Провайдера называть не хочу, чтобы не привлекать его внимание. А то, не ровен час, ещё какую пакость придумают.

IPsec? А он в быту часто применяется? ;)
Вполне возможно, что он тоже не работает (не пробовал), да вот только те, кому он нужен в быту составляют подавляющее меньшинство, значимого спроса не создают и провайдеру, увы, плевать.

Ещё раз говорю: я не имею оснований утверждать, что это борьба именно с VPN. Это может быть эхо войны с ддосерами или подобным говном. Просто поступили по логике: дубовое решение на коленке слепили, ддосеров победили, 99% абонентов не повредили, ну и отлично — а 1% гиков пусть вертится, как хочет.

ValdikSS 14 фев 2016 в 09:27

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

Ну что за ребячество? Назовите провайдера, и другие люди будут осведомлены о проблемах с ним. Вы вообще писали провайдеру о проблеме?
Я использую IPsec настолько же часто, насколько OpenVPN — мой телефон поддерживает только его, и в Windows и OS X поддержка встроена в ОС тоже.

Raegdan 14 фев 2016 в 09:44

Писать — не писал, но в техподдержку звонил, и даже со второй линией общался по этому поводу.

Фиолетовый московский провайдер, нынче принадлежащий зелёному сотовому оператору.

MichaelBorisov 13 фев 2016 в 20:35

Решение хорошее, но работать оно будет ровно до того момента, пока провайдер вообще не отключит вам UDP.

"… Пока не пришел день полного освобождения, вы должны сосуществовать с другими. Вы можете покинуть их, но они могут пойти за вами и навязать вам свое присутствие." © Г. Гаррисон

И я поддерживаю идею, что решаться проблема должна радикально: путем обжалования, путем смены провайдера. Иначе что это получается? Вы фактически не имеете интернета, а имеете его суррогат, если не можете пересылать любые пакеты в любом направлении.

EugeneButrik 13 фев 2016 в 21:30

Вообще отключит UDP? Хм… какой коварный провайдер, который так изощренно прекращает предоставлять свои услуги :)

MichaelBorisov 13 фев 2016 в 21:54

Ну, может быть, DNS только оставит, и тот — с DPI, чтобы не злоупотребляли. Веб будет работать, а все остальное «надо еще доказать». Если человеку просто так, без причины, рубят один порт UDP — то это тоже по сути прекращение предоставления услуг. Но он прибегает к техническим методам обхода (поскольку блокируется только один порт), аргументируя это тем, что «доказать сложно». Тут по сути то же самое.

У меня был случай с украинским провайдером — интернет работал чрезвычайно медленно, с перебоями (все протоколы), пока использовал VPN. Не сразу разобрался, в чем было дело. Думал, просто провайдер глючит.

EugeneButrik 13 фев 2016 в 22:03

И что? Разобрались с провайдером? Он действительно фильтровал трафик (отрубая полностью или снижая пропускную способность) на транспортном уровне, нагружая этим своё оборудование?

MichaelBorisov 13 фев 2016 в 22:22

Да, разобрался. Как только перестал пользоваться VPN — все заработало.

EugeneButrik 13 фев 2016 в 22:44

Классные провайдеры. Это прям классика нашего постсовкового бизнеса — пообещать "до 50 Мбит/с", а потом делать всё возможное не для того чтобы обеспечить ему эти 50 Мбит/с, а для того чтобы этих самых 50 Мбит/с потребитель не смог достичь никогда.

Raegdan 14 фев 2016 в 09:07

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

lexore 13 фев 2016 в 23:46

Фильтрация UDP — это, скорее всего, блокировщик DDoS/левых пакетов из интернета (и, возможно, оборзевших торрентов).
Если вам ещё интересно, попробуйте TCP, на каких-нибудь попсовых портах (20, 21, 22, 80, 443). Или просто ниже 1024 (диапазон системных сервисов) или выше 49152 (диапазон динамически открываемых соединений). Мне кажется, на это не будет реакции. Не буду рекомендовать TCP для продакшена, с ним может быть чуть больше задержка.

Вы знаете, сервер в принципе можно оставить слушать весь диапазон.
И у вас интересный механизм генерации порта. Не пробовали что-нибудь попроще, например port++? :) А номер порта хранить на гитхабе.

Raegdan 14 фев 2016 в 08:57

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

ValdikSS 14 фев 2016 в 09:29

Неправда, вы, видимо, что-то не так настроили. Снижение скорости обычно не сильно значительное, по крайней мере, не такое, чтобы вообще от TCP отказаться.

zabbius 14 фев 2016 в 19:27

+1 проблемы возникают только при передаче чего-нить типа RTP, когда пакеты начинают вставать в очередь вместо того, чтобы выкидываться. TCP подключения через TCP OpenVPN работают нормально.

TrurlMcByte 15 фев 2016 в 05:04

Можно ещё кооперироваться с другими такими же любителями своего VPN на VPS, и, в этом случае, ещё и IP менять по заданной кооперативной программе. Правда, это потребует ещё и учитывать трафик каждого участника такого кооператива (на всякий пожарный), но это не шибко сложная задача для коллективного творчества.
Эдакое товарищество VPN-VPSосоводов-любителей.