Зайдите на страницу непосредственно с VPS. У вас либо проблема в браузерном кеше, либо в IP-адресе VPS.
непосредственно с vps curl netflix.com также показывает “Not Available”. Выходит IP vps-ки также забанен, других вариантов нет?
Похоже на то, а какое гео ip впски?
Что выдаст команда curl ipinfo.io ?
curl ipinfo.io выдает
“city”: “Amsterdam”,
“region”: “North Holland”,
“country”: “NL”,
“loc”: “52.3740,4.8897”,
“org”: “AS207651 Hosting technology LTD”,
“postal”: “1012”,
“timezone”: “Europe/Amsterdam”,
“readme”: “Get the full potential of IPinfo - IPinfo.io”
у кого curl netflix.com проходит, скиньте где vps брали с беспроблемной оплатой в РФ.
Собственно, это и ответ на ваш вопрос, данная AS - AS207651 российскому провайдеру, в гео RU
Как вариант — добавить swap, оптимальнее всего — в виде zram.
apt install zram-tools
Затем поправить /etc/default/zramswap, увеличив значение в процентах до 70, и systemctl restart zramswap.
Спасибо! Вроде помогло)
Помогите решить проблему с доступом на сайт meta.com, имеется шлем VR, который необходимо привязать к аккаунту META, установлен собственный сервер с помощью LXD, всё работает хорошо, но вот сайт meta.com никак не хочет открываться, подскажите куда копать. Заранее спасибо.
Вопрос решился после добавления домена в include-hosts-custom.txt, правда пришлось подождать некоторое время, чтобы он начал пропускать.
Добрый день, есть ли возможность как нибудь использовать днс резолвер как сервер, а не тунельный с блокировкой днс компьютера? Но при этом чтобы впн так же работал только на заблокированных сайтах. из-за этого windows постоянно говорит что нет сети, хотя она есть. Это на работоспособность в основном не влияет, но раздражает немного, особенно когда приложения доверяют винде в определении доступности интернета.
Коллеги, как диагностировать такое поведение:
- Ночью пропал интернет на VPS на полчаса.
- С утра проснулся, смотрю - был даунтайм. Лезу проверять сайты - работают частично (например инстач пашет, твиттер-тижорнал не пашет, пишет Could not resolve DNS, пинги и в правду не резолвят имя).
- Начал смотреть клиентскую часть - по перетыкал соединение, по перезагружал роутер. Не помогло.
- Подключился с OpenVPN клиента с телефона через 4G / tcp - тоже сайты открываются частично. То есть, проблема не на клиенте, а на сервере.
Смотрю на сервер, там с аптаймом все в порядке, curl / telnet по запрещенным ресурсам без проблем ходит. Перезагрузил виртуалку, всё заработало.
Может ли быть, что kresd как то отваливается из-за долгого отсутствия интернета? Как добиться его (кресда) стабильной работы?
Перестал отдаваться контент гугл-фото ( lh3.googleusercontent.com )
Прописал домен в include-hosts-custom.txt, но, видимо, блокируется как-то по-другому.
PS C:\Users\ArchimedRT> tracert lh3.googleusercontent.com
Трассировка маршрута к googlehosted.l.googleusercontent.com [142.250.185.65]
с максимальным числом прыжков 30:
1 4 ms 1 ms 1 ms MI-R3G [192.168.1.1]
2 1 ms 1 ms 1 ms 10.16.255.135
3 1 ms 1 ms 1 ms 10.16.248.225
4 3 ms 3 ms 3 ms 10.16.248.218
5 * * * Превышен интервал ожидания для запроса.
6 3 ms 3 ms 3 ms 10.16.248.253
7 53 ms 53 ms 54 ms ae10-493.rt.itp.kzn.ru.retn.net [87.245.231.206]
8 60 ms 61 ms 65 ms ae5-9.rt.sl.spb.ru.retn.net [87.245.233.13]
9 26 ms 27 ms 26 ms gw-google.retn.net [87.245.228.199]
10 26 ms 26 ms 27 ms 74.125.244.132
11 39 ms 31 ms 30 ms 142.251.61.219
12 32 ms 32 ms 32 ms 72.14.232.87
13 * 64 ms 63 ms 142.251.239.32
14 66 ms 63 ms 62 ms 209.85.245.31
15 61 ms 59 ms 60 ms 108.170.251.193
16 63 ms 62 ms 62 ms 142.250.62.151
17 61 ms 61 ms 60 ms fra16s48-in-f1.1e100.net [142.250.185.65]
Трассировка завершена.
Как понять, где проблема, и как ее исправить?
Такое может быть, попробуйте очистить кеш резолвера:
echo "cache.clear()" | socat - /run/knot-resolver/control/1
В контейнере версия kresd старая, но насколько помню, версии новее требовали перенастройки для корректной работы со stub-резолвером, перезаписывающим адреса, коим является репамминг-резолвер, так что лучше его не обновлять.
В свободное время соберу обновлённую версию контейнера, где такой проблемы, надеюсь, не будет.
Удалите домен googleusercontent из config/exclude-hosts-dist.txt.
Когда скрипты АнтиЗапрета создавались, они резолвили IP-адреса заблокированных доменов и добавляли IP’шники в список. На тот момент были вредоносные домены, устанавливающие себе IP-адреса легитимных, поэтому был создан такой список. С тех пор многое изменилось, а список остался. В то время не предполагалось, что такие крупные домены могут блокироваться гос. структурой.
Кстати, описаная мной проблема если что есть и на старой (из коробки версии антизапрета), так и на новой.
Под новой я вот что понимаю:
внутри LXC контейнера прописал свежие ключи и запустил apt update && apt-upgrade.
В итоге, сейчас у меня kresd 5.5.2, всё работает, но вот такая канитель случается.
Спасибо за очистку кэша, как-нить выцеплю и попробую полечить (а может есть даже смысл в крон прописать, нехай он каждую ночь чистит)
Не помогло.
А вот когда подключаюсь через альтернативный конфиг (пуск всего трафика по инструкции), то все работает корректно.
Вероятно, вы забыли обновить лист после редактирования файла исключений, либо же googleusercontent еще где-то присутствует в качестве исключения.
Присоединяюсь, тоже не грузят гуглфото и аватарки в гуглтаблицах.
Удаление googleusercontent.com из exclude-hosts-dist.txt и добавление в include-hosts-custom.txt (после этого естественно был выполнен doall, сброшен кэш кнота и выждано время) - не помогло.
Симптомы - пинги до *.googleusercontent.com не заворачиваются в тоннель (а идут через интернет как у Архимеда).
но в exclude-regexp-dist.awk был обнаружен еще (/googleusercontent.com/) {next}.
и вот удаление его вопросики порешало, то есть итого:
- Удаляем строку гуглюзерконтент из exclude-hosts-dist.txt;
- Добавляем строку в include-hosts-custom.txt;
- Удаляем строку из exclude-regexp-dist.awk
Затем doall, и погнали
Я пробовал удалять и из файла exclude-regexp-dist.awk, но после этого у меня даже пинг до lh3.googleusercontent.com не идет.
Причем, с альтернативным конфигом с пуском всего трафика тоже перестает открываться
Убедитесь, что после изменения не забыли запустить doall, а также очистите кеш knot-resolver (если домен резолвится в настоящий IP-адрес, а не в 10.224.x.x, то дело в кеше либо knot, либо ОС).