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-терминала спасает -- даже сотовые сети работают плохо.
Ориентированный означает, что пройти по такому графу можно только в одном направлении.
Ориентированный значит, что рёбра однонаправленные. В самом графе могут быть и циклы.
Так называемые L2-коммутаторы не являются участниками ip-сетей и в алгоритме кратчайших путей не участвуют. Они являются мостами для организации взаимодействия подключенных маршрутизаторов, позволяя экономить физические порты роутеров и уменьшать количество настроек.
Немного зауженный взгляд на свитчи. Нельзя сказать, что написанное Вами неверно, но я б сказал что свитчи являются для Ethernet примерно тем же, чем роутеры для IP-сетей.
Поиск по ресурсу выдал примерно 20 страниц со статьями, но к сожалению среди них не было ни одной подробной про работу алгоритма в ip-сетях.
Обычно алгоритм выбирают под задачу, а не ищут решения задачи с использованием какого-то алгоритма. Насколько я знаю, алгоритм Беллмана-Форда используется в RIP и BGP. Почему так? У меня только догадки. Может быть Вы могли бы в статье раскрыть свой выбор. Заодно и рассказать про оценку сложности конкретно вашей реализации на плюсах с использованием set вместо очереди с приоритетом для непосещённых узлов, что получается если её сравнить по вычислительной сложности и затратам памяти с тем же Беллманом-Фордом.
После прочтения я так и не понял, что для меня в этой статье, как бы я мог воспользоваться этим. Может разве что кто-то захочет написать свою реализацию протокола динамической маршрутизации. Отчасти статья выглядит как курсовая работа, раздутая до требуемого объёма листингами.
Вы можете попробовать opera-proxy. Он предоставляет доступ к "VPN" оперы и поддерживает подключение через вышестоящий прокси, например Tor. См. опцию -proxy.
Ну, как минимум openvpn через прокси тоже рабочий вариант, причём в смысле оверхеда не хуже простого openvpn через tcp. UDP плохо заворачивается в TCP или TLS по известным причинам. Но можете попробовать позаворачивать UDP в DTLS: https://github.com/Snawoot/dtlspipe
Хотя, положа руку на сердце, особых причин форвардить UDP через прокси или VPN нету.
А что в этой отечественной РЕД ОС отечественного?
Есть такое, да. Потому и встал вопрос альтернатив. Может с их стороны заблокировано. А передвину-ка я его на последнее место, раз такое дело.
А давайте. Если есть настроение, то присылайте пуллрек.
Так там всё то же самое, если включить 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-терминала спасает -- даже сотовые сети работают плохо.
Вот так вот сразу, да?
Ориентированный значит, что рёбра однонаправленные. В самом графе могут быть и циклы.
Немного зауженный взгляд на свитчи. Нельзя сказать, что написанное Вами неверно, но я б сказал что свитчи являются для Ethernet примерно тем же, чем роутеры для IP-сетей.
Обычно алгоритм выбирают под задачу, а не ищут решения задачи с использованием какого-то алгоритма. Насколько я знаю, алгоритм Беллмана-Форда используется в RIP и BGP. Почему так? У меня только догадки. Может быть Вы могли бы в статье раскрыть свой выбор. Заодно и рассказать про оценку сложности конкретно вашей реализации на плюсах с использованием set вместо очереди с приоритетом для непосещённых узлов, что получается если её сравнить по вычислительной сложности и затратам памяти с тем же Беллманом-Фордом.
После прочтения я так и не понял, что для меня в этой статье, как бы я мог воспользоваться этим. Может разве что кто-то захочет написать свою реализацию протокола динамической маршрутизации. Отчасти статья выглядит как курсовая работа, раздутая до требуемого объёма листингами.
Защиту детей ещё приплетите.
Зеркало: https://web.archive.org/save/https://habr.com/ru/articles/777656/
del
Вы можете попробовать opera-proxy. Он предоставляет доступ к "VPN" оперы и поддерживает подключение через вышестоящий прокси, например Tor. См. опцию
-proxy.Хорошо, тогда заворачивайте Wireguard в DTLS.
Ну и плюс никто не мешает завернуть весь траф в прозрачный прокси у которого апстримом будет стоять прокси через HTTPS.
Ну, как минимум openvpn через прокси тоже рабочий вариант, причём в смысле оверхеда не хуже простого openvpn через tcp. UDP плохо заворачивается в TCP или TLS по известным причинам. Но можете попробовать позаворачивать UDP в DTLS: https://github.com/Snawoot/dtlspipe
Хотя, положа руку на сердце, особых причин форвардить UDP через прокси или VPN нету.
Всё, что похоже на HTTPS, скорее всего будет работать. Поэтому самые обычные HTTPS-прокси хорошо работают (и быстро). Посмотрите в эту ветку.