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

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

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

dnscrypt-proxy

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

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

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

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

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

Объясните, пожалуйста, по подробнее про списки. Вот айпишники 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