тоже не совсем понятно, что нужно сделать, чтобы пускать этот домен через проксю
тут
Контейнер VPN АнтиЗапрета для установки на собственный сервер - antizapret.prostovpn.org / АнтиЗапрет на собственном сервере (self-hosted) - NTC
я так понимаю схема для домена третьего уровня, а
osxapps.itunes.apple.com
домен четвёртого
как было исправлено
?
Если вам нужно решить проблему с apple.com, то его не нужно для этого добавлять в список проксирования.
См. сообщение выше.
Проблема в том, что мы хостим DNS сервер в другой стране, что создает большое количество проблем с сайтами, которые используют DNS-based Geo-балансировку (а не anycast, что более логично), то есть такие домены резолвятся на ближайшие IP-адреса к вашему DNS-серверу за границей а не к вам, что может в целом замедлять работу даже незаблокированных сайтов.
Я в итоге пришел к такой конфигурации. В Москве (где я живу) я взял виртуалку и поднял там knot-resolver, который для незаблокированных сайтов форвардит DNS запросы на 1.1.1.1, а для заблокированных сайтов форвардит всё на мой собственный DNS сервер в Финляндию (самая ближайшая локация к Москве с пингом около 16мс), с него уже отдаются фейковые IP-адреса для заблокированных сайтов.
Иными словами нужно резолвить адреса там, где вы будете к ним обращаться.
Сейчас в списке заблокированных больше 400 000 доменов, у Вас knot нормально справляется с маршрутизацией каждого DNS-запроса по такой немаленькой таблице?
Сам эту задачку решаю, но пока что планировал в фоне логи запросов к своему DNS-серверу обрабатывать и корректировать маршруты, т.к. был уверен, что в real time не взлетит.
Работает хорошо, подгрузил через RPZ.
Правда при запуске около 20 секунд лагает)
workers: auto
logging:
level: info
network:
listen:
- interface: wg0@53
cache:
prediction: true
lua:
script: |
policy.add(
policy.rpz(
policy.FLAGS({'NO_EDNS', 'NO_0X20'}),
'/config/domains.rpz',
true
)
)
policy.add(
policy.rpz(
policy.STUB('fd86:ea04:1116::1'),
'/config/domains.rpz',
true
)
)
policy.add(policy.all(policy.STUB('1.1.1.1')))
Я по итогу сделал свой antizapret на wireguard и NAT64 (Jool в kernel mode), а мой DNS64 сервер резолвит Embedded IPv4 in IPv6 адреса вместо фейковых IPv4, таким образом не нужно поддерживать маппинг fake ip → real ip в iptables, архитектура получилась stateless и очень прозрачной и эффективной.
Можно даже маршрутизирующий knot-resolver разместить на своём домашнем роутере для отказоустойчивости и околонулевого latency.
Единственный минус такой схемы, вам нужны IPv6 адреса на ваших устройствах в вашей сети. Но если публичных IPv6 адресов нет то можно заанонсить ULA IPv6-префикс через RA.
Спасибо за подробные пояснения, но, честно говоря, не понял, зачем Вам вообще фейковые адреса и IPv6. Разве не достаточно просто использовать для каждого доменного имени ресолвер в той стране, через которую мы предполагаем маршрутизировать трафик к соотв. серверу?
Или Вы таким образом решаете не только проблему, когда для разных геолокаций отдаются разные адреса, но и проблему, когда в рамках одной геолокации рандомно отдаются разные адреса из некоего пула?
Под фейковыми адресами я подразумевал то, что отдает antizapret dns (10.241.x.x).
Долго задавался вопросом как переделать antizapret на wireguard и при этом решить проблему резолва адресов для НЕзаблокированных сайтов там, где я нахожусь, в итоге пришел к такому архитектурно простому решению дабы не заморачиваться со скриптами, которые поддерживают состояние iptables 
Разве не достаточно просто использовать для каждого доменного имени ресолвер в той стране, через которую мы предполагаем маршрутизировать трафик к соотв. серверу?
Если я правильно понял вы предполагаете использовать, например, Yandex DNS в качестве резолвера, который будет использоваться в антизапрете, (если мы предполагаем что антизапрет находится в другой стране). То есть Antizapret будет обращаться к DNS серверу яндекса в Москве.
В таком случае будет достаточно высокий latency на резолв для ЛЮБЫХ сайтов. Ваш компьютер в Москве будет обращаться к антизапрету в Финляндии (допустим), а он в свою очередь будет посылать запрос к DNS серверу яндекса в Москве, затем получать ответ и возвращать вам.
Гораздо лучше будет если DNS запросы не будут улетать за пределы Москвы и будут оставаться в пределах пары миллисекунд.
Сорри, я в эту тему подключился исключительно после Вашего комментария про распределение DNS-запросов, что для меня тоже актуально. Продукт от antizapret не использую и откуда и зачем в нём берутся фейковые адреса - не знаю 
(P.S. Почитал, понял, хитроумное решение, но очень уж нишевое )
У меня своя VPN-сеть с точками в нескольких странах и маршрутизацией через эти точки по правилам, специфичным для каждой страны (скажем, из России заблокированные IP через Голландию, а из-за пределов России российские IP через Россию и т.п.) Списки префиксов для маршрутизации, в т.ч. путём ресолвинга доменных имён, формирует свой сервер и раздаёт всем остальным узлам сети по BGP в отдельных community. Все пользователи моей сети используют мои DNS-ресолверы (для уменьшения latency и отказоустойчивости у меня их 2 - в России и в Голландии).
И вот тут я сталкиваюсь с аналогичной проблемой - при построении списка маршрутов сервер может получить для доменного имени один IP, а пользователь при обращении по этому имени - другой, к которому правильный маршрут не построен. Я эту проблему планировал решать, написав работающий в фоне парсер логов DNS-ресолвера, который проверяет все запросы на соответствие доменам из списка и обновляет маршруты при появлении для этих доменов новых IP. В этом случае пользователь с первого раза всё равно получит проблему, но хотя бы при повторном обращении (обновлении страницы) через некоторое время нужный маршрут уже успеет появиться. Но вот если можно действительно расикдать и DNS-запросы, сохранив приемлемую производительность ресолвера, то часть проблем (вызванные несоответствием геолокации, а не балансировкой нагрузки) это сняло бы сразу.
По поводу latency DNS я вообще не переживаю. У меня сейчас вообще рекурсивные ресолверы, которые ходят по всей цепочке от корневых серверов, и никакой особой latency это не привносит, затраты времени же только на первый запрос, дальше всё в кэше. Медианное время выполнения рекурсивного запроса для российского ресолвера около 80 мс, для европейского - около 30 мс. Переход от собственных ресолверов к сторонним, где бы они ни находились, эти цифры только улучшит. И мой компьютер в Москве не ходит к иностранному серверу без нужды, как и иностранный к российскому.
благодарю, прочитал внимательно, в чём дело
действительно, для osxapps.itunes.apple.com это рабочее решение
ну раз уж задал вопрос про проксирование конкретных доменов четвёртого уровня (мало ли, пригодится), то метод для доменов третьего уровня
Контейнер VPN АнтиЗапрета для установки на собственный сервер - antizapret.prostovpn.org / АнтиЗапрет на собственном сервере (self-hosted) - NTC
вероятно нерабочий
можно этот вопрос осветить?
спасибо
День добрый! А никто не в курсе, у нас могут как-то трекать впны, расположенные в близлежащих странах (конкретно Финляндия), или это админы самого сайта делают такие интересные вещи? Имею впску в Финляндии, на которой крутится контейнер антизапрета, сегодня наткнулся на один сайт из реестра, который при попытке его открыть перекидывает на сайт fsb.ru, в нетворке пролетает NS_BINDING_ABORTED (Firefox); пытался включить “полный” впн (решение через добавление bypass-dhcp в конфиг) - не работает, включаю отдельный впн в браузере на условную Австрию (пробовал несколько разных стран) - работает, включаю на Финляндию - не работает, снова редирект. Или, может, где-то произошло какое-то условное кэширование и меня теперь по геоайпи как-то блочит? С контейнера сайт пингуется, доступ есть.
Ответы HTTP 301, 302, 303, 307 выдаёт веб сервер, настроенный администратором сайта. Фильтрация доступа может осуществлятся например по данным GeoIP, размеру MTU, разнице времени браузера и локации IP.
Я, конечно, немного дилетант в плане сетей и прочего, но в какой момент в этой всей системе вылезает редирект на сайт фсб? Я даже раньше, кажется, такого не видел - обычно при попытке доступа либо заглушка с баннером была про то, что сайт заблокирован, либо относительно недавно начала вылетать PR_CONNECT_RESET_ERROR и никакого редиректа. В моем понимании если идет блок какого-либо вида со стороны сайта, то там будет опять же либо какая-то заглушка (как делают сейчас многие сайты, блокирующие доступ пользователям из РФ), либо редирект на условный гугл, но уж никак не на сайт российского фсб - тем более что без впна я на этот сайт даже не заходил. Пробовал включить Эстонию/Латвию/Литву/Норвегию (что близко географически) - с ними все замечательно открывается, ощущение что “виноват” был именно первый коннект через антизапрет, который по каким-то причинам был где-то задетекчен.
В браузере открываете Web Developer Tools, владку Network и должны увидеть код HTTP редиректа на первом запросе страницы. “Виноват” скорее всего администратор веб сервера, который добавил IP в блок лист.
Что-то я сомневаюсь, что там админ сервера так заморочился. Может, просто Ваш финский VPS по GeoIP бьётся как российский? Такое, вроде, встречалось в отношении площадок, которые наши хостеры арендуют (или в недавнем прошлом арендовали) за рубежом.
Сайт, как оказалось, принадлежит той же компании, что и в этом треде. Проверил этот, симптомы абсолютно такие же - без впна нет коннекта, с финским впном/финской прокси из UrbanVPN (мой хостится на Aeza, прокся на Creanova) 302 + редирект на фсб, с финской проксей hide.me (Hetzner) или с другими странами все работает. Видимо, все-таки владельцы шаманят на своей стороне. Не до конца, правда, понятно, что это за магический геоблок такой, который отработал на два разных хостинга в пределах одной страны и не отработал на третий, ну да ладно.
На мою впску первые два указывают Финляндию, третий по каким-то причинам Швецию (хотя, кажется, когда у меня был рабочий Хецнер, с ним была похожая история - периодически выдавало Германию вместо Финляндии), на втором при этом есть упоминание runexis.ru в качестве домена - единственная зацепка? На урбанвпновской проксе три честных Финляндии.
Не знаю. Вариантов много. Или они берут GeoIP из какого-то другого источника, на котором светится Россия (если там упомянут российский домен - возможно, раньше этот блок IP числился напрямую за российской компанией, а базы GeoIP могут быть древние необновлённые). Или какой-то российский пользователь/бот с VPN у этого же провайдера засветился индивидуально так, что заставил админов соотв. диапазон добавить вручную.
В любом случае, версия, что они как-то детектят именно Антизапрет и добавляют “засветившиеся” адреса в вечный бан, кажется самой маловероятной. Во-первых, не видно со стороны сервера никаких критериев, по которым можно так определять. Во-вторых, Антизапрет - точно не самый популярный способ обхода блокировок для россиян. В-третьих, ну это до какой степени надо упороться
