Как стать автором
Обновить

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

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

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

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

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

если всё тоже самое, но через свисток билайна, то с гугла я редиректюсь на билайновскую заглушку: качать любую музыку за 20р в день.
Ну тут может и сам сайт чудить, партнерское соглашение с опсосом например заключено.
Необязательно играет в 007, многие по-другому не могут выполнять требования РКН и поэтому делают разные ухищрения типа ацл по ip(чтобы не все заворачивать, а только то что на тех же ip что запрещено), и дальше каким-нибудь wccp на сквида где разбирают по урл пускать или на заглушку кидать. Просто костыли по-моему, а не 007.
Вот тогда вопрос — как частный сервер, на котором выделенный IP, в списках роскомсакса не значащийся (да и как ему там оказаться, если по этому адресу висит тупой мониторинг помещения, причём адрес(IP) не менялся лет семь), с доменом который тоже в списках не значится, влетает в этот самый ACL. Ну не пойму я этого никак, либо крупный acl отжирает слишком много ресурсов на маршрутизаторе, либо провайдер — ленивая жопа, и ему проще весь трафик завернуть на прокси и уже там расхлёбывать все прелести жизни.
«Всеми» это какими, например? Какие плюшки не использует человек, который заворачивает в VPN только критичную часть трафика, не жертвуя скоростью, стабильностью и доступностью для всего остального?
На хабре регулярно появляются темы в стиле: мой провайдер вставляет мне рекламу в http трафик, а мой — заменяет мне кнопки на свои, а мой просто дополняет странички своими элементами. При этом с другой стороны идут топики на тему big data, как можно много извлечь данных из пользовательских страничек, и что навязанный правительством DPI на самом деле может приносить пользу, если знать как. А с третей стороны провайдеры догавариваются с рекламщиками, чтобы получать деньги за свои знания о пользователях, иногда основывают совместные проекты.

Вот чтобы всего этого счастья не было, приходится заворачивать весь трафик в VPN.
Я имел ввиду ту самую деанонимизацию трафика, идущего помимо VPN.
Интересно, на каком основании провайдер запрещает vpn?
Фиг знает. Не факт, что это вообще против VPN сделано — это может быть защита от DDoSных ботнетов, например. Техподдержка клянется, что «мы ничего не режем» и «если вы уверены, что режут — это всё аплинк, мы за него не отвечаем». Ну, в принципе, ответ вполне ожидаемый.
почему именно провайдер пал под подозрение, а не хостер… может быть он и режет разные аномалии у себя.
С клиентов на других провайдерах проблем нет. Ноут тоже туда подключается, и куда с ним ни ходил — везде работает.
Хм… вообще-то, за такие вещи надо сразу подавать жалобу в отдел по защите прав потребителей (конечно, если выход в интернет идёт не через работодателя, к примеру).

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

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

«эвристика их фаервола»… надож придумать такое :)
Ну я в терминологии могу быть не силён, но как назвать такой механизм? Который принимает решение, обнаруживая определённый паттерн поведения.
Провайдер тут скорее всего не при делах, а вот у хостера может быть какая-нибудь защита от DDOSа, которая считает обилие udp как флуд. Согласитесь, что куча входящего UDP на vps'е — редкость. Непонятно только, почему с такой задержкой…
Ну так вы сходите с ноутом на «пару-тройку дней» куда-нибудь, что бы IP ноута и порт не менялись — и оттуда заблочит ;)

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

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

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

Вы просто так рьяно кинулись придумывать обходное решение не выяснив причин такого поведения. Мне вот было бы интересно — это трафик от вас до сервера блокируется или же трафик сервера до вас?
Если трафик сервера до вас — может и правда, какая-нибудь железка (например, некоторые DPI умеют) оператор пытается вас от несуществующего флуда защитить, но как-то уж очень странно это.
А. Я думал, вы имеете в виду сравнить трейсы, когда работает и когда нет. Ну при рабочем канале всё обычно: провайдер, наши аплинки, украинские аплинки, сеть хостера. А опять пытаться спровоцировать блок неохота. Он может произойти в понедельник, и линк отвалится вместе с возможностью удалённого доступа, т.е. до возвращения с работы всё будет лежать.
Именно от меня к серверу. Проверял tcpdump-ом по ssh на обеих сторонах.
А заблокированные порты через некоторое время перестают блокироваться?
Если с них уйти — разумеется. Через сколько разблокируют — не замерял, но предполагаю тот же порядок цифр, что и для блокировки.
Решение, конечно, отличное и скоро будет весьма актуальным, но в текущий момент времени уместнее было бы разобраться с провайдером.
берём условно 6000, прибавляем день в месяце, например 12, прибавляем неделю в месяце, например 2, прибавляем месяц в году, например 5, получаем порт 6019, и каждый день новый порт.
а котиков на ютубчике поглядеть можно и напрямую.
А не проще 6000 + номер_дня_в_году?
Ну, так интервал будет целый день. Проще уже unixtime поделить с округлением на количество секунд до смены порта, ну и от результата взять остаток от деления на желаемую длинну диапазона портов.
Только так порты подряд будут, нужно ещё что-то поверх навернуть, чтобы избежать упорядочености. Любая хеш-функция должна справиться.
То есть, в итоге — хеш от огрублённого времени? Поздравляю, вы пришли примерно к тому же самому, к чему и я :)
Интересное решение. Но 3 разных vpn можно и с tcp, если статика — клиент сервер поменяны местами, внутри ospf с разными приоритетами мне бы пришло в голову первым в такой ситуации. Скоро все может пригодиться и ещё заворачивать внутрь https туннеля )
Теоретически, в этот момент соединение уже должно работать на новом порту, однако на практике оно почему-то продолжает использовать старый до перезапуска демона. Буду благодарен, если кто-нибудь объяснит причину такой багофичи, но пока я просто отдаю из скрипта команду на перезапуск. Перебой связи при этом — несколько секунд и неудобства не причиняет.
Предполагаю, что дело в conntrack — соединение запоминается и фильтры не применяются. Можно удалить информацию о соединении через утилиту conntrack (пакет conntrack-tools).

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

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

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

Ещё раз говорю: я не имею оснований утверждать, что это борьба именно с VPN. Это может быть эхо войны с ддосерами или подобным говном. Просто поступили по логике: дубовое решение на коленке слепили, ддосеров победили, 99% абонентов не повредили, ну и отлично — а 1% гиков пусть вертится, как хочет.
Провайдера называть не хочу, чтобы не привлекать его внимание. А то, не ровен час, ещё какую пакость придумают.
Ну что за ребячество? Назовите провайдера, и другие люди будут осведомлены о проблемах с ним. Вы вообще писали провайдеру о проблеме?
Я использую IPsec настолько же часто, насколько OpenVPN — мой телефон поддерживает только его, и в Windows и OS X поддержка встроена в ОС тоже.
Писать — не писал, но в техподдержку звонил, и даже со второй линией общался по этому поводу.

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

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

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

У меня был случай с украинским провайдером — интернет работал чрезвычайно медленно, с перебоями (все протоколы), пока использовал VPN. Не сразу разобрался, в чем было дело. Думал, просто провайдер глючит.
И что? Разобрались с провайдером? Он действительно фильтровал трафик (отрубая полностью или снижая пропускную способность) на транспортном уровне, нагружая этим своё оборудование?
Да, разобрался. Как только перестал пользоваться VPN — все заработало.
Классные провайдеры. Это прям классика нашего постсовкового бизнеса — пообещать "до 50 Мбит/с", а потом делать всё возможное не для того чтобы обеспечить ему эти 50 Мбит/с, а для того чтобы этих самых 50 Мбит/с потребитель не смог достичь никогда.
Увы, сменить не на что. Единственный альтернативный для меня провайдер использует PPPoE, то есть будет ещё один потенциальный источник глюков в виде дополнительной инкапсуляции и необходимости дозвона. А сейчас ухищрений никаких, воткнул витуху — интернет пошёл, и хотя бы за это спасибо.
Фильтрация UDP — это, скорее всего, блокировщик DDoS/левых пакетов из интернета (и, возможно, оборзевших торрентов).
Если вам ещё интересно, попробуйте TCP, на каких-нибудь попсовых портах (20, 21, 22, 80, 443). Или просто ниже 1024 (диапазон системных сервисов) или выше 49152 (диапазон динамически открываемых соединений). Мне кажется, на это не будет реакции. Не буду рекомендовать TCP для продакшена, с ним может быть чуть больше задержка.

Вы знаете, сервер в принципе можно оставить слушать весь диапазон.
И у вас интересный механизм генерации порта. Не пробовали что-нибудь попроще, например port++? :) А номер порта хранить на гитхабе.
С TCP скорость ниже плинтуса. Связано это с тем, что при туннелировании TCP через TCP механизмы гарантирования доставки внутреннего и внешнего слоёв TCP устраивают между собой цепную реакцию тормозов. Об этом сказано прямо на сайте OpenVPN. И да, я такой вариант пробовал, и действительно лагает ужасно.
Неправда, вы, видимо, что-то не так настроили. Снижение скорости обычно не сильно значительное, по крайней мере, не такое, чтобы вообще от TCP отказаться.
+1 проблемы возникают только при передаче чего-нить типа RTP, когда пакеты начинают вставать в очередь вместо того, чтобы выкидываться. TCP подключения через TCP OpenVPN работают нормально.
Можно ещё кооперироваться с другими такими же любителями своего VPN на VPS, и, в этом случае, ещё и IP менять по заданной кооперативной программе. Правда, это потребует ещё и учитывать трафик каждого участника такого кооператива (на всякий пожарный), но это не шибко сложная задача для коллективного творчества.
Эдакое товарищество VPN-VPSосоводов-любителей.
Я бы для начала просто перенес порт на tcp 443 и посмотрел бы что из этого вышло.
А вообще нафиг такого провайдера, который впны банит.
А целостность полученного файла как-то контролируется?
HTTPS-сертификат гитхаба.
Я не про подлог, а про повреждения при передаче.
CRC в TCP пакетах
Качался файл, соединение упало, в файле мусор. Могу еще картинками нарисовать.
Т.е. у вас просто кусок файла.
Файл такого размера влезет в один TCP-пакет. Следовательно, или скачалось, или нет.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.