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

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

Отличный сервис. Большое вам спасибо за него. Не хотите ли вы поделиться им с сообществом, раскрыв исходный код, чтобы каждый желающий мог на своих ресурсах поднять такой же? Это бы автоматом решило вопрос с масштабированием. Думаю, найдется много людей (и я в том числе), который подержат этот проект на том же гитхабе, помогая со сборками, багфиксами и прочими радостями opensource)

По-моему, у нас с вами уже был разговор об этом года два назад. Мне абсолютно не жалко поделиться решением, беда только в том, что делиться-то по сути нечем.

«Под капотом» у сервиса ровно то самое решение, которое было подробно описано в самой первой статье, на которую здесь есть линк. Это же решение может повторить на своей площадке любой желающий, просто пошагово выполняя описание.

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

Так что делиться тут нечем, по сути. Ну не кодом же лендинга с бесплатным темплейтом.
Предполагаю, что реестр как источник IP-префиксов для обхода блокировок исчерпает себя в начале-середине 2022 года

откуда взалась эта дата середина 2022 года? Вы считаете что блокировать через год начнут в тихую, не сообщая нам какой IP заблокировали?

Это, конечно, моя собственная оценка, не претендующая на истину. Но из чего я исхожу:
  1. государство не обязано сообщать «нам», какие IP-адреса заблокированы. Полный реестр — информация ограниченного доступа и существует постольку, поскольку операторы связи пока что обязаны обеспечивать блокировку и им для этого нужна информация;
  2. блокировка на операторах в целом неуспешна — большинство операторов строят системы блокировки формально, чтобы не попасть под штрафы. Контролирующие агенты («Ревизоры») большинство ставит в песочницы, чтобы уменьшить вероятность проблем, а пользователи сети продолжают иметь доступ как минимум к части заблокированных ресурсов;
  3. во многом именно по этой причине была придумана система ТСПУ, официальные поводы внедрения которых смехотворны и схема включения их не соответствует декларируемым целям. Но при этом законом 90-ФЗ прямо прописывается, что оператор связи, на сети которого ресурс блокируется с использованием ТСПУ, не обязан самостоятельно блокировать доступ к этому ресурсу;
  4. «замедление Твиттера» было первым массовым тестированием ТСПУ в продакшне и декларированное замедление показало текущее проникновение ТСПУ — 100% у мобильных операторов и 50% на фиксированных (по числу абонентов);
  5. расстановка ТСПУ продолжается, при этом есть второй тренд на поглощение мелких операторов (где в основном ТСПУ еще отсутствуют) крупными (где ТСПУ установлены);
  6. предполагаю, что к началу-середине 2022 оба этих тренда приведут к тому, что проникновение ТСПУ будет близко к 100% и участие операторов в блокировках более требоваться не будет.


Вот приблизительно такая у меня логика.

Мало того, тенденция укрупнения операторов нацелена на то, что на рынке фиксированного ШПД останется фактически один единственный оператор («угадайте кто»), и покупку Ростелекомом ЭР-Телекома я прогнозирую не позднее 2024 года, но может и в 2023 успеют.
Ein Reich, ein Führer, ein Internetdienstanbieter.

Поздравляю, первая часть вашего предсказания исполнилась. В списке выгрузки нет, например, твиттера, фейсбука или инстаграма.
Ждём вторую часть.

В выгрузку добавили AS фейсбука и твиттера вручную, но там печаль в том, что у фейсбука трафик размазан по CDN на чужих адресах. И, например, весь RETN ради этого отправлять в выгрузку было бы как-то неправильно.

Если кто-нибудь знает для фейсбука сервис, аналогичный https://www.gstatic.com/ipranges/goog.json - поделитесь ссылками.

В BGP есть поддержка flow-spec, кстати. Там можно обрабатывать отдельные порты отдельных протоколов по специальным правилам. В принципе, это предназначно для борьбы с DoS-атаками; и на мой взгляд действия РКН являются Denial-of-Service атакой чистой воды (хоть и government sponsored), так что flow spec тут строго по назначению.

Я пока не очень представляю, как использовать флоуспек в этом кейсе. Смысл флоуспека в том, чтобы передать пирам информацию о характеристиках (3-4 уровень модели) трафика, который требует специальной обработки (чаще всего дропа, но может быть и полисинга, например), чтобы этот трафик не долетал до анонсера. При этом по факту операторы между собой крайне неохотно включают флоуспек на EBGP, поскольку это потенциально дает возможность соседу сломать вам флоу при ошибке конфигурации.
А в нашем кейсе — не очень представляю, куда мы его прикрутим. Опишите подробнее мысль?

Если вы РКН анонсите на BGP, то имеет смысл так же анонсить не просто IP-адреса, а более точное указание того, что РКН блочит. Вместо списка адресов — список портов, которые надо в VPN заворачивать. Флоу-спек — это не только "блочить", но и специально маршрутизировать.

Так вряд ли кому-то нужна специфика «давайте 80/tcp завернем в туннель, а 23/tcp не будем». Поскольку оператор чаще всего блокирует доступ к ресурсу (большинство из которых в реестре уже https) по L3.
Да и RouterOS 6.*, насколько я в курсе, flowspec не поддерживает.

тогда я не понимаю причин грусти на тему "ломают на L7, а чиним на L3". Если ломают на L3, то и чинить надо тоже на L3.

Давайте я попробую объяснить.

Реестр по сути — это (для случая блокировки к странице или к сайту, поскольку для записей блокировки IP или подсети всё очевидно) совокупность L7-записей (URL), к которым в качестве дополнительной информации Роскомнадзор прикручивает записи L3 (IP). При этом контролируется фильтрация устройствами «Ревизор», работающими также на L7, т.е. имитирующими пользователя.

Занесенные в реестр записи L3 не отличаются достоверностью. Даже если не обращать внимания на леность и ошибки сотрудников, заполняющих реестр, есть проблема с множественными IP-адресами ресурсов — например, round robin записи в DNS или использование географически распределенных CDN/DDoS protection решений. Т.е. у вас конкретный ресурс может быть доступен совершенно не на том IP, на котором он доступен у меня и у Роскомнадзора.

Поскольку операторам штрафов не хочется, они вынуждены каким-то образом решать эту проблему. Одним из путей является получение L3-информации для фильтрации непосредственно из L7-записей на фильтре. Таким образом, фильтры L3 у операторов отличаются (обычно в сторону расширения) от набора адресов в реестре и, к сожалению, с моей стороны нет технического пути определить, какие именно L3-адреса входят в список фильтрации у каждого из провайдеров РФ.
Впрочем, есть некоторая часть фильтров, работающая на анализе SNI и являющаяся таким образом true L7, но процент с внедрением ESNI/ECH TLS 1.3 неуклонно снижается и фильтрация возвращается к грубому L3.

Так что разница существует из-за разного отображения L7 в L3 в реестре и у операторов связи.

Ага. Ясно. Т.е. есть "правильный" и "работающие" варианты.


Я бы их так и отдавал. Два BGP-фида, один из них — "правильный" (какие сказали адреса, такие и фиксим), второй "работающий", который пихает в маршруты всё, что только придумается роботу по аналогии с провайдерскими.

Список IP после операторского резолвинга на сайте есть, но в BGP его нет, потому что если его не суммировать, он будет чересчур большим (он все-таки по /32), а если суммировать по /24, как отдаваемый сейчас, то там будет треть интернета.
Ну и опять же, это резолвинг одного конкретного оператора связи и в силу вышеописанных причин он будет достаточно хорош для клиентов этого оператора и существенно хуже для всех остальных.

… Кстати, если мы знаем про выкрутасы конкретных операторов, то им можно отдавать кастомизированный фид. В нормальном виде это через AS-path само случается, но у конечных пользователей нет представления о своём AS-path, так что делать по провайдерскому диапазону...

Идея хорошая, но я пока не знаю, как брать информацию о выкрутасах конкретных операторов.

Т.е. в принципе можно было бы запилить клиента, которого надо запускать со стороны пользователя, резолвить все домены по листу и выгружать результат в BGP, но тогда и BGP логичнее с этого же клиента забирать. Такое софтовое решение реализовать не очень сложно, но нужно быть программистом, а я — не :)
настраиваю BGP на cisco:
router bgp 64999
synchronization
bgp router-id 000.00.00.00
bgp log-neighbor-changes
bgp bestpath aigp ignore
neighbor 163.172.210.8 remote-as 65432
neighbor 163.172.210.8 ebgp-multihop 250
neighbor 163.172.210.8 disable-connected-check
neighbor 163.172.210.8 update-source GigabitEthernet0/0
neighbor 163.172.210.8 timers 60 240 240
neighbor 163.172.210.8 route-map BGP_NEXT_HOP in

Чтобы я не делал получаю ничего:
hq-gw-01(config-router)#do sh ip bgp summa
BGP router identifier 000.00.00.00, local AS number 64999
BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
163.172.210.8 4 65432 0 0 1 0 0 never Idle
Так вообще должно работать? Буду благодарен, если всевидящий All ткнет пальцем.
Сильно смущает «BGP router identifier 000.00.00.00» в выводе, ощущение, что BGP-сервис лежит. У вас какая модель кошки?

При этом пинг с сервиса до вашего адреса, указанного в Router ID, проходит, так что сослаться на отсутствие маршрута не получится. Может быть, у вас ACL на внешнем интерфейсе блокирует трафик 179/tcp?
Cisco 1941, id я убрал чтобы ip не палить ) ACL на внешнем GI нету — если только предположить что провайдер блокирует 179

Ой наврал acl in есть но такой:
10 deny ip 37.49.230.0 0.0.0.255 any log (176 matches)
20 deny udp 37.49.230.0 0.0.0.255 any log
30 deny udp any host 185.60.44.99 eq domain (663 matches)
40 deny udp any host 185.60.44.99 eq 5353 (167 matches)
50 deny tcp any host 185.60.44.99 eq domain (116 matches)
60 permit ip any any (563453978 matches)

А сам Gi:

interface GigabitEthernet0/0
description ISP-GORKOM
ip address dhcp
ip access-group ACL-GLOBAL-IN in
no ip unreachables
no ip proxy-arp
ip accounting output-packets
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip nat outside
ip virtual-reassembly in
ip route-cache same-interface
ip route-cache policy
load-interval 30
duplex auto
speed auto
no cdp enable
crypto map MAP-VPN-HQ

Возможно и провайдер. Тогда вам просто надо прописать статикой маршрут до сервера через ваш VPN-туннель, где уже ничего не должно его блокировать.
Разобрался:
Во первых Маршрут по умолчанию для соседей(по белому ип) не работает. нужно обязательно прописывать статический маршрут руками.

Во вторых кошка на столько офигела от нагрузки — что до сих пор (уже 5-7 минут) едва дышит
CPU utilization for five seconds: 99%/11%; one minute: 99%; five minutes: 93%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
180 561000 6243 89860 57.52% 58.91% 58.04% 0 BGP Router
155 128348 5401 23763 27.72% 25.22% 18.88% 0 BGP Scheduler

Upd. З.Ы. Во втором пункте была виновата команда debug ip bgp )))
НЛО прилетело и опубликовало эту надпись здесь
Как решение per-host и только веба — это гораздо эффективнее, чем по BGP. Еще более эффективно будет использовать список доменов, который из того же реестра можно либо парсить самостоятельно, либо подтягивать с антифильтра. На сайте есть просто список доменов, а есть он же в формате Switchy, понимаемом SwitchyOmega напрямую. Ссылку на второй список можно добавить в поле Rule List URL в настройках auto switch плагина — и теоретически всё будет работать, автоматически обновляться и никаких других действий для обхода не требуется.
«Теоретически» потому, что в последнее время в списке появилось что-то, что роняет мне плагин на макбуке (а в windows не роняет). Ну и еще один нюанс есть — в списке url есть в частности youtube, это немного затрудняет пользование :)

Вообще, конечно, в списке 90% записей — мусор, никому даром не нужный. Вариант с BGP появился для решения проблем, которые РКН создал бизнесу, начав блокировать Телеграм крупными IP-префиксами, типа /10, что накрыло AWS и прочие полезные сервисы, сами по себе в реестре не находящиеся.

Для текущей более-менее спокойной ситуации вполне достаточно SwitchyOmega и создаваемых вручную правил в нем, благо их можно одним кликом добавлять. Попытались зайти на нужный сайт, увидели попытку переадресации на страницу блокировки — кликнули мышью и пошли через прокси.
НЛО прилетело и опубликовало эту надпись здесь
В целом согласен, но про CDN — у SwitchyOmega очень удобно сразу показывается список failed resources на загруженной странице и, опять же, одной кнопкой для всех этих ресурсов можно создать правила для ухода в прокси.

А про то, что провайдер блочит по IP — тут есть нюансы, я вот тут попробовал раскрыть логику. Так что доменные имена в целом писать в список для прокси надежнее.
НЛО прилетело и опубликовало эту надпись здесь

Кстати, а чем вы держите bgp? bird? exa?

В первой статье подробно описано — bird. Разве что тогда это был 1.6, а сейчас 2.0.7.

Exa крайне медленно всасывает список префиксов из файла. Когда их там было около 2 миллионов — этот процесс занимал более часа, при том, что список лежал на рамдиске.

Мы используем process, и, вроде, получается быстрее.

Мне такой продукт не попадался, и немудрено — название прямо идеально подходит для того, чтобы его никто никогда не нагуглил :) Вообще не представляю, как сформулировать поисковый запрос, чтобы гугл выдал нужный сайт.
Поделитесь ссылкой, плз, интересно.

process — это название опции exa. Не из файла читать, а кормить из stdout'а дочернего процесса. https://github.com/Exa-Networks/exabgp/wiki/Controlling-ExaBGP-:-possible-options-for-process


Хотя, если у меня когда-то расправятся rust-руки, быстрый bgp-из-файла будет одним из пунктов в моём списке добра.


ЗЫ bird мы тоже юзаем, но для других целей.

А, ну насколько я помню, именно это и пробовал, но добиться высокой скорости не удалось.
У вас какой объем префиксов и за какое время залетает, не засекали?

full view, меньше 10 минут. Большей частью ограничена производительностью принимающих железок. Параллельность достигается несколькими экзами.

Ну да, тут еще вопрос в том, что у меня это работает на бюджетном атоме. Понятно, что на 6250 префиксы всасываться будут сильно шустрее.

Вот на удивление bird справлялся с тем же набором префиксов более чем в 2 раза быстрее.

bird — C, exa — python. Кстати, отключение логов на exa ускоряет процесс ощутимо.

Можно попросить поделиться конфигом для bird 2?
У меня настроено по второй статье и всё работает, но хочу попробовать перейти на bird 2.
Он синтаксически мало чем отличается, кроме того, что в protocol команды стали выделяться в группы по протоколам. Т.е. если раньше было
protocol kernel {
         import none;
         export none;
}

то теперь стало
protocol kernel {
   ipv4 { import none; export none; };
}
С таким конфигом
log syslog all;
router id 192.168.42.1;

protocol kernel {
	scan time 20;
	ipv4 {
		import none;
		export none; 
		};
	}

protocol device {
	scan time 60;
}

protocol static static_bgp {
	ipv4 {
		include "subnet.txt";
		include "ip.txt";
		};
}

protocol bgp OurRouter {
	ipv4 {
		import none;
		export where proto = "static_bgp";
		};
	description "Our Router";
	neighbor 192.168.42.10 as 64999;
	next hop self;
	local as 64999;
	source address 192.168.42.1;
	passive off;
}


Ошибка /etc/bird/subnet.txt:1:1 syntax error, unexpected ROUTE
В subnet.txt вроде бы все правильно, с bird предыдущей версии всё работало, скорее всего в конфиге что-то неправильно.
Вероятно это потому, что в bird2 поменяли ключевые слова в route — теперь вместо reject он ждет unreachable.
Так что в скрипте makebgp надо поменять reject на unreachable в двух местах.
Спасибо за помощь, всё заработало.

На всякий случай финальный конфиг, может быть кому-нибудь пригодится:
log syslog all;

router id 192.168.42.1;

protocol kernel {
	scan time 60;
	ipv4 {
		import none;
		export none;
	};
}

protocol device {
	scan time 60;
}

protocol static {
	ipv4;
	include "subnet.txt";
	include "ip.txt";
}

protocol bgp {
	local 192.168.42.1 as 64999;
	neighbor 192.168.42.10 as 64999;
	passive off;
	ipv4 {
		import none;
		export all;
		next hop self;
		};
}
Добрый день!
Во-первых, спасибо за ваш сервис. Во-вторых — а когда сможете по BGP отдавать разные фиды, а не один дефолтный? (там довольно большая агрегация получается). Ответ на вопрос получен после внимательного прочтения статьи, спасибо! ;)
И кстати, раз у у вас bird, не сталкивались с тем, что при перезагрузке файла с маршрутами сессия у клиентов зависает и отваливается? (хотя кроме как на микроте я это не проверял — возможно это его косяк)
Во-первых, пожалуйста.
Во-вторых, отваливание сессий — как раз следствие больших размеров файла — в процессе чтения однопоточный бёрд замирает.
Поиграйте с ускорением чтения (например, с рамдиска), включением на берде graceful restart. Можно разделить на фронт и бэк (между фронтом и бэком сделать очень длинные таймауты, в бэк подсасывать файл, а с фронта коннектить клиента).
Но в целом для одного-двух клиентов вполне достаточно просто раскрутить Hold таймер куда-нибудь в небеса (синхронно с обеих сторон).

Здравствуйте, спасибо за статью! Вы ещё не экспериментировали с ROSv7? Я делал рабочую конфигурацию для третьей беты, но в четвёртой они ещё раз поменяли routing filters — https://help.mikrotik.com/docs/display/ROS/ROSv7+Basic+Routing+Examples#ROSv7BasicRoutingExamples-RoutingFilters, вообще не понимаю, как этим сделать тоже самое, что сделано в статье.

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

Т.е. я бы (чисто из головы) из
/routing filter add action=accept chain=dynamic-in protocol=bgp comment="Set nexthop" set-in-nexthop=172.30.1.1

сформулировал что-то типа

/routing/filter/rule
add chain=dynamic-in rule={
  if true then={
    ip-value set=bgp-next-hop<assign>172.30.1.1;
    action accept;
  }
}

Но это исключительно из логики построения, сами ключевые слова надо в командной строке смотреть. Если когда-нибудь доберутся руки до v7 — проверю.

Думаю как то так. (добавилась роль BGP) в нашем случае это ebgp , внешняя

/routing bgp template add name="antifilter" ignore-as-path-len=yes routing-table=main as=64512 multihop=yes hold-time=4m keepalive-time=1m input.filter=bgp_in

/routing bgp connection add name="antifilter_bgp" remote.address=163.172.210.8/32 local.address=---впн адрес локальный ваш--- router-id=ваш ип роутера templates=antifilter

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

РКН вообще к списку IP относится спустя рукава и пишет туда достаточно часто всякую фигню. Увы, пока другого источника нет.

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

После обновления с 6.49.3 на 7.1.3 немножко всё сломалось.

Маршруты по BGP получались, фильтр отрабатывал, но трафик шел напрямую.

В новой версии фильтр преобразовался в такую конструкцию:

/routing/filter/rule> print
Flags: X - disabled, I - inactive
0 ;;; Set nexthop to VPN
chain=bgp_in rule="set gw-interface moy-vpn; accept;"

В итоге маршруту ставился gateway не vpn, а ether1 (обычный интернет).

Погуглил, поменял gw-interface на просто gw и всё заработало.

"set gw moy-vpn; accept;"

Может я чего не понял, но при установке "set gw moy-vpn; accept;" у меня отваливается wireguard. А как повесить next-hop я так и не понял(( RoS 7.1.3

попробуйте вписать название впн интерфейса, а не IP

Конфиг для микротика с 7й прошивкой:

/routing bgp template
add as="ВАША ВЫДУМАННАЯ AS БЕЗ СКОБОК" disabled=no hold-time=4m input.filter=bgp_in .ignore-as-path-len=yes keepalive-time=1m multihop=yes name=antifilter routing-table=main

/routing bgp connection
add disabled=no hold-time=4m input.filter=bgp_in .ignore-as-path-len=yes keepalive-time=1m local.address= "ВАШ ВНУТРЕННИЙ ИП БЕЗ СКОБОК" .role=ebgp multihop=yes name=antifilter_bgp remote.address=45.154.73.71/32 .as=65432 router-id="ВАШ ВНЕШНИЙ ИП БЕЗ СКОБОК" routing-table=main templates=antifilter

/routing filter rule
add chain=bgp_in disabled=no rule="set gw *9; accept;" <<<===Вот тут по поводу *9 я не уверен. У емня вместо *9 название VPN интерфейса, но в конфиге именно так.

Пытаюсь нагуглить, как скормить маршруты роутеру Asus на прошивке merlin.

У кого-нибудь был такой опыт?

Теоретически туда можно bird поставить через entware, но его ещё настроить надо как-то.

Или, например, мой роутер коннектится через openvpn к VPS, который ему может скормить маршруты(ещё не факт, что роутер их съест правильно) + чтобы их обновить, это придётся переподключится по vpn.

bird сам по себе настраивается несложно (выше по тексту есть примеры конфигов), если он у вас заработает в merlin. Там есть какие-то тонкости с тем, чтобы он в принципе поднялся и начал слушать сеть, и конкретно эти тонкости лучше обсудить с пользователями этой фирмвари (я был, но очень давно).

Есть еще некоторые подозрения, что асусу может не хватить процессора или памяти, всё-таки bgp - достаточно ресурсоемкий протокол.

В целом в текущей ситуации, к сожалению, обход блокировок РКН у большинства уже перестал быть основной целью наличия VPN, поэтому и сервис в виде динамически меняющегося списка IP стал менее полезным. Для абсолютного большинства пользователей самым подходящим сейчас считаю прописать через туннель "всё, кроме РФ" (т.е. держать список российских IP статическими маршрутами в оператора, а в VPN отправлять дефолт) и отдельно корректировать то, что при этом через VPN работает хуже.

У меня Asus RT-AX86U достаточно мощный, даже не знаю, что ещё есть более мощное в этом сегменте.

Короче, я настроил в принципе. За основу взял настройку для keenetic - https://keenetic-gi.ga/2019/01/22/bgp_routing.html

Всё тоже самое: ставится entware, потом bird, который слушает маршруты через VPN с удаленного VPS.

Единственное, пока не нашёл, как сделать, чтобы после поднятия OpenVPN запускался скрипт добавления маршрута и при этом всё работало(если добавить в конфиг openvpn вызов скрипта up/down, то почему-то вообще ничего не работает). Для keenetic там скрипты можно положить в /opt/etc/ndm/, а в асусе такого нету. Но в целом некритично, т.к. роутер практически не перезагружается и на крайняк можно пока что по ssh зайти и запустить руками. Будет время ещё поковыряю, плюс нужно ещё будет зону .lib подключить, пока тоже не было времени разобраться как.

А почему обход блокировок перестал быть основной целью? Весь зарубежный трафик гонять через VPN не хочется, особенно контент. Просто заметно медленней работает.

Весь зарубежный трафик гонять через VPN не хочется, особенно контент. Просто заметно медленней работает.

работаю в таком режиме с августа, vps в nl, вообще никакой разницы не замечаю.
разве что ютуб нидерландскую рекламу показывает.

Я пробовал разные vps и я разницу вижу, особенно во всяком телеграме, ютубе, там где загрузка контента.

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

ну не знаю, вот только что снял:
https://www.speedtest.net/result/14165298599
вам 100+ мегабит недостаточно для ютуба?
и по задержкам: de facto весь зарубежный трафик идёт через европу, сама европа не такая уж и большая, так что в случае расположения vps с vpn в хорошем датацентре задержка увеличится не так уж и сильно.

Если на VPS канал +- такой же как у тебя дома, то даже чисто теоретически уже половину канала ты потеряешь.

Ну и, видимо, не вытягивает VPS OpenVPN что ли(скорость через VPN ниже в 8-10 раз):

Из консоли VPS:
speedtest --server 5252
Retrieving speedtest.net configuration...
Testing from Host Sailor Ltd (xxx)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by signetbreedband (Arnhem) [91.51 km]: 7.301 ms
Testing download speed................................................................................
Download: 675.43 Mbit/s
Testing upload speed......................................................................................................
Upload: 416.29 Mbit/s

Из дома через OpenVPN через VPS:
$ speedtest --server 5252
Retrieving speedtest.net configuration...
Testing from Host Sailor Ltd (xxxx)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by signetbreedband (Arnhem) [91.51 km]: 191.321 ms
Testing download speed................................................................................
Download: 50.98 Mbit/s
Testing upload speed......................................................................................................
Upload: 51.82 Mbit/s

Из дома без VPN:
$ speedtest --server 6827
Retrieving speedtest.net configuration...
Testing from Beeline Home (yyyy)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by MGTS (Moscow) [0.38 km]: 13.348 ms
Testing download speed................................................................................
Download: 464.92 Mbit/s
Testing upload speed......................................................................................................
Upload: 461.67 Mbit/s

Тариф за 7 баксов в месяц вот такой:

SEAMAN

  • RAM 1GB

  • VSwap 1GB

  • RAID10 storage 30 GB HDD

  • NL Processor E5-2620 v3 & E5-2620 v4 & X5650 & Silver 4108

  • RO Processor E5-2620 v3

  • Cores 4

  • IPV4 Addresse(s) 1

  • IPV6 Addresse(s) /64

  • Bandwidth 1TB

  • Network Speed 1Gbit

  • RO DDoS protection 20Gbps

  • NL DBC/DBA Protection Optional

  • NL GreenDatacenter DDOS Protection 20Gbps

  • Control panel SolusVM

  • Location Netherlands/Romania

Подумываю, чтобы пустить трафик без шифрования как-то.

На contabo за те же деньги был VPS покруче и в плане проца и памяти вроде 8Гб было и там ситуация была получше, конечно, но всё равно скорость ощутимо ниже.

Видимо, шифрование сжирает весь процессор, хотя по мониторингу этого не видно.

Если на VPS канал +- такой же как у тебя дома, то даже чисто теоретически уже половину канала ты потеряешь.

нет, конечно же. если всё нормально работает, то в скорости фактически не теряешь, немного теряешь в latency (и из-за этого tcp-сессии будут разгоняться до максимальной скорости чуть дольше)


Подумываю, чтобы пустить трафик без шифрования как-то.

тест выше был сделан через wireguard, но и через openvpn 100+ получается.


NL Processor E5-2620 v3 & E5-2620 v4 & X5650 & Silver 4108

x5650? погуглите какого это года процессор )
есть подозрение, что у этого провайдера на всём экономят, линки/процы перегружены.

Ну мне надо было на что-то срочно перейти за несколько дней, когда контабо предупредил, чтобы разорвет контракт. И это не первый вариант, кстати, первый совсем плохой был на OpenVZ, но совсем дешевый зато)

А какой VPS есть кошерный, только чтобы криптовалюту принимал или любым другим способом платежи из России? Вы каким пользуетесь для VPS?

Вообще есть подозрение, что проблема в настройке OpenVPN, я поковырял пару часов, отключил шифрование, сжатие, попробовал разные сетевые настройки. Самое смешное, что скорость только ниже стала. Притом скорость на UDP раза в 2 меньше, чем на TCP.

Надо будет это дело доковырять...

А почему обход блокировок перестал быть основной целью? 

Потому что (во всяком случае у меня и многих других) vpn теперь нужен в основном не для доступа до заблокированного РКН контента, а для доступа до заблокированных для России ресурсов. Списка которых в блеклисте РКН, разумеется, нет.

Кстати, да. Очень много ресурсов в т.ч. образовательных тупо заблокировало российские ip адреса. Ну значит буду по старинке для них включать VPN, который весь трафик заворачивает в туннель.

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

Публикации

Истории