Prg, а если он локальный, то зачем ему HTTPS? Это все шифрование нужно только для одного - защита трафика при передачи через ненадежные каналы, если все внутри LAN, то такие упражнения излишни.
Prg, если домен локальный - то нет, через certbot это не сделать, по крайней мере стандарным подходом, потому что certbot должен иметь возможность на web сервере по 80 порту связаться со своим сервером для создания сертификата...
Вообще, традиционно mysite.com обозначает некий публичный сайт, если надо писать про внутренний, то пишут site.local
ky0, А, ну я прочел это как самому делать валидный сертификат, через свой СЦ. ))) Ну, я то как раз понял вопрос так, что сайт то не локальный. а публичный, на который надо откуда то переходить...
валидный сертификат самому не сделать, ибо сертификат сервера должен быть подписан любым СЦ (прямо или через цепочку сертификатов), которым доверяет браузер конечного клиента...
ну и надо бы добавить - что это все работает для совсем тупых, умные поднимут свой DOH и будут пользоваться им (у меня именно так сделано), ну или каким то публичным DOH, их в инете мильён... https://dnscrypt.info/public-servers/
Ну или еще проще - восопользуются VPN или проксированием DNS.
Вообще, я против каких бы то ни было блокировок, кроме рекламных.
это все легко гуглится же, там тебе ниже написали как, это одна из самых распространенных задач, через тот же GPT можно узнать как... а вообще лучше это делать не через средства Mikrotik, а сделать это через внешний DNS сервис, вроде AdGuardHome...
Alexey Dmitriev, Для этого не нужны отдельные сертификаты, если конечно для каждого контейнера не выделен отдельный домен, и даже в этом случае есть wildcard сертификат.
Развернуть на сервере контейнер с NGINX который будет выступать "фронтом" для запросов на 80 и 443 порты, которые он будет проксировать в контейнеры с NGINX-backend сервисов (сайтов\приложений e.t.c)
Звучит как какой то бред. Поставь один web - сервер, без контейнеров и всей этой мишуры, не надо плодить зловещий зоопарк из w.eb-серверов. На хосте должен быть только один web-сервер, все остальное решается просто добавлением нужных портов и правил в его конфиги.
трассировку до нужного хоста сделай, и проверь маршруты, через какие сервера ходят пакеты... возможно хочтинг-провайдер в целях экономии гонит трафик непойми куда и откуда, отсюда и тормоза...
ну и пробуй проверять канал через iperf3, в разное время, возможно сервера на которых VPS ки забиты, от этого тоже бывают тормоза
ну и РКН может гадить, это из основная задача, и они её осуществляют как могут
Dark_Time, bridge это сетевой мост между физическими интерфейсами, это если надо ограничивать канал между разными портами LAN, если нужно ограничить канал интернет, используй тот интерфейс, куда заходит кабель от провайдера, обычно ether1.
Dark_Time, ты ссылку посмотри, там буквально все расписано. Особенно раздел "Ограничение скорости по IP". Нет смысла мне повторять все то, что там есть.
Vaxa Packs, ну, с учетом того, что play собирает aap под конкретный девайс, где то происходит ошибка.
Я с таким не встречался, обычно Google SignIn от ключей Goggle Play не зависит, хотя они могли что-то и поменять. Никаких depricated библиотек и функций нет?
Вообще, по симптомам очень похоже на то, что где то Client ID или package name не совпадает, проверь еще раз в console.cloud.google.com. Ну и Update selected scopes. Сорри, не могу дать конкретный ответ, но я бы еще на StackOverflow поспрашивал, возможно кто-то и натыкался на подобное.
Ziptar, ну, ок, не категорически, а желательно... ))) Просто не надо мешать ей работать, отключение этого не приводит к решению каких то проблем, чаще всего, а создает дополнительно новые, особенно если пользователь не осознает что он делает, зачем и какой при этом хочет результат. В целом его работа по автоматическому присвоению IP и внутренней маршрутизации не создает проблем, и если нету пушей каких то статических маршрутов - его отключение не на что не влияет.