Ярослав

Раз вам нужен HTTP сервер (а еще, видимо, рядом потребуется и СУБД запустить и какие-нибудь приложения), да еще и обход блокировок (а для этого требуются разные средства, не факт, что то, что работает сегодня, будет подходить через год), то вам нужен не роутер, а компьютер. Можно не слишком быстрый, но все-таки компьютер. Какие бы сложные блокировки ни были, если для них будет возможность обхода - она наверняка будет работать на Linux, а вот будет ли работать на роутерах - это под вопросом.

Одноплатники - стоят конские деньги для своей мощности, я бы их отмел. Я советую - мини-пк, которых сейчас много. Это все-таки настоящий компьютер, который можно как угодно конфигурировать, с полноценным обычным Linux внутри.

У меня c Озона (с Китая) - "Findarling Мини-ПК T9 Plus (Intel Processor N100, RAM 16 ГБ, SSD 512 ГБ, Intel HD Graphics, Windows 11 Pro), черный"
Я брал за 14 тыров, сейчас он 16 стоит. (есть варианты с SSD 256 и 1024).

Чем нравится: Вы видите характеристики, вполне себе достойная машинка даже для работы. На ней даже по приколу WoT можно запустить. Внутри обычный дебиан поставил. Проц N100 - довольно-таки мощный.

Бенчмарки:
geekbench: 1138 / 2795
UnixBench: 1706 / 4881

Для сравнения мой Core i5-4570 по unixbench дает 5753. На 20% быстрее всего (ну так то i5, а там N100)

И еще одна очень приятная фишечка именно этого вот мини-пк - ДВА ethernet порта! То есть, вполне пригоден в качестве файрвола, роутера.
Большой диск - можно использовать как файлопомойку и медиа-сервер (чтобы крутить фильмы с него на ТВ или через DLNA или сразу через HDMI).

Минусы - ЛГБТ-подсветка, но в сети написано, как ее выключить. Охлаждение активное, но он не греется при обычной работе, да и вентилятор в самом деле практически бесшумный.

Может быть вам какой-то другой мини-ПК подойдет, или вообще обычный в каком-нибудь micro-ATX корпусе (тогда вопрос ремонта-апгрейда еще проще будет). Но мой совет - смотреть в сторону более-менее современных, "настоящий" компьютеров, а не одноплатников. Чуть-чуть дороже, но гораздо-гораздо мощнее.

Помимо известных проектов (chroot, docker, podman, apparmor, selinux) ChatGPT посоветовал:
- firejail
- bubblewrap

Я потестил firejail:

mir ~ $ firejail --private --net=none dd if=/dev/zero of=BREAK bs=1K count=1
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc
Warning: networking feature is disabled in Firejail configuration file

** Note: you can use --noprofile to disable default.profile **

Parent pid 2406028, child pid 2406029
Child process initialized in 55.43 ms
1+0 records in
1+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 6.4323e-05 s, 15.9 MB/s

Parent is shutting down, bye...
mir ~ $ ls -l BREAK
ls: cannot access 'BREAK': No such file or directory

под firejail dd "записал" файл виртуально, на диске его нет, как видим. (но в /tmp будет писать на диск, а под рутом где-нибудь в /usr/lib - выругается, что read-only). Можно поиграть с настройками.

Сеть тоже не работает (если отключить):

mir ~ $ firejail --private --net=none ping 1.1.1.1
ping: connect: Network is unreachable

Бесполезно, но - когда я делаю себе новый ключик для wireguard (для нового компа, смартфона), очень удобно получить "красивый" ключ (чтобы несколько букв в начале ключа показывали имя устройства, для хоста asdf чтобы ключ был вроде asdf/....

1) не перепутаешь, какой ключ от какого сервера, не надо пересверять постоянно при настройке
2) сразу видно, что раз ключ "красиво" начинается, то это публичный ключ

И вот этим загружаю простаивающий комп. Но если хочется длинный префикс, а VPS слабая - это как раз загрузит ее на ближайшие 15 лет :-)

https://github.com/axllent/wireguard-vanity-keygen
https://github.com/warner/wireguard-vanity-address

Вы не учли более простой (как мне кажется) вариант с Dynamic DNS.

Есть простое решение, которое делается за час на базе okerr + dynamic DNS.
https://habr.com/ru/articles/359372/

Зайдите на https://cat.okerr.com/ и если вы увидите котенка и надпись "status=OK" - значит, эта система работает. При том что там всего 3 сервера и каждые 20 минут мы условно "пристреливаем" один из них :-) В первый заход вы почти 100% попадете на живой сервер. В последующие можете оставаться на "умершем" короткое время, пока DNS запись не переключится (это уже проблема с браузером, часто в инкогнито загружается правильная страница).

Кратко - при детектировании ошибки, изменяется DNS запись на то значение, которое работает. (Для этого не требуется, чтобы DNS хостер умел в DynDNS, можно даже и без этого)

Несколько тонкостей:
1. Ситуация "падает доступ" только в теории очевидная и однозначная (потому что мы ее сами выдумали, а не исследуем Н.Ё.Х. ). В реальности - это более серая ситуация. Что именно мы считаем "падает доступ"? Например, если потерялся один сетевой пакет (на самом деле случается регулярно) - это уже "доступ упал"? Если с сервера мониторинга в Амстердаме доступ есть, а с сервера мониторинга в Твери через минуту доступа нет - то как это понимать: Ваш сервис за эту минуту упал или просто какие-то локальные проблемы в Твери? И даже если проблема видна с обоих серверов - это уже повод для паники и переключения, или мы полагаем, что проблема может быть минутная и лучше пусть через минуту сама исправится? Придется ответить себе на эти вопросы, но любой ответ будет по-своему ошибочный, всегда будет trade off между скоростью переключения и ложными срабатываниями.

2. Все равно сохраняется некоторое временное "окно" недоступности. Представим, что в момент T0 вы выдергиваете кабель (симулируете проблему). Мониторинг может заметить первую проблему во время T1, которое зависит от настроек и удачи (если перепроверка каждые 30 секунд, то заметить может и через 1 секунду и через 29 секунд). Если у нас есть перепроверки (чтобы избежать ложных результатов), то перепроверка будет во время T2 (причем, вы самим можете хотеть, чтобы Т2 было не в ту же секунду, а дать хотя бы минуту, чтобы ситуация может быть сама решилась). Затем уйдет 1-2 секунды чтобы изменить DNS запись. И вот после этого момента, если клиент решил зайти на ваш сайт, он получит новый (работающий) IP - для него все супер. Но другой человек, кто уже работает с ним, в момент переключения будет иметь старую DNS запись, и для него все еще будет не работать, пока эта запись не протухнет в DNS кеше (в браузере, на компьютере, на DNS резолвере/роутере). Этот период времени можно сократить выставив низкий TTL в DNS.

Замечания по вашим вариантам:
1. Облака - тоже падают. Может постабильнее, но вот я через окерр слежу за своими серваками на разных хостерах, иногда ложится и дешевый hetzner и дорогой AWS. (Причем, я бы не сказал, что даунтайм у hetzner выше. Субъективно и по моему личному опыту - наоборот). Небольшое утешение - если вы НЕ будете использовать мониторинг - скорее всего, вы этого не заметите. :-) Но в целом облачный вариант достаточно надежен (если не ожидать от него абсолютных 100%).
2. Раунд-робин DNS - в принципе могло бы подойти. Но тоже каждая попытка будет занимать какое-то время и даже когда будет очевидно, что один IP у вас умер, раундробин по прежнему будет его выдавать. Но если юзер будет долбиться в кнопку refresh - то рано или поздно пробьется -). Хотя есть еще проблема с браузерным кешем (как выше вот описал). Как вариант - вообще сделать собственное веб-приложение (не путать с веб-страничкой), которое все все данные умеет брать с разных серверов. Не смогла взять с www1.example.com, ну значит лезет на www2.example.com. Тогда это будет почти незаметно для пользователя. Но дорого разрабатывать приложение с этой сложностью. И да, это только для веба.
3. Обновление DNS записей. Вы пишете про ужасные 12 часов. Это должно регулироваться полем TTL записи - если изменить ее, все будет лучше. Но до секунды лучше не менять, а вот 30 секунд (наверное, это минимум, не уверен, что подойдет), минута ли пять минут - выглядят как разумный компромисс в вашей ситуации.
4. AS, BGP и все прочие сатанинские слова. Страшно, очень страшно, мы не знаем что это такое, если бы мы знали, что это такое, но мы не знаем, что это такое. Вам это может быть кажется интересным вариантом именно потому, что вы не знаете, насколько этот вариант ужасен, не имеете опыта с ним и все его минусы и сложности и ужасы для вас пока скрыты. Проблем там будет дофига. А кроме всего прочего, подумайте вот о чем - я выше написал, как в окерре все сложно и неоднозначно с простой казалось бы вещью - "доступен ли у нас сервер или нет" (хотя старались сделать как можно проще). Так вот с динамической маршрутизацией - не лучше. Там ведь тоже есть те же самые проблемы диагностики (как отличить кратковременное падение линка на 2 секунды, от выхода из строя и избежать ненужного переключения?) и проблемы переключения (окей, один роутер догадался, что линк лежит - а как скоро все роутеры мира обновят свои таблицы маршрутизации? К ноябрю?). Даже если вы наймете супер гуру в AS / BGP вряд ли он вам гарантирует переключение за секунду или хотя бы минуту. BGP обеспечивает связность сети в принципе (вот, в масштабе "хотя бы к ноябрю"), но не обеспечивает моментальности или даже минутности, пятиминутности. И те процедуры обнаружения неисправности и восстановления скорее всего вам будет сложнее использовать и подкручивать под себя. Весь мир использует BGP, но не забывайте, что это тот же самый мир, который в 2024 году использует IPv4 из 1981 и не может перейти на IPv6. В общем, ну его.

Сделайте сессию, как описано здесь - https://requests.readthedocs.io/en/latest/user/adv...

При первом заходе, в сессии появятся куки, а следующие запросы в рамках этой сессии будут их использовать.
Если сервер (не важно по какой причине) выдаст новые значения кукам, они так же сами автоматически отразятся в сессии.

Поддержу первого комментатора - фигня это все. То, что есть проекты для этого - не означает, что они качественно справляются с задачей, а означает, что есть спрос (вот как у вас) на такого рода *невыполнимую* задачу. Но да, как небольшое препятствие - это препятствие в самом деле. Но несложное. Это примерно как защитить контент вроде фотографий, которые отдаются клиенту - принципиально невозможно, и все механизмы защиты, вроде "сгорающих фото в телеграмме" обманывают самого пользователя, который надеется, что его это защитит, но совсем не того, кому нужно это украсть.

Если речь идет про защиту от копирования - я бы просто вставил какую-то сетевую функцию в код, чтобы что-то выполнялось по сети, с вашего сервера (и этого кода не было на клиентской части). Если нужно будет отключить - просто на сервере отключаете. Это обойти будет очень сложно.

Если же про защиту от копирования, но программа должна работать без сети - вы совершили ошибку еще на этапе выбора языка программирования - он не подходит для хоть сколько-то надежной защиты.

def x():
    print("x called")
fname="x"
globals()[fname]()

Ответ со словарем (выше) хороший. А еще есть встроенный словарь символов, который выдает globals().
И eval() - тоже вариант. Но если fname у вас идет из ненадежного источника (пользователя) - то это опасно (через globals() - тоже опасно). Например:

globals()['os'].system("clear")
Вызовет clear, а может вызвать и rm -rf / .

Если нужен безопасный eval - советую посмотреть на evalidate (disclaimer: этой мой пакет), и там по ссылкам еще альтернативы есть - asteval и simleeval. Через них можно (если аккуратно) сделать безопасный eval и проверить его популярным джейлбрейками (в evalidate они есть, и есть в тестах к нему).

Сам себе отвечу.
1. В том браузере, который (как у меня) кодирует скобки-кавычки - проэксплойтить эту уязвимость нельзя. Кодирование есть на стороне браузера.
2. Это "хороший тон", RFC3986, секция 2.2 https://datatracker.ietf.org/doc/html/rfc3986#sect... обязывает кодировать только некоторые другие символы:

If data for a URI component would conflict with a reserved character's purpose as a delimiter, then the conflicting data must be percent-encoded before the URI is formed.

reserved = gen-delims / sub-delims

gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"

sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="

Никакого другого требования кодировать я не нашел. То есть, curl, когда не кодирует двойные кавычки и угловые скобки - действует строго по RFC, а вот httpie или браузер - сами кодируют "лишние" символы, но они не обязаны делать это.

Ну и главное тут - это происходит на стороне клиента, следовательно: 1) на стороне клиента может быть что-то поломаное, работающее с ошибкой. Может быть какой-то новый (новорожденный) браузер с этими проблемами. Может быть старый очень браузер. Могут быть какие-то особые настройки, сочетания настроек и дополнений, из-за которых он не делает так. и 2) Браузер вполне может исполнять только требования RFC, но не более. Защищать дырявое приложение от XSS атак он не обязан.

3. Включать REQUEST_URI в ответ неправильно. Лучше так не делать. Но, тем не менее, есть такой тонкий и негарантированный слой защиты в популярных браузерах, который защищает от этого. Но никто не дает никаких гарантий, положиться на это нельзя.

Предполагаю, что никак. Вероятно, вы берете данные (музыку) с чужого сервера? Современные браузеры требуют, чтобы тот сервер (не ваш, и не ваше фронтенд-приложение) отдавал вместе с файлом еще и заголовок Access-Control-Allow-Origin (с адресом вашего сайта. Мол, "да, по запросам с этого сайта можно отдавать этот файл"), а если вы устанавливаете еще какой-то заголовок в запросе - то этот заголовок тот сервер должен сам от вас хотеть принять и упомянуть его в Access-Control-Allow-Headers в ответе.

Сейчас я вижу, что у вас играет музыка. Вы удалили какой-то проблемный источник и оставили только те, которые позволяют доступ с любых Origin?

XSS - это не атака на сервер, а атака на пользователей.
Допустим, есть огромная XSS уязвимость на сайте. Мы можем заманить пользователя на нужный "хитрый" урл на том сайте ("нажмите на эту ссылку" или даже через JS на нашем сайте перенаправить его), или отправить на тот сайт сабмит формы. В итоге пользователь оказывается на уязвимом сайте с "вредным" запросом, и, например (уже в браузере пользователя!) исполняется код (с полномочиями пользователя на этом сайте).

Например, если банковское веб-приложение (его JS код) позволяет делать переводы, то и внедренный через XSS JS код тоже сможет сделать такие же запросы на перевод к серверу.

А запуск просто 20 раз даст то, что вам нужно? Не требуется никакая коммуникация между процессами?
Тогда однозначно запускайте просто 20 копий программы, можно через parallel (стандартная утилита, есть наверное, везде) или просто своим шелл-скриптом. Будет быстрее и надежнее.

В пайтоне есть GIL и это сильно влияет на производительность в многопоточном режиме. Да и вообще, зачем усложнять? Один изолированный процесс, который делает какую-то простую функцию - это богоугодно. А если вы делаете монстра, который внутри себя запускает потоки/процессы то только в идеале вы приблизитесь к рекомендуемому варианту. А не в идеале - будете иметь проблемы с производительностью или какие-то сложноуловимые глюки и race conditions.

Многопоточность оправдана только если без нее никак, например, нужна коммуникация между процессами, работа с общими данными.

С другой стороны, если производительность вам не важна, а хочется "набить руку", потренироваться - в пайтоне это достаточно просто делается, почему бы и нет? Но это не самый оптимальный результат по скорости будет.

А какая-нибудь тильда вам не подойдет? Я так понимаю, высоких требований у вас нет - не проще ли это бесплатно где-то захостить?
И еще, если будет интересно - можно подумать в сторону jamstack сайтов (статических). Многие блоги, например, очень хорошо реализуются как статические сайты. (Современный статический сайт - совсем не так, как было в 90-ых, он может иметь JS, может пользоваться разными API, например, статичные блоги имеют комменты от disqus или других подобных сервисов). Потребуется сделать небольшую learning curve. Но у вас, мне кажется, типичный блог - каждое новое появившееся животное - это новый пост в этом блоге.

Из SSG (генераторов статичных сайтов) я предпочитаю hugo, но тут на вкус и цвет (я просто не люблю те, что написаны на JS).

Какие плюсы вы получите, если сайт будет статичным:
1. Он будет очень быстрым, это приятно пользователям и может хорошо индексироваться поисковиками (я для теста выжимал 100/100/100/100 web vitals по google lighthouse - оценка для десктопов, и 98/100/100/100 для мобил)
2. Его можно хостить бесплатно на куче хостингов типа netlify, cloudflare pages, github, gitlab, ...
3. Очень высокий аптайм, эти сервисы оочень редко ломаются.

Но чтобы научиться это делать, придется потратить какое-то время, первый раз это сложнее чем вордпресс поднять.

Я бы все-таки предпочел wireguard и пока что не слишком волновался насчет того, что его блокируют - это все легко обходится. Раз у вас свой сервер, то решается все легко.

Думать о том, как там будет через 3 года, и готовиться обязательно к самому худшему сценарию пока не нужно. А то потратите силы на подготовку к самому худшему, а он не случится - обидно будет. Но даже если случится, через три года если что и переставите, а там может или шах или ишак. А все это время лучше жить с быстрым VPN, пользоваться которым одно удовольствие. И ставится он "красиво", системным способом, а не как Outline.

У wg очень простая сигнатура для DPI, поэтому легко его детектят и блочат. Но для этой проблемы несколько вариантов решений.

Решение 1 от ValdikSS : Сначала с того же клиентского порта и на тот же серверный "пробить" соединение другим пакетом (без сигнатуры). Так как для DPI этот пакет - часть соединения, то оно уже не похоже на wg. А вот wg сервер просто проигнорирует первый мусорный пакет, выбросит, а на второй ответит.

wg0.conf: ListenPort = 56789

sudo nping --udp --count 1 --data-length 16 --source-port 56789 --dest-port DEST_PORT DEST_IP

Как проверить, что wireguard не заблокирован?
https://ntc.party/t/wireguard/4968/6
(обратите внимание на то, что на клиенте нужно зафиксировать ListenPort)

2. Тот же самый эффект, но без ручного запуска nping каждый раз (просто автоматизируем то же решение):
в конфиг wg (wg0.conf или какой у вас) просто пишем:

[Interface]
PrivateKey = ....
Address = 10.9.0.2/24
ListenPort = 12345

PreUp = nping --udp --count 1 --data-length 16 --source-port 12345 --dest-port 12345 123.123.123.123

3. Можно чуть больше заморочиться, и замаскировать (обфусцировать) wg трафик через netfilter - если на клиенте и сервере закодировать его с одинаковым ключом (и самым простым шифрованием) - DPI его не видит.
https://github.com/infinet/xt_wgobfs

В общем, wireguard сам по себе искаропки не умеет "прятаться" (это и не его задача), но если нужно его спрятать - это делается в две минуты. (Ну первый раз подольше, пока разбираешься). Силы зла и негетеросексуализма и так уже вынуждены применять дорогой и тяжелый DPI для блокировки очень простого VPN. Блокировать обфусцированный, как в этих примерах - на порядок (порядки) сложнее (если вообще возможно) и точно неэффективно - огромные затраты, чтоб заблочить VPN всего паре десятков тысяч ITшников, которые тут же как-то иначе наладят себе VPNы (в крайнем случае перейдут на Outline или что-то еще) - бессмысленно, поэтому, думаю, никогда и не случится.

Если очень хочется поиграться с амазоном: https://aws.amazon.com/free/ - вообще бесплатно, но это только на 12 месяцев. Для поиграться, чтоб немного получить опыта и строчку в резюме - может быть нормально. Но хоститься там будет дороже, чем на дешевом VPS вроде hetzner.

И в гугле есть бесплатная VPS если сможете привязать карту к ним. (привязка нужна и у меня почему-то снимают все-таки пару центов изредка). Получается и дешево и вполне себе "облачные технологии".

Но у вас парадоксальная ситуация, что вам облачность-то реально не нужна, нужна чисто "облачность ради облачности". Как по мне, облака - это либо для "больших мальчиков" (ну типа какого-нибудь м-видео или леруа), либо для модных стартапов, которые хотят сейчас запуститься и может быть через месяц быстро размножиться на тысячи серверов про большом успехе. Для большинства даже крупных (но не гиганстких) компаний достаточно обычных серверов (впски или дедики) - это гораздо дешевле. Но это если сумма за хостинг вам важна и ощутима. Если переплатить не страшно - тогда да, можно сразу в облака - некоторые вещи там могут оказаться удобнее (но никогда не дешевле).