Доступ к заблокированному сайту

А может просто https://zaborona.help/zaborona-help.ovpn ?

С помощью dnsmasq или ipset-dns формируешь лист ipset, дальше форвардишь все из листа через tor transport. Таким же образом можно и .onion-домены завернуть, если захочется.

dnscrypt-proxy

Спасёт если у провайдера не используется анализ SNI в https. Однако попробовать в любом случае стоит - хуже от этого не будет.

Похоже, что ТС — тот самый, которого я помню с Лафокса, поэтому это Украина, поэтому, какой к чёрту анализ SNI :).

Ну это пока не используется :-)
Если у вас там такие же упор^W упёртые как у нас - всё еще впереди. Хорошо бы конечно, чтобы я был не прав...

В Украине нет нефтедолларового бюджета, пилить особо нечего... Вот ведь повезло ;)

Ага, и я помню, жаль Лафокс уже не тот.
На mail.ru надо попасть. Не знаю, что такое SNI, но DPI (wikipedia.org) мой провайдер похоже таки использует...

Объясните, пожалуйста, по подробнее про списки. Вот айпишники mail.ru:
5.61.16.0/21
5.61.232.0/21
79.137.157.0/24
79.137.183.0/24
94.100.176.0/20
95.163.32.0/19
95.163.248.0/21
128.140.168.0/21
178.22.88.0/21
178.237.16.0/20
185.5.136.0/22
185.16.148.0/22
185.16.244.0/22
188.93.56.0/21
194.186.63.0/24
195.211.20.0/22
195.218.168.0/24
217.20.144.0/20
217.69.128.0/20
178.22.91.0/24
178.22.92.0/23
185.16.244.0/23
195.211.128.0/22
208.87.94.0/24

С nftables всё понятно, добавляем их через запятую в ихнешний set, и потом редиректим куда надо.
Как быть с dnsmasq, как ему скормить этот список для правильного резолва? не могу понять какой должен быть синтаксис, понятно когда один айпишник и много имён, а когда наоборот?

жаль Лафокс уже не тот

Ну, теперь его вообще нет, вообще-то :).

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

https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy

Оно? Похоже, тебе нужно настроить это прозрачное проксирование и завернуть все подсети на виртуальный интерфейс ТОР'а.

Я не очень в теме, на самом деле, как с ТОР'ом лучше сделать. На твоём месте я бы копал в сторону VPN'а. UDP, например, через TOR ты не прогонишь, только TCP.

С DNS так же — у dnsmasq есть conditional forwarding. Так вот, наверное, можно для *.mail.ru сделать форвардинг запосов по TCP на нужный резолвер, а роут к этому резолверу перенаправить через TOR, как по ссылке в предыдущем комментарии.

О conditional forwarding тут: http://pyther.net/2010/12/dns-conditional-forwarding-dnsmasq/

Как вариант, есть ещё способ обхода блокировок.

Гонять UDP на mail.ru? Мне лишь бы логин с паролем не увели при авторизации, всё остальное не актуально.
Прозрачное проксирование, это понятно. Вопрос в том, как делить трафик на основе DNS запросов.
Или уже все DNS запросы отправлять в Tor, а dnsmasq пусть сам формирует свой cache-список?

th3m3, интересная статья, но в ряд ли это будет работать для моего прова, проверить не могу (перестраиваться обратно на iptables нет желания).

Пищу для размышлений подала статья в которой используется связка squid+privoxy+tor, но в ней предполагается в браузере устанавливать использование прокси.

Или можно связку заменить на
nftables->squid->privoxy->tor
дабы убрать необходимость прописывать использование прокси в браузерах?

как делить трафик на основе DNS запросов

Говорю же, conditional routing в dnsmasq. Прописываешь нужную зону, форвардишь её по TCP к какому-нибудь публичному резолверу. Этот трафик заворачиваешь через TOR.

Не-DNS трафик (TCP-only) тоже заворачиваешь через TOR.

В такой схеме нигде прокси прописывать не нужно.

Спасибо, настроил. Теперь DNS запросы на mail.ru резолвятся «лично» dnsmasq через Tor (проверено).
Конфиг /etc/tor/torrc

User tor
Log notice syslog
SocksPort 0
TransPort 9040
DNSPort 9053

table ip filter {
        chain input {
                type filter hook input priority 0; policy drop;
                ct state invalid drop
                ct state established,related accept
                iifname "lo" ip daddr 127.0.0.0/8 accept
                ip protocol icmp accept
                iifname "eth1" accept
        }

        chain output {
                type filter hook output priority 0; policy accept;
        }

        chain forward {
                type filter hook forward priority 0; policy drop;
                iifname "eth1" accept
                oifname "eth1" accept
        }
}

table ip nat {
        chain prerouting {
                type nat hook prerouting priority 0; policy accept;
                ip daddr { 217.69.139.199} tcp dport https redirect to :9040
        }

        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
                oifname "eth0" ip saddr 192.168.10.20 masquerade
        }
}

ip daddr { 94.100.180.199, 217.69.139.199, 94.100.180.202, 217.69.139.202 } tcp dport { 80, 443 } redirect to :9040

Проверил у себя так — работает.

Нет, так тоже не работает :(
В чём же дело...

Поставил для эксперимента sinoptik.ua, добавил счётчик

ip daddr { 212.42.76.150} tcp dport { http, https} counter packets 1 bytes 60 redirect to :9040

Сложно сказать. Вроде, в других цепочках дропаться не должно.

Тор как обычный socks-прокси работает?

Если на шлюзе выставить браузер на использование socks (127.0.0.1:9050), - то работает;
если на клиенте в локалке выставить socks 192.168.10.1:9050 (внутренний адрес шлюза), то нет.
Проблема таки в Tor'е похоже...

Я думаю, тебе в конфиге тора нужно биндиться не просто на порт, а на адрес:порт. Я у себя так делал. Адрес пользуешь тот, который внутренний шлюза.

О! Вот это оно:

TransPort 127.0.0.1:9040
TransPort 192.168.10.1:9040