Jump to content

Выборочный роутинг через VPN туннель


Recommended Posts

что-то я у себя сломал, прошу помощи. Настроен выборочный обход блокировки по рецепту avn через tor. ipset unblock4-tor и unblock4-tor.dnsmasq создаются, правила в iptables добавляются, tor на dns и транспортном портах слушает. Обход работает для доменов/адресов, занесенных в unblock4-tor.txt, например 2ip.me, но не работает ни для чего в домене onion, включая, например, сайт flibista.onion, для которого в torrc настроен маппинг. Счетчики в iptables при обращении на 2ip.me в соответствующих правилах растут, а для xxxx.onion - тишина. Подскажите, что проверить? Вот, что у меня прописано в torrc:

TransPort 0.0.0.0:9141
TransPort [::]:9141

DNSPort 127.0.0.1:9053
DNSPort [::1]:9053
AutomapHostsOnResolve 1

VirtualAddrNetworkIPv4 127.192.0.0/10
VirtualAddrNetworkIPv6 [fc00::]/10

в dnsmasq.conf:

server=/onion/127.0.0.1#9053
server=/onion/::1#9053

Этот параметр, как я понимаю, в данном случае не требуется, и он закомментирован:

ipset=/onion/unblock4-tor,unblock6-tor

в правилах iptables:

iptables -A PREROUTING -w -t nat -i br0 -p tcp -m set --match-set unblock4-tor dst -j REDIRECT --to-port 9141
iptables -A PREROUTING -w -t nat -i br0 -p udp -m set --match-set unblock4-tor dst -j REDIRECT --to-port 9141

 

Link to comment
Share on other sites

58 минут назад, ale_xb сказал:

что-то я у себя сломал, прошу помощи. Настроен выборочный обход блокировки по рецепту avn через tor. ipset unblock4-tor и unblock4-tor.dnsmasq создаются, правила в iptables добавляются, tor на dns и транспортном портах слушает. Обход работает для доменов/адресов, занесенных в unblock4-tor.txt, например 2ip.me, но не работает ни для чего в домене onion, включая, например, сайт flibista.onion, для которого в torrc настроен маппинг. Счетчики в iptables при обращении на 2ip.me в соответствующих правилах растут, а для xxxx.onion - тишина. Подскажите, что проверить? Вот, что у меня прописано в torrc:

TransPort 0.0.0.0:9141
TransPort [::]:9141

DNSPort 127.0.0.1:9053
DNSPort [::1]:9053
AutomapHostsOnResolve 1

VirtualAddrNetworkIPv4 127.192.0.0/10
VirtualAddrNetworkIPv6 [fc00::]/10

в dnsmasq.conf:

server=/onion/127.0.0.1#9053
server=/onion/::1#9053

Этот параметр, как я понимаю, в данном случае не требуется, и он закомментирован:

ipset=/onion/unblock4-tor,unblock6-tor

в правилах iptables:

iptables -A PREROUTING -w -t nat -i br0 -p tcp -m set --match-set unblock4-tor dst -j REDIRECT --to-port 9141
iptables -A PREROUTING -w -t nat -i br0 -p udp -m set --match-set unblock4-tor dst -j REDIRECT --to-port 9141

 

Сети 127.192. не будут маршрутизироваться.

Edited by avn
Link to comment
Share on other sites

В 20.06.2022 в 21:04, avn сказал:

Сети 127.192. не будут маршрутизироваться.

Черт, а ведь верно! Обход с tor заработал, спасибо!

Теперь следующий шаг: обход через vpn Wireguard. С ПК Windows все работает, с Андроид телефона/планшета - какая-то ерунда творится.  Для некоторых доменов, flibusta.is, например, все работает, для других, rutracker.org, например, - не работает и выскакивает заглушка Ростелеком (мой пров). Трафик, в таблице mangle цепочки PREROUTING почему-то не маркируется, счетчик пакетов/байт в правиле при запросах с телефона/планшета не меняется, потому и пакеты не маршрутизируются в нужной таблице на интерфейс vpn в качестве default. При этом cоответствующий ipset unblock4-vpn и unblock-vpn.dnsmasq наполняются нормально, ведь с ПК, в конце-концов это работает. Использую только ipv4, т.к. вы указали на проблемы маршрутизации маркированного трафика для ipv6. Пробовал включать/выключать fast-nat на роутере и использовать маркировку, как пакетов, так и сессий. Для ПК с Windows - работает в обоих случаях, для телефона/планшета с Android - все те же чудеса. Мысли, где копать уже заканчиваются 😞

UPD: есть смутные подозрения, что Андроид устройства запрашивают (или им отдается) в первую очередь AAAA записи, а для этих адресов обход через vpn не работает и у меня даже не настроен. Т.е. имена, которые разрешаются по DNS только в A записи работают, а те, где есть обе записи или только AAAA - не работают. Если мои подозрения правомерны, посоветуйте что дополнительно проверить или исправить? Тупо убрать ipv6 не хочется, т.к. это нормально работает для tor.

UPD2: Точно, так и есть! Проверил. Имена, для которых есть AAAA записи не работают с Андроид. При этом все без проблем и на Андроид работает для имен с только А записями. Теперь надо подумать, что с этим делать. Делать сортировку по ipset-ам/доп.конфигам dnsmasq в зависимости от полученного ответа dig (есть/нет AAAA в ответе) или что-то проще? Возможно, попробую вернуться к единому списку ublock.txt, а скрипты пусть распихивают ipv4/ipv6 адреса с приоритетом маршрутизации через vpn для ipv4 и только для ipv6 - в tor. Видел, народ еще ip6-in-ipv4 поднимает, но таких костылей, пожалуй, надо избегать в "век повсеместного ipv6" 🤔

Edited by ale_xb
Link to comment
Share on other sites

В 22.06.2022 в 03:02, ale_xb сказал:

Черт, а ведь верно! Обход с tor заработал, спасибо!

Теперь следующий шаг: обход через vpn Wireguard. С ПК Windows все работает, с Андроид телефона/планшета - какая-то ерунда творится.  Для некоторых доменов, flibusta.is, например, все работает, для других, rutracker.org, например, - не работает и выскакивает заглушка Ростелеком (мой пров). Трафик, в таблице mangle цепочки PREROUTING почему-то не маркируется, счетчик пакетов/байт в правиле при запросах с телефона/планшета не меняется, потому и пакеты не маршрутизируются в нужной таблице на интерфейс vpn в качестве default. При этом cоответствующий ipset unblock4-vpn и unblock-vpn.dnsmasq наполняются нормально, ведь с ПК, в конце-концов это работает. Использую только ipv4, т.к. вы указали на проблемы маршрутизации маркированного трафика для ipv6. Пробовал включать/выключать fast-nat на роутере и использовать маркировку, как пакетов, так и сессий. Для ПК с Windows - работает в обоих случаях, для телефона/планшета с Android - все те же чудеса. Мысли, где копать уже заканчиваются 😞

UPD: есть смутные подозрения, что Андроид устройства запрашивают (или им отдается) в первую очередь AAAA записи, а для этих адресов обход через vpn не работает и у меня даже не настроен. Т.е. имена, которые разрешаются по DNS только в A записи работают, а те, где есть обе записи или только AAAA - не работают. Если мои подозрения правомерны, посоветуйте что дополнительно проверить или исправить? Тупо убрать ipv6 не хочется, т.к. это нормально работает для tor.

UPD2: Точно, так и есть! Проверил. Имена, для которых есть AAAA записи не работают с Андроид. При этом все без проблем и на Андроид работает для имен с только А записями. Теперь надо подумать, что с этим делать. Делать сортировку по ipset-ам/доп.конфигам dnsmasq в зависимости от полученного ответа dig (есть/нет AAAA в ответе) или что-то проще? Возможно, попробую вернуться к единому списку ublock.txt, а скрипты пусть распихивают ipv4/ipv6 адреса с приоритетом маршрутизации через vpn для ipv4 и только для ipv6 - в tor. Видел, народ еще ip6-in-ipv4 поднимает, но таких костылей, пожалуй, надо избегать в "век повсеместного ipv6" 🤔

А не проще делить так:

ipset=/fishki.net/unblock4-vpn,unblock6-vpn

ipset=/digikey.com/unblock4-vpn

 

Link to comment
Share on other sites

В 23.06.2022 в 07:50, avn сказал:

А не проще делить так

Если я правильно Вас понял, для этого надо самому отсортировать доменные имена для обхода блокировок по тому, как разрешаются их адреса в ipv4/ipv6 и занести эти имена в тот или иной список вручную? Неудобно же.

Набросал для себя схему работы (с упрощениями/вольностями, конечно) обсуждаемого здесь способа обхода блокировок для лучшего понимания, что и как происходит и провел мини-исследование. Предпосылки: tor умеет пропускать tcp ipv4/ipv6 трафик, vpn - tcp/udp только ipv4 (как указывал здесь avn, из-за недоработок ip rule в Keenetic для ipv6). Красным указаны пути следования пакетов через таблицы netfilter роутера (везде цепочки PREROUTING. Для наглядности можно посмотреть здесь), остальными цветами - последовательность формирования списков разблокировки, ipset-ов, правил netfilter. Бирюзовый - для tor, зеленый - vpn, желтый - ss:image.thumb.png.eb177b08818d0e6c2b282bd21f11324e.png

Если в домашней сети вы используете только ipv4, все изложенное вас не касается, но по умолчанию, на современных домашних сетевых устройствах и ОС включены оба стека, поэтому читаем дальше. В списке для обхода блокировок, могут быть имена, разрешающиеся в ipv4 и ipv6 (например, news.google.com, www.dw.com на рисунке) и могут быть имена, разрешающиеся только в ipv4 (например, www.euronews.com, www.2О19.vоte). Обращение из приложения, скажем, браузера для первого случая может идти в зависимости от приоритета адресов. На современных Андроид системах, как я понимаю, это - ipv6, и такое поведение меняется "с бубном", т.е. является "фичей". На Windows/Linux приоритет меняется сравнительно просто, но обычно этим никто не озадачивается. У меня на двух домашних ПК (Windows 10 и 11) идет обращение приоритетно по ipv4, например. В итоге получаем следующие варианты в зависимости от того, в какой список занесено доменное имя для разблокировки и по какой версии ip идет обращение к ресурсу:

1. Обращение с Андроид (приоритет ipv6, если есть оба адреса):

  • news.google.com (цепочка 0-1-4-5) - ipv6, успешно
  • www.euronews.com (0-...-3-4-5) - ipv4, успешно. Правила 2 в iptables не будет, т.к. оно может быть создано только для unblock-vpn.txt списка.
  • www.dw.com (0-...-4-...) - ipv6, проблема. Не будет подходящего правила 1, т.к. оно здесь может появиться только из списка unblock-tor.txt Пакет пойдет обычным путем через вашего провайдера.
  • www.2019.com (0-2-...-4-6) - ipv4, успешно. Правило 3 создается из списка unblock-tor.vpn, поэтому его здесь не будет.

2. Обращение с Windows (приоритет ipv4, если есть оба адреса):

  • news.google.com (цепочка 0-...-3-4-5) - ipv4, успешно. Правило 2 отсутствует.
  • www.euronews.com (0-...-3-4-5) - ipv4, успешно. Аналогично предыдущему.
  • www.dw.com (0-2-...-4-6) - ipv4, успешно.
  • www.2019.com (0-2-...-4-6) - ipv4, успешно. Аналогично предыдущему.

Если добавить домен dw.com в оба списка, казалось бы, все заработает и на Андроид, т.к. должно быть создано правило 1, но это не так потому, что для dw.com нет записи АAAA:

root@keenetic:/opt/etc$ dig +short AAAA dw.com @localhost

<пусто>

Она есть только для www.dw.com, что рушит логику/ожидания работы данной схемы обхода блокировок:
root@keenetic:/opt/etc$ dig +short AAAA www.dw.com @localhost
www.dw.com.edgekey.net.
e11619.dsce6.akamaiedge.net.
2a02:26f0:9500:7b7::2d63
2a02:26f0:9500:7bc::2d63

Вывод: всё чуть сложнее, чем кажется 😉 и теперь надо бы постараться упростить работу с этим. Буду признателен за замечания и советы по улучшению данного механизма обхода блокировок.

Примечание: Для www.2О19.vоte срабатывает перенаправление на другое доменное имя, поэтому счетчик трафика в "Другие подключения" web-интерфейса Keenetic будет расти только при первом запросе по этому имени, а не при нажатии кнопки "обновить" в браузере. Я сходу просто не нашел подходящий сайт без перенаправления и только с A записью.

UPD: вместо www.2О19.vоte можно проверить изложенное на www.flibusta.is

UPD2: добавил ss без описания вариантов хождения ipv4/ipv6 для него с разных устройств.

Edited by ale_xb
добавил ss
Link to comment
Share on other sites

39 минут назад, ale_xb сказал:

Если я правильно Вас понял, для этого надо самому отсортировать доменные имена для обхода блокировок по тому, как разрешаются их адреса в ipv4/ipv6 и занести эти имена в тот или иной список вручную? Неудобно же.

Набросал для себя схему работы (с упрощениями/вольностями, конечно) обсуждаемого здесь способа обхода блокировок для лучшего понимания, что и как происходит и провел мини-исследование. Предпосылки: tor умеет пропускать tcp/udp ipv4/ipv6 трафик, vpn - tcp/udp только ipv4 (как указывал здесь avn, из-за недоработок ip rule в Keenetic для ipv6). Красным указаны пути следования пакетов через таблицы netfilter роутера (везде цепочки PREROUTING. Для наглядности можно посмотреть здесь), синим - последовательность формирования списков разблокировки, ipset-ов, правил netfilter:image.png.60bbbeae1a9309a9a6fbc3bc7e0638ff.png

Если в домашней сети вы используете только ipv4, все изложенное вас не касается, но по умолчанию, на современных домашних сетевых устройствах и ОС включены оба стека, поэтому читаем дальше. В списке для обхода блокировок, могут быть имена, разрешающиеся в ipv4 и ipv6 (например, news.google.com, www.dw.com на рисунке) и могут быть имена, разрешающиеся только в ipv4 (например, www.euronews.com, www.2019.vote). Обращение из приложения, скажем, браузера для первого случая может идти в зависимости от приоритета адресов. На современных Андроид системах, как я понимаю, это - ipv6, и такое поведение меняется "с бубном", т.е. является "фичей". На Windows/Linux приоритет меняется сравнительно просто, но обычно этим никто не озадачивается. У меня на двух домашних ПК (Windows 10 и 11) идет обращение приоритетно по ipv4, например. В итоге получаем следующие варианты в зависимости от того, в какой список занесено доменное имя для разблокировки и по какой версии ip идет обращение к ресурсу:

1. Обращение с Андроид (приоритет ipv6, если есть оба адреса):

  • news.google.com (цепочка 0-1-4-5) - ipv6, успешно
  • www.euronews.com (0-...-3-4-5) - ipv4, успешно. Правила 2 в iptables не будет, т.к. оно может быть создано только для unblock-vpn.txt списка.
  • www.dw.com (0-...-4-...) - ipv6, проблема. Не будет подходящего правила 1, т.к. оно здесь может появиться только из списка unblock-tor.txt Пакет пойдет обычным путем через вашего провайдера.
  • www.2019.com (0-2-...-4-6) - ipv4, успешно. Правило 3 создается из списка unblock-tor.vpn, поэтому его здесь не будет.

2. Обращение с Windows (приоритет ipv4, если есть оба адреса):

  • news.google.com (цепочка 0-...-3-4-5) - ipv4, успешно. Правило 2 отсутствует.
  • www.euronews.com (0-...-3-4-5) - ipv4, успешно. Аналогично предыдущему.
  • www.dw.com (0-2-...-4-6) - ipv4, успешно.
  • www.2019.com (0-2-...-4-6) - ipv4, успешно. Аналогично предыдущему.

Если добавить домен dw.com в оба списка, казалось бы, все заработает и на Андроид, т.к. должно быть создано правило 1, но это не так потому, что для dw.com нет записи АAAA:

root@keenetic:/opt/etc$ dig +short AAAA dw.com @localhost

<пусто>

Она есть только для www.dw.com, что рушит логику/ожидания работы данной схемы обхода блокировок:
root@keenetic:/opt/etc$ dig +short AAAA www.dw.com @localhost
www.dw.com.edgekey.net.
e11619.dsce6.akamaiedge.net.
2a02:26f0:9500:7b7::2d63
2a02:26f0:9500:7bc::2d63

Вывод: всё чуть сложнее, чем кажется 😉 и теперь надо бы постараться упростить работу с этим. Буду признателен за замечания и советы по улучшению данного механизма обхода блокировок.

Примечание: Для www.2019.vote срабатывает перенаправление на другое доменное имя, поэтому счетчик трафика в "Другие подключения" web-интерфейса Keenetic будет расти только при первом запросе по этому имени, а не при нажатии кнопки "обновить" в браузере. Я сходу просто не нашел подходящий сайт без перенаправления и только с A записью.

UPD: вместо www.2019.vote можно проверить изложенное на www.flibusta.is

Tor - tcp + ipv4+ipv6

SS - tcp+udp + ipv4+ipv6 (для udp требуется маркировка, и чистый shadowsocks)

VPN - tcp+udp+ipv4 - требуется маркировка.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   1 member

×
×
  • Create New...