Там целый скриптовый движок есть чтобы любое сочетание правил нарисовать можно было. Опцией -js-access-filter задаём файл со скриптом:
const allowedIPs = new Set([
"203.0.113.99",
]);
function ipFromAddrPort(addrPort) {
return addrPort.replace(/\:[^:]+$/, "").replace(/^\[(.*)\]$/, "$1");
}
function access(req, dst, username) {
const ip = ipFromAddrPort(req.remoteAddr);
if (allowedIPs.has(ip)) {
return true;
}
print(`rejecting IP address ${ip} due to IP filter restrictions`);
return false;
}
А у софта нету никаких крутилок для ограничения трафика по логинам?
Спрашиваю не просто так -- я автор dumbproxy, в нём в принципе можно накрутить лимиты по трафу, но не очень удобным образом. Думаю, насколько целесообразно и востребовано было бы прикрутить лимиты по трафику.
Мда, какой-то позор просто... Ну оставлю тогда рефералочку, но не знаю как там с оплатой из России дела обстоят. У меня весь вебсерфинг через неё, всё устраивает и стоит 2 евро в месяц.
Насчёт скорости дешёвых VPS слишком категоричное заявление. Масса дешёвых хостеров предоставляют гигабитный порт. Другое дело, что сейчас почти везде объём трафика лимитирован (однако, зачастую лимит вполне достаточный).
Допустим, у меня есть вот такой конфиг Wireguard для Proton VPN:
[Interface]
# Key for ws
# Bouncing = 3
# NAT-PMP (Port Forwarding) = off
# VPN Accelerator = on
PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
Address = 10.2.0.2/32
# DNS = 10.2.0.1
PreUp = ip rule add from 10.2.0.2 lookup 1000
PostDown = ip rule del from 10.2.0.2 lookup 1000
Table = 1000
[Peer]
# NL-FREE#106
PublicKey = ExWwfvm2QK3oJhrz4s0tsBLt1PVBiONhljwh5jt40Bk=
AllowedIPs = 0.0.0.0/0
Endpoint = 185.182.193.108:51820
Строка 11 задаёт, что маршруты для этого соединения будут добавлены не в главную таблицу маршрутизации, а в дополнительную с номером 1000. Т.е. интерфейс не станет маршрутом по умолчанию.
Строки 9 и 10 добавляют и удаляют при старте правило, что для исходящего адреса 10.2.0.2 используется таблица маршрутизации с номером 1000. Всё, этого достаточно для избирательной отправки в разные интерфейсы. Уже упомянутый выше скрипт
P.S. Если запускаете steady-tun где-то в локальной сети, то чтобы он принимал соединения не только со 127.0.0.1 нужно ещё добавить опцию -bind-address 0.0.0.0
Дело в том, что тут есть путаница. Eсть HTTPS-прокси как обычный HTTP-прокси, но он поддерживает метод CONNECT для прохождения HTTPS-трафика через него. А есть HTTPS-прокси который (обычно) умеет всё вышеперечисленное, но связь с самим прокси осуществляется через TLS (т.е. HTTP-proxy-over-TLS). В статье выше как раз про такой, защищённый прокси. Судя по документации proxifier под HTTPS-проксями понимает обычные HTTP-прокси.
Однако это не проблема, если приложение поддерживает только обычные прокси. Есть вот такой адаптер, который оборачивает соединение в TLS. Вы его запускаете где-то у себя (на клиенте или где-то в локалке) вот так:
И он будет слушать порт 57800 и пересылать соединения уже через TLS. На него уже можно подключаться как на обычный прокси (HTTPS-прокси в терминах proxifier). При этом, конечно же, proxifier должен быть настроен так, чтобы не перенаправлять соединения steady-tun в прокси, иначе работать не будет.
В этом руководстве всё сделано через опцию -autocert, которая получает сертификаты автоматически через ACME (по умолчанию - LetsEncrypt). Сертификат выпускается сразу, как только приходит соединение для которого нет сертификата в кэше. Расположение кэша автоматически выписываемых сертификатов задаётся опцией -autocert-dir (по умолчанию в ~/.dumbproxy/autocert).
Если вам нужно задать свой сертификат, это можно сделать опциями -cert и -key.
Оптика оптике рознь. Если FTTX и свитч провайдера выключается вместе с общим электричеством, то нет. PON таким страдать не должны -- там всё оборудование пассивное. Буквально стекляшки просто без какого либо питания. Я живу в регионе, где часто и надолго выключают свет, поэтому только резервное питание роутера и PON-терминала спасает -- даже сотовые сети работают плохо.
Там целый скриптовый движок есть чтобы любое сочетание правил нарисовать можно было. Опцией
-js-access-filterзадаём файл со скриптом:Добавил рецепт в вики проекта: https://github.com/SenseUnit/dumbproxy/wiki/Recipe:-restricting-access-by-IP-address
А у софта нету никаких крутилок для ограничения трафика по логинам?
Спрашиваю не просто так -- я автор dumbproxy, в нём в принципе можно накрутить лимиты по трафу, но не очень удобным образом. Думаю, насколько целесообразно и востребовано было бы прикрутить лимиты по трафику.
Если кто-то интересуется мультихопом, то dumbproxy поддерживает форвардинг через вышестоящий прокси и прост в настройке.
Мда, какой-то позор просто... Ну оставлю тогда рефералочку, но не знаю как там с оплатой из России дела обстоят. У меня весь вебсерфинг через неё, всё устраивает и стоит 2 евро в месяц.
https://webdock.io/en/pricing?ReferralCode=WDREFAJNY
Насчёт скорости дешёвых VPS слишком категоричное заявление. Масса дешёвых хостеров предоставляют гигабитный порт. Другое дело, что сейчас почти везде объём трафика лимитирован (однако, зачастую лимит вполне достаточный).
Да, и гигабит с полным дуплексом, насквозь.
Можно на уровне TCP форвардить, разделяя соединения с помощью nginx по SNI: https://github.com/SenseUnit/dumbproxy?tab=readme-ov-file#example-http-proxy-over-tls-pre-issued-cert-behind-nginx-reverse-proxy-performing-sni-routing
Либо можно просто вместо nginx использовать haproxy, который не имеет проблем с методом CONNECT.
Три противоречащих точки зрения, конечно, лучше, чем две.
Так уже можно делать.
Допустим, у меня есть вот такой конфиг Wireguard для Proton VPN:
Строка 11 задаёт, что маршруты для этого соединения будут добавлены не в главную таблицу маршрутизации, а в дополнительную с номером 1000. Т.е. интерфейс не станет маршрутом по умолчанию.
Строки 9 и 10 добавляют и удаляют при старте правило, что для исходящего адреса 10.2.0.2 используется таблица маршрутизации с номером 1000. Всё, этого достаточно для избирательной отправки в разные интерфейсы. Уже упомянутый выше скрипт
отправит трафик в заданный домен избирательно.
А что в этой отечественной РЕД ОС отечественного?
Есть такое, да. Потому и встал вопрос альтернатив. Может с их стороны заблокировано. А передвину-ка я его на последнее место, раз такое дело.
А давайте. Если есть настроение, то присылайте пуллрек.
А с чего у вас уверенность, что цензор не может осуществлять пробы с ИП-адресов клиентов, которых видел?
Так там всё то же самое, если включить TLS. А если его не включать (или в dumbproxy убрать опцию -autocert) то шифрования не будет.
P.S. Если запускаете steady-tun где-то в локальной сети, то чтобы он принимал соединения не только со 127.0.0.1 нужно ещё добавить опцию -bind-address 0.0.0.0
Значит приложение стучится в проксю не через TLS.
Дело в том, что тут есть путаница. Eсть HTTPS-прокси как обычный HTTP-прокси, но он поддерживает метод CONNECT для прохождения HTTPS-трафика через него. А есть HTTPS-прокси который (обычно) умеет всё вышеперечисленное, но связь с самим прокси осуществляется через TLS (т.е. HTTP-proxy-over-TLS). В статье выше как раз про такой, защищённый прокси. Судя по документации proxifier под HTTPS-проксями понимает обычные HTTP-прокси.
Однако это не проблема, если приложение поддерживает только обычные прокси. Есть вот такой адаптер, который оборачивает соединение в TLS. Вы его запускаете где-то у себя (на клиенте или где-то в локалке) вот так:
И он будет слушать порт 57800 и пересылать соединения уже через TLS. На него уже можно подключаться как на обычный прокси (HTTPS-прокси в терминах proxifier). При этом, конечно же, proxifier должен быть настроен так, чтобы не перенаправлять соединения steady-tun в прокси, иначе работать не будет.
P.S. Документация: https://github.com/SenseUnit/dumbproxy#dumbproxy
Вики с несколькими полезными рецептами: https://github.com/SenseUnit/dumbproxy/wiki
В этом руководстве всё сделано через опцию -autocert, которая получает сертификаты автоматически через ACME (по умолчанию - LetsEncrypt). Сертификат выпускается сразу, как только приходит соединение для которого нет сертификата в кэше. Расположение кэша автоматически выписываемых сертификатов задаётся опцией -autocert-dir (по умолчанию в ~/.dumbproxy/autocert).
Если вам нужно задать свой сертификат, это можно сделать опциями -cert и -key.
А где вы здесь видите SOCKS?
Оптика оптике рознь. Если FTTX и свитч провайдера выключается вместе с общим электричеством, то нет. PON таким страдать не должны -- там всё оборудование пассивное. Буквально стекляшки просто без какого либо питания. Я живу в регионе, где часто и надолго выключают свет, поэтому только резервное питание роутера и PON-терминала спасает -- даже сотовые сети работают плохо.
Вот так вот сразу, да?