На Хабре есть уже десятки статей о том, как поднять свой VPN. Но, кроме VPN, существует еще и прокси. Для браузера его более, чем достаточно.
Практика показывает, что РКН на данный момент не ломает даже прозрачные HTTP прокси (МГТС, Москва). Надеяться на это, впрочем, не приходится, поэтому мы поднимем еще и HTTPS прокси с помощью Squid. Данный прокси работает тупо по адресу и паре логин:пароль безо всяких PAC файлов и прочих костылей на стороне клиента (костылей на стороне сервера будет предостаточно). Позволяет гонять через себя весь TCP трафик не интересуясь, что там уже заблокировано, а что еще нет. Кроме того, его хорошо понимают скрипты и программы Linux, потому что он совместим с переменными HTTP_PROXY и HTTPS_PROXY. Например, в докере:
environment:
- HTTPS_PROXY=https://user:password@domain1.com:12345В минимальной проверенной конфигурации, нам понадобится два сервера: один в РФ, второй "за кордоном". Теоретически, сервер в РФ можно заменить локальным Squid. Для пользователей Linux это не сложно: squid-openssl ставится одной командой в терминале. Но для Windows ничего подходящего (и стабильно работающего) я так и не нашел.
Кроме того, полноценный сервер в РФ позволяет предоставить доступ неограниченному кругу лиц и устройств. И, например, размазать финансовые затраты на несколько человек.
Идеальная, максимальная конфигурация: 1 сервер в РФ, любое количество серверов не в РФ, свой домен.
Весь гайд и конфигурация рассчитаны на последнюю Ubuntu 24, хотя бы 1 гигабайт ОЗУ и 10ГБ места на диске. Минимальный shared конфиг аезы подойдет.
После прохождения всех шагов гайда вы получаете HTTPS и HTTP прокси с авторизацией по паре логин:пароль. Учтите, что такая авторизация - непопулярный в 2024 году способ использовать прокси, поэтому почти для всех браузеров вам понадобится расширение, которое имеет поля для их ввода. Для Firefox я использую FoxyProxy.
Я не претендую на специалиста и являюсь простым юзером. Поэтому конфиги могут выглядеть некрасиво, могут иметь в меру бесполезные строчки и прочее-прочее. Я размещаю конфигурацию, которая работает у меня. Совсем идиотских предложений в ней быть не должно.
Я не ставил цели сэкономить. Поэтому у меня есть два сервера (за которые я плачу в сумме 14000 рублей в год) и домен, за который я отдаю еще 5 тысяч рублей в год. Пространство для экономии есть: существуют копеечные домены, есть очень дешевые VPS, можно попробовать где-то прикрутить самоподписанный сертификат и обойтись без домена вовсе, а некоторые серверы могут быть ipv6-only, еще дешевле. Всего этого в гайде не будет - тут вам придется изучать вопрос самостоятельно. Меня удовлетворил вариант с делением ценника на несколько человек - я лично отдаю 4000 рублей в год.
Далее по гайду, первый сервер - это сервер в РФ, который и будет прокси-сервером, к которому будут подключаться клиенты (браузеры). Второй сервер - это сервер в другой стране, к которому сервер 1 будет обращаться по необходимости. Клиенты напрямую к серверу 2 не подключаются.
1. Безопасность
На всех серверах меняем socket ssh на сервис, чтобы он читал настройки из /etc/ssh/sshd_config:
systemctl disable --now ssh.socket
systemctl enable --now ssh.serviceГенерируем новый ключ на сервере:
ssh-keygen -t rsa -b 4096 -C "root@server"
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.sshЧитаем ключ с сервера: cat ~/.ssh/id_rsaи копируем его текстом себе на ПК. Файл с сервера удаляем rm ~/.ssh/id_rsa
Если ваш ssh клиент требует файл ppk, то этот текст можно импортировать в puttygen (conversions -> import key) и сохранить как ppk (file -> save private key).
Проверяем, что авторизация по ключу и без пароля работает, после чего отключаем вход по паролю, добавляя эти строчки в nano /etc/ssh/sshd_config:
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PubkeyAuthentication yesРаз уж мы здесь, переносим ssh на другой порт:
Port 45678Убедитесь, что в файле нет конфликтующих строчек, разрешающих авторизацию по паролю, вроде PasswordAuthentication yes
Далее, разрешаем новый порт ufw allow 45678 и перезагружаем ssh systemctl restart ssh
Пока мы занимаемся портами, разрешим себе на будущее сразу все:
ufw allow 80
ufw allow 443
ufw allow 12345
ufw allow 12346Последние два - это предлагаемые мной порты для прокси. В целях маскировки, рекомендую использовать любые другие два порта здесь и далее.
Кроме того, если у вас статический IP, можно разрешить с него (и к нему) весь трафик. Аналогично, если вы используете конфигурацию с 2 серверами, есть смысл разрешить им весь трафик друг к другу:
ufw allow from 111.222.333.444
ufw allow to 111.222.333.444Вызов ufw status после этого должен возвращать:
Status: active
To Action From
-- ------ ----
443 ALLOW Anywhere
80 ALLOW Anywhere
... и так далее ...Если status: inactive, то включаем: ufw enable
Повторюсь, что эти шаги есть смысл сделать на всех серверах: и на российском, и на зарубежном(ых). Учтите, что зарубежные серверы общаются, фактически, только с прокси в РФ. Поэтому настраивать файерволл от них к клиентам в РФ не нужно - только к прокси.
2. Подготовка сторонних программ
Эти шаги тоже делаем на всех серверах.
Устанавливаем nginx, он еще может пригодиться в хозяйстве (например, проксировать vless grpc или websocket, если вы решите совместить приятное с полезным и развернуть на том же сервере vpn):
apt update
apt install -y nginx-fullЯ настоятельно рекомендую вам использовать HTTPS, для чего будет очень удобно заиметь собственный домен. Устанавливаем certbot для получения сертификатов:
apt install -y snapd
snap install --classic certbot
ln -s /snap/bin/certbot /usr/bin/certbotНа этом этапе вы должны направить свой (под)домен на IP сервера. Если есть IPV6, сделайте и A и AAAA записи. После чего, немного обождав, получаем сертификат на этот домен:
certbot --nginxВ nginx сертификат встанет сам, и путь до него можно будет посмотреть в конфигурации оного. Но в любом случае, пути сохраняем, потому что они нам понадобятся в шаге 4.
3. Подготовка Squid
Добавляем репу со squid, поддерживающим ssl и устанавливаем его на все серверы (не обязательно для Ubuntu 24):
wget -qO - https://packages.diladele.com/diladele_pub.asc | sudo apt-key add -
echo "deb https://squid57.diladele.com/ubuntu/ focal main" > /etc/apt/sources.list.d/squid57.diladele.com.listУстанавливаем:
apt-get update && apt-get install -y squid-common squid-openssl apache2-utils wget squidclient libecap3 libecap3-devНа первом сервере, который будет раскидывать клиентов по остальным, создаем файл с паролем:
htpasswd -c /etc/squid/htpasswd proxyОбратите внимание, что дополнительные пользователи добавляются уже без -c:
htpasswd /etc/squid/htpasswd proxy2На остальных серверах пароль нам не нужен - прокси будут разрешены по IP.
4. Конфигурация squid:
Во всех случаях редактируем файл /etc/squid/squid.conf
Сервер 1 в РФ (к которому ходят все клиенты):
https_port 111.222.333.444:12345 cert=/etc/letsencrypt/live/domain1.com/fullchain.pem key=/etc/letsencrypt/live/domain1.com/privkey.pem
https_port [0000:0000:0000::2]:12345 cert=/etc/letsencrypt/live/domain1.com/fullchain.pem key=/etc/letsencrypt/live/domain1.com/privkey.pem
http_port 111.222.333.444:12346
http_port [0000:0000:0000::2]:12346
dns_nameservers 8.8.8.8 1.1.1.1
# Authentication settings
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/htpasswd
auth_param basic realm proxy
# Access control lists (ACLs)
acl authenticated proxy_auth REQUIRED
acl primary dstdomain "/etc/squid/squid-whitelist-zones.conf"
acl hasRequest has request
acl allowed_ips src 000.000.000.000
access_log daemon:/var/log/squid/access.log hasRequest
# Access rules
http_access allow allowed_ips # Allow these IPs without authentication
http_access allow authenticated # Allow authenticated users
http_access deny all # Deny all others
# Cache settings
cache_peer domain2.com parent 14881 0 no-query no-digest ssl sslflags=DONT_VERIFY_PEER sourcehash
cache_peer_access domain2.com allow primary
cache_peer_access domain2.com deny all
cache_peer 555.555.555.555 parent 14881 0 no-query no-digest ssl sslflags=DONT_VERIFY_PEER sourcehash
cache_peer_access 555.555.555.555 allow primary
cache_peer_access 555.555.555.555 deny all
prefer_direct on
never_direct allow primary
never_direct deny all
cache allow all
cache_dir aufs /tmp/squid 1000 16 256
cache_mem 256 MB
memory_cache_mode always
maximum_object_size 4096 KB
maximum_object_size_in_memory 256 KB
pipeline_prefetch 10
collapsed_forwarding on
max_filedescriptors 65535
pinger_enable onПояснения по релевантным пунктам:
1 и 2 нужно удалить, если вы не планируете HTTPS. В противном случае, вам нужно поменять путь до сертификата, который вам дал letsencrypt.
2 и 5 нужно удалить, если у вас нет IPV6 адреса.
4 и 5 можно удалить, если вам не нужен HTTP прокси.
В строчке 17 можно указать собственный IP (если он у вас статический) для доступа без пароля. В противном случае, строчки 17 и 22 удаляем.
В строчках 27-29 и 31-33 настраивается маршрутизация до двух серверов (связка из 3 серверов и, потенциально, больше). Первый пример с хождением по домену, второй - по IP. Меняем на свои значения. Учтите, что настраивать один прокси и как домен, и как IP, не нужно - squid их сам под капотом интерпретирует в IP. Поэтому, если у вас только один прокси в другой стране - оставляйте один блок, не два.
По параметрам cache_peer: sourcehash нужен для того, чтобы зарубежный сервер для маршрутизации выбирался исходя из IP клиента (раскидывать клиентов более или менее равномерно). Если сервер один, sourcehash нужно убрать.
ssl можно убрать, но тогда шифрования между серверами не будет, со всеми вытекающими. Это если у вас нет домена и HTTPS.
sslflags=DONT_VERIFY_PEER не обязателен, но иногда squid перекрывает, и он начинает терять подключение между серверами. Этот флаг помогает. По принципу Неуловимого Джо, MITM между проксями мы не боимся. Если вы убрали ssl, то и sslflags убираем тоже.
Кеш, откровенно говоря, можно отключить, удалив строчки с 39 по 44. Он все равно ничего не делает для HTTPS трафика. Сэкономим место на диске и в памяти. Решение ваше.
Всю остальную магию оставляем без изменений.
Сервер 2 (и последующие серверы, к которым ходит первый):
https_port 444.333.222.111:12345 cert=/etc/letsencrypt/live/domain2.com/fullchain.pem key=/etc/letsencrypt/live/domain2.com/privkey.pem
https_port [9999:9999:9999::2]:12345 cert=/etc/letsencrypt/live/domain2.com/fullchain.pem key=/etc/letsencrypt/live/domain2.com/privkey.pem
http_port 444.333.222.111:12346
http_port [9999:9999:9999::2]:12346
# Access control lists (ACLs)
acl A_proxy src domain1.com
acl B_proxy src 111.222.333.444
# Access rules
http_access allow A_proxy
http_access allow B_proxy
http_access deny all
cache allow all
cache_dir aufs /tmp/squid 1000 16 256
cache_mem 256 MB
memory_cache_mode always
maximum_object_size 4096 KB
maximum_object_size_in_memory 256 KB
# Additional settings
max_filedescriptors 65535
pinger_enable onЗдесь логика первых 5 строчек та же, что и выше: меняем IP, опционально убираем HTTP или HTTPS, опционально убираем IPV6.
Важно, что здесь в строчках 8 и 9 мы разрешаем доступ по IP с первого сервера в РФ. Можно разрешить с домена, но я предпочитаю перебдеть и разрешить оба варианта.
Кеш, аналогично, можно отключить (16-21).
Конфигурация сервера 2 на этом закончена, но нам все еще нужен список заблокированных доменов для сервера 1.
5. Добываем список доменов для маршрутизации
Для самых ленивых я выкладываю сегодняшний squid-whitelist-zones.conf
Этот файл нам нужен на первом сервере в РФ. Кладем по пути из конфигурации в строчке 15: acl primary dstdomain "/etc/squid/squid-whitelist-zones.conf"
Обновлять я его не буду, так что собирайте лучше свой (или ищите готовый для squid). Делать это будем на забугорном сервере, чтобы избежать вмешательства РКН.
Для сборки, воспользуемся antizapret-pac-generator-light:
mkdir /opt/antizapret-pac-generator-light
cd /opt/antizapret-pac-generator-light
git clone https://bitbucket.org/anticensority/antizapret-pac-generator-light/src/master/ .
mkdir /etc/nginx/proxy/Отредактируем файл doall.sh, чтобы он копировал готовый .conf файл для раздачи через nginx:
nano doall.sh
#!/bin/bash
set -e
HERE="$(dirname "$(readlink -f "${0}")")"
cd "$HERE"
./update.sh
./parse.sh
./process.sh
cp /opt/antizapret-pac-generator-light/result/squid-whitelist-zones.conf /etc/nginx/proxy/squid-whitelist-zones.conf
chown www-data:root /etc/nginx/proxy/squid-whitelist-zones.confДобавляем в cron crontab -e:
0 0 * * * /opt/antizapret-pac-generator-light/doall.shРазрешаем выполнение:
chmod -R +x /opt/antizapret-pac-generator-lightЕсли каких-то доменов в стандартной конфигурации будет не хватать (или вы, например, хотите добавить домены, которые блокируют IP РФ), их можно добавить в файл /opt/antizapret-pac-generator-light/config/include-hosts-custom.txt, например:
twitter.com
twimg.com
x.com
chatgpt.comТеперь, файл нужно донести до первого сервера. Тут нам и пригодится nginx. Редактируем /etc/nginx/sites-enabled/default
Нам нужно добавить папку с файлом. В https блок добавляем:
location /cheburnet/ {
alias /etc/nginx/proxy/;
allow all;
}После чего nginx перезапускам service nginx restart
Теперь на первом сервере, раскидывающем клиентов, ежедневно забираем новый файл. Я предпочитаю для этого использовать свой скрипт. Создаем его /etc/squid/update.sh:
#!/bin/bash
set -e
# Download the latest whitelist
wget -O /etc/squid/squid-whitelist-zones.conf https://domain2.com/cheburnet/squid-whitelist-zones.conf
# Remove all domains ending with .ua
sed -i '/\.ua$/d' /etc/squid/squid-whitelist-zones.conf
# Manually remove problematic domains that are subdomains
sed -i '/\.sex2\.kirov\.life$/d' /etc/squid/squid-whitelist-zones.conf
sed -i '/\.sex\.kirov\.life$/d' /etc/squid/squid-whitelist-zones.conf
# Reload Squid configuration with low priority
nice -n 19 squid -k reconfigureСкрипт подчищает несколько доменов, которые засоряют выдачу service squid status
Не забываем указать свой реальный домен в строчке 6. Путь должен открываться из браузера. Если вам нужны домены в зоне UA, удаляем строчку 9. Разрешаем выполнение chmod +x /etc/squid/update.shи закидываем в cron crontab -e:
0 1 * * * /etc/squid/update.shСкрипт будет забирать файл на первый сервер через час после того, как его сформирует второй. С поправкой на то, что у них один часовой пояс. В противном случае, разницу надо будет посчитать.
Для первого запуска и тестов, оба скрипта запускаем руками, не дожидаясь часа X.
На втором:
./opt/antizapret-pac-generator-light/doall.shНа первом:
./etc/squid/update.shНа первом сервере должен появиться файл /etc/squid/squid-whitelist-zones.conf на 3+ мегабайт.
Второй скрипт применяет все настройки, что мы прописывали в squid.conf. На будущее, это делается либо запросом к самому squid перечитать конфигурацию squid -k reconfigure, либо перезапуском сервиса: service squid restart
Кроме того, для экспериментов у squid есть еще squid -k check, который проверит ваш конфиг не роняя прокси.
Проверяем service squid status
В идеале, мы хотим видеть относительно чистый лог:
squid.service - Squid Web Proxy Server
Loaded: loaded (/usr/lib/systemd/system/squid.service; enabled; preset: enabled)
Active: active (running) since Sun 2024-12-15 17:02:24 MSK; 47min ago
Dec 15 17:02:24 server1.com squid[1989315]: Accepting HTTP Socket connections at conn9 local=[censored]:censored remote=[::] FD 18 flags=9
listening port: [censored]:censored
Dec 15 17:02:24 server1.com squid[1989315]: Done reading /tmp/squid swaplog (1468 entries)
Dec 15 17:02:24 server1.com squid[1989315]: Finished rebuilding storage from disk.
1468 Entries scanned
0 Invalid entries
0 With invalid flags
1468 Objects loaded
0 Objects expired
0 Objects canceled
0 Duplicate URLs purged
0 Swapfile clashes avoided
Took 0.02 seconds (73499.22 objects/sec).
Dec 15 17:02:24 server1.com squid[1989315]: Beginning Validation Procedure
Dec 15 17:02:24 server1.com squid[1989315]: Completed Validation Procedure
Validated 1468 Entries
store_swap_size = 44888.00 KB
Dec 15 17:02:24 server1.com squid[1989315]: Configuring Parent server2.com
Dec 15 17:02:24 server1.com squid[1989315]: Configuring Parent server3.com
Dec 15 17:02:24 server1.com squid[1989315]: Starting new basicauthenticator helpers...
current master transaction: master54
Dec 15 17:02:24 server1.com squid[1989315]: helperOpenServers: Starting 1/20 'basic_ncsa_auth' processes
current master transaction: master54
Dec 15 17:02:25 server1.com squid[1989315]: storeLateRelease: released 0 objectsВсе серверы должны быть active (running). Также сервер 1 в РФ должен видеть "родителей": Configuring Parent <...>
Если это так, то прокси можно пробовать.
Иногда подключение между проксями может умирать:
Dec 15 17:50:02 domain1.com squid[1989315]: ERROR: Connection to domain2.com failed
current master transaction: master9185Само по себе, это не проблема, если подключение после этого восстанавливается. Проблема - это когда подключение умирает вообще:
Dec 15 16:58:28 domain1.com squid[12847]: Detected DEAD Parent: domain2.com
current master transaction: master376639Обычно это означает, что зарубежный сервер (parent) упал или по какой-то причине не пускает к себе первый сервер. Если проблема всплывает после первой настройки, то проверяем, разрешили ли мы доступ от сервера 1 к серверу 2 в настройках squid и в файерволле и применили ли вообще новую конфигурацию. Смотрим логи. Проверяем, что на сервере РФ есть корректный squid-whitelist-zones.conf
Иногда, сервер умирает вообще просто потому что. Я заметил, что такое случается реже (или не случается вовсе), если для подключения от сервера к серверу использовать IP вместо домена.
В целом, проблемы с подключением изредка случаются, но особых неудобств не доставляют. Как правило, чинятся сами. В любой непонятной ситуации - перезагружайте сервисы squid, а если не поможет - сами сервера.
Пример конфигурации FoxyProxy:
6. Что еще можно сделать:
Все здесь будет коротко и тезисно, потому что либо гуглится, либо экспериментально.
Как я уже писал выше, раз уж у нас есть nginx, можно развернуть x-ui с websocket и grpc. Само-собой, это делается на забугорных серверах. Очень коротко:
Ставим x-ui, добавляем inbound, слушаем 127.0.0.1 с protocol vless и transmission grpc на произвольном порту (например, 8888). Service Name - это ваш путь для nginx. Таким образом, в nginx идет:
location /ServiceName {
if ($content_type !~ "application/grpc") {
return 404;
}
client_max_body_size 0;
client_body_buffer_size 512k;
grpc_set_header X-Real-IP $remote_addr;
client_body_timeout 1w;
grpc_read_timeout 1w;
grpc_send_timeout 1w;
grpc_pass grpc://127.0.0.1:8888;
}Аналогично для websocket:
Добавляем inbound, слушаем 127.0.0.1 с protocol vless и transmission websocket на произвольном порту (например, 8889). Path - это ваш путь для nginx. В nginx идет:
location /SecretPath {
if ($http_upgrade != "websocket") {
return 404;
}
proxy_pass http://127.0.0.1:8889;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_read_timeout 52w;
}В x-ui для обоих inbound включаем external proxy: TLS | вашдомен.com | 443, security: none.
Настроить ежедневное создание отчетов ИЛИ отключить логгинг squid.
Отключаем логи: на первом сервере в файле squid.conf строчку
access_log daemon:/var/log/squid/access.log hasRequestМеняем на
access_log none... либо настраиваем отчеты в Telegram (тоже РФ сервер):
Устанавливаем calamaris: apt install calamaris
Создаем скрипт (написано на коленке ChatGPT, но работает):
nano /etc/squid/send_squid_report_telegram.sh
Меняем строчки 4 и 6.
#!/bin/bash
set -x # Enable command tracing
# Telegram Bot API Token
TOKEN="ваш:токен"
# Chat ID where to send the report
CHAT_ID="чатид"
# Generate Calamaris report in HTML format and save to a temporary file
REPORT=$(mktemp --suffix=".html")
calamaris -a --output-format html /var/log/squid/access.log.1 > "$REPORT"
# Generate plain text Calamaris report for parsing
TEXT_REPORT=$(mktemp)
calamaris -a /var/log/squid/access.log.1 > "$TEXT_REPORT"
# Extract Total Requests
TOTAL_REQUESTS=$(awk '/^Total amount:/ && /requests/ {print $NF}' "$TEXT_REPORT")
# Extract Total Bandwidth (in bytes)
TOTAL_BANDWIDTH=$(awk '/^Total Bandwidth:/ {gsub(/K$/, "", $NF); print $NF * 1024}' "$TEXT_REPORT")
if [[ "$TOTAL_BANDWIDTH" =~ ^[0-9]+$ ]]; then
HUMAN_READABLE_BANDWIDTH=$(echo "$TOTAL_BANDWIDTH" | awk '{printf "%.2f MB", $1 / 1024 / 1024}')
else
HUMAN_READABLE_BANDWIDTH="Data not available"
fi
# Extract Outgoing Requests by Destination (IPs, DIRECT, and percentage)
OUTGOING_STATUS=$(awk '/^# Outgoing requests by destination/,/^Sum/ {
if ($1 != "#" && $1 != "Sum" && $1 != "------------------------------")
if ($1 != "neighbor") print "- " $1 ": " $3 "%"
}' "$TEXT_REPORT")
# Fallback for extraction
if [ -z "$TOTAL_REQUESTS" ]; then TOTAL_REQUESTS="Data not available"; fi
if [ -z "$HUMAN_READABLE_BANDWIDTH" ]; then HUMAN_READABLE_BANDWIDTH="Data not available"; fi
if [ -z "$OUTGOING_STATUS" ]; then OUTGOING_STATUS="Data not available"; fi
# Message with key metrics
MESSAGE="Here's a summary of the daily Squid proxy report:
- **Total Requests**: $TOTAL_REQUESTS
- **Total Traffic**: $HUMAN_READABLE_BANDWIDTH
Outgoing Requests by Destination:
$OUTGOING_STATUS
Full report attached."
# Send the HTML report as a document with proper filename
curl -s -X POST \
"https://api.telegram.org/bot$TOKEN/sendDocument" \
-F chat_id="$CHAT_ID" \
-F document="@$REPORT;filename=calamaris_report.html" \
-F caption="$MESSAGE"
# Clean up temporary files
rm "$REPORT" "$TEXT_REPORT"Разрешаем запуск chmod +x /etc/squid/send_squid_report_telegram.sh
Настраиваем запуск скрипта после logrotate:
nano /etc/logrotate.d/squid
#
# Logrotate fragment for squid.
#
/var/log/squid/*.log {
daily
missingok
notifempty
compress
delaycompress
maxsize 100M
rotate 2
nocreate
sharedscripts
prerotate
test ! -x /usr/sbin/sarg-reports || /usr/sbin/sarg-reports daily
endscript
postrotate
test ! -e /run/squid.pid || test ! -x /usr/sbin/squid || /usr/sbin/squid -k rotate
/etc/squid/send_squid_report_telegram.sh
endscript
}Добавить секьюрности в конец конфига:
forwarded_for delete
httpd_suppress_version_string on
via offНе отдавать на запрос без логина и пароля 407.
Теоретически, немного поможет от active probing. Однако, такая конфигурация ломает доступ по IP без пароля (поэтому его из конфига я убрал).
Кроме того, такая конфигурация может быть небезопасна, потому что мы пускаем всех без разбору, а потом рубим подключение тем, кто зашел без пароля. Отклонять их до входа безопаснее, но такой подход отдает 407 из-за логики работы Squid, что раскрывает существование прокси.
В любом случае, это защита от совсем уж тупого бота, который ищет определенную ошибку. Потому что существование прокси все равно читается:
* CONNECT tunnel: HTTP/1.1 negotiated
* allocate connect buffer
* Establish HTTP proxy tunnel to 2ip.ru:443
> CONNECT 2ip.ru:443 HTTP/1.1
> Host: 2ip.ru:443
> User-Agent: curl/8.5.0
> Proxy-Connection: Keep-Alive
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS alert, close notify (256):
* Proxy CONNECT aborted
* Closing connection
* Send failure: Connection reset by peer
curl: (56) Proxy CONNECT abortedДля использования этого костыля, поменять нужно этот блок:
<...>
# Authentication settings
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/htpasswd
auth_param basic realm proxy
# Access control lists (ACLs)
acl primary dstdomain "/etc/squid/squid-whitelist-zones.conf"
acl hasRequest has request
acl unauthenticated proxy_auth NONE # ACL for unauthenticated users
access_log daemon:/var/log/squid/access.log hasRequest
# Access rules
# Allow unauthenticated users to proceed without authentication but redirect to a different response or location
http_access allow unauthenticated
# Allow authenticated users
http_access allow !unauthenticated # Allow any user who provides credentials (this won't trigger 407 for unauthenticated)
http_access deny all # Deny all others
# Redirect unauthenticated users to another response or URL
http_reply_access allow unauthenticated
deny_info TCP_RESET unauthenticated # or use a custom error page
# Cache settings
<...>С прямым доступом по location в nginx есть смысл что-то сделать. В идеале, разместить правдоподобные медиа-файлы, чтобы оправдать трафик. Если готовы быть тупым прокси для какого-нибудь сайта, то можно завернуть его целиком (не рекомендую, но как пример).
location / {
proxy_pass https://vk.com/;
}Заблокировать РКН:
Я собрал скрипт для блокировки сомнительных адресов РФ. Теоретически, он слегка подпортит жизнь РКН. Я скажу честно, я даже не уверен, что он работает. По факту, это больше для души. Маскировке это только помешает:
nano /usr/local/bin/update_blocklist.sh
#!/bin/bash
# Variables
BLACKLIST_URL="https://raw.githubusercontent.com/C24Be/AS_Network_List/refs/heads/main/blacklists/blacklist.txt"
BLACKLIST_FILE="/tmp/blacklist.txt"
UFW_BEFORE_RULES="/etc/ufw/before.rules"
BACKUP_FILE="/etc/ufw/before.rules.bak"
# Function to validate IPv4 CIDR
validate_cidr() {
local cidr="$1"
if [[ "$cidr" =~ ^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{1,2}$ ]]; then
ip="${cidr%/*}"
mask="${cidr#*/}"
if [[ $mask -ge 0 && $mask -le 32 ]]; then
return 0 # Valid CIDR
fi
fi
return 1 # Invalid CIDR
}
# Download the blacklist
echo "Downloading blacklist from $BLACKLIST_URL..."
wget -q -O "$BLACKLIST_FILE" "$BLACKLIST_URL"
if [ $? -ne 0 ]; then
echo "Error: Failed to download blacklist." >&2
exit 1
fi
# Backup the original before.rules
if [ ! -f "$BACKUP_FILE" ]; then
echo "Backing up $UFW_BEFORE_RULES to $BACKUP_FILE..."
cp "$UFW_BEFORE_RULES" "$BACKUP_FILE"
fi
# Prepare new rules for BLACKLIST
BLACKLIST_RULES="/tmp/blacklist.rules"
{
echo "# BLACKLIST rules"
echo ":BLACKLIST - [0:0]"
while IFS= read -r ip; do
[[ "$ip" =~ ^#.*$ || -z "$ip" ]] && continue # Skip comments and empty lines
if validate_cidr "$ip"; then
echo "-A BLACKLIST -s $ip -j DROP"
echo "-A BLACKLIST -d $ip -j DROP"
else
echo "Skipping invalid CIDR: $ip" >&2
fi
done < "$BLACKLIST_FILE"
echo "# Apply BLACKLIST chain"
echo "-A ufw-before-input -j BLACKLIST"
echo "-A ufw-before-output -j BLACKLIST"
echo "-A ufw-before-forward -j BLACKLIST"
} > "$BLACKLIST_RULES"
# Integrate blacklist.rules into before.rules
echo "Integrating blacklist rules into $UFW_BEFORE_RULES..."
cp "$BACKUP_FILE" "$UFW_BEFORE_RULES"
sed -i '/# End required lines/ r /tmp/blacklist.rules' "$UFW_BEFORE_RULES"
# Reload UFW
echo "Reloading ufw to apply changes..."
ufw reload
# Clean up
rm "$BLACKLIST_RULES"
echo "Blacklist updated successfully!"Разрешаем выполнение: chmod +x /usr/local/bin/update_blocklist.sh
Добавляем в cron crontab -e:
0 0 * * * /usr/local/bin/update_blocklist.shУже упоминалось выше, но всю коммуникацию между серверами стоит разрешить в файеровлле ufw и в настройках самого squid.
ufw allow from и ufw allow to на каждом сервере к каждому другому серверу.
В squid.conf на забугорных серверах разрешаем сервер РФ по всем его адресам:
acl A_proxy src domain1.com
acl B_proxy src 111.222.333.444
acl С_proxy src [9999:9999:9999::2]
http_access allow A_proxy
http_access allow B_proxy
http_access allow С_proxy
http_access deny allНа этом, пожалуй, все.
Комментарии (123)
wassup666
15.12.2024 18:20Не раскрыта тема зачем васяносквид с diladele.
nidalee Автор
15.12.2024 18:20Обычный сквид не умеет https: его нужно либо собирать из сорцов
--enable-ssl-crtd --with-openssl, либо ставить с левой репы.This project provides scripts needed to recompile modern version of Squid on Ubuntu 22.04 LTS with support for HTTPS filtering and SSL inspection. Results of the compilation are available in the public repos hosted by diladele.com.
UP: дописал.
UP2: поправочка, в 24.04 уже есть squid-openssl версии 6.6. В целом, не вижу вреда от левой репы, раз она актуальна для более старых систем. В новые все равно встанет из родной.
sena
15.12.2024 18:20Что значит "Обычный сквид не умеет https"? Всё он умеет. Он не сможет заглядывать внутрь зашифрованного трафика и кэшировать его, но пробрасывать его будет без проблем.
Жонглирование сертфикатами имеет свои последствия, если удалённый сквид взломают, то злоумышленник получит доступ ко всему трафику через прокси, включая пароли.
Спрашивается, зачем так усложнять конфигурацию, чтобы в итоге серьёзно ослабить свою безопасность. Чтобы что?
Как минимум следует указать о такой опасности, чтобы народ не тянул бяку без понимания, что он делает. Всех предупреждаю, если вы глубоко не понимаете, о чём речь, то не пользуйтесь squid-openssl, описанным в статье.
Вполне достаточно простого squid, это будет гораздо безопасней и проще в настройке.
Хотелось бы добавить, не пользуйтесь также случайными инструкциями из Интернета.
sena
15.12.2024 18:20ЗЫ Посмотрел ещё раз конфиги - не уверен на 100%, но похоже я неправ и автор использует squid-openssl для заворачивания https в https, а не для SSL bumping. Прошу пояснений, я верно понял?
nidalee Автор
15.12.2024 18:20Вполне достаточно простого squid, это будет гораздо безопасней и проще в настройке.
По поводу ssl-bumping уже написал, а squid без openssl не понимает директиву https_port, только и всего. Собственно, я раньше им и пользовался, пока не задумался, насколько нежизнеспособная затея - гонять plain http и надеяться, что его не найдут.
Сертификатами мы не жонглируем и трафик не расшифровываем.
sena
15.12.2024 18:20Спасибо, теперь понял. А то я начал читать для чего используется squid-ssl, а у него везде в описании стоит что он предназначен для ssl-bumping.
Но у меня ещё вопрос, зачем всё-таки нужен второй прокси? Чтобы скрыть что первый прокси за границей и от клиентов не было прямых коннектов за границу?
По поводу плагина, здесь пишут что достаточно выставить опцию network.negotiate-auth.allow-proxies, тогда плагин не нужен.
ЗЫ интересно как работает https прокси - шифрует зашифрованный трафик по второму кругу?
Uporoty
15.12.2024 18:20Но у меня ещё вопрос, зачем всё-таки нужен второй прокси?
Чтобы не гонять трафик до российских ресурсов через заграницу, а выпускать его сразу с российского сервера
Чтобы со стороны фильтрующих коробочек у провайдера был видно, что пользователь всегда подключается к российскому серверу - в этом случае, как показывает практика, фильтрация по протоколам происходит не так активно.
интересно как работает https прокси - шифрует зашифрованный трафик по второму кругу
К сожалению да. Поэтому в теория этот вариант уязвим к детектированию TLS-in-TLS
Destructive
15.12.2024 18:20Чтобы со стороны фильтрующих коробочек у провайдера был видно, что пользователь всегда подключается к российскому серверу - в этом случае, как показывает практика, фильтрация по протоколам происходит не так активно.
У "коробочек" провайдера есть какая-то принципиальная разница между тем, кто стучится забугор — домашний ПК на Windows или сервак на Linux?
Uporoty
15.12.2024 18:20если сервак на Linux стоит у абонента, то разницы нет, блокироваться будет одинаково.
а вот если сервак стоит в дата-центре, то разница большая - там часто этих коробочек или нет вообще, или они работают не настолько яростно (например, на них не распространяются региональные блокировки, как недавно в Дагестане).
sena
15.12.2024 18:20Чтобы не гонять трафик до российских ресурсов через заграницу, а выпускать его сразу с российского сервера
Зачем российский трафик гонять через прокси, если можно напрямую? Это же можно настроить через Automatic proxy configuration URL, он для этого предназначен. Ну или просто через No proxy for *.ru в браузере
Uporoty
15.12.2024 18:20PAC-ом вы можете прописать правило для *.ru, но у вас не получится туда запихать все GeoIP, и в итоге трафик до серверов, которые находятся в РФ, но висят на не .ru/.su/.рф доменах пойдет все равно через забугор.
nidalee Автор
15.12.2024 18:20Но у меня ещё вопрос, зачем всё-таки нужен второй прокси? Чтобы скрыть что первый прокси за границей и от клиентов не было прямых коннектов за границу?
Во-первых, да, чтобы клиенты ходили в одну точку, а там уже серверы между собой ими жонглировали.
Во-вторых, первый сервер в РФ забирает у клиента задачу настраивать маршрутизацию. То есть клиент настраивается один раз и навсегда. Дальше маршрутизация настраивается админом на сервере, и клиентам об этом задумываться вообще не нужно. Это, во-первых, проще развернуть на множество клиентов, а во-вторых убирает проблемы совместимости: если софт умеет прокси, то он будет ходить куда нужно и как нам нужно, потому что он вообще не задумывается о маршрутизации.
Kil1J0y
15.12.2024 18:20А я абсолютно все скрыл за haproxy
Вот пример фронта
frontend tcp
bind *:80,*:443#,*:853
mode tcp
option tcplog
tcp-request inspect-delay 10s #5s
tcp-request content capture req.ssl_sni len 10
tcp-request content accept if { req_ssl_hello_type 1 } or !{ req_ssl_hello_type 1 }
use_backend vless if { req.ssl_sni -i ваш домен } #работает только с tls без reality маскировки под другой домен нет
# use_backend adh if { req.ssl_sni -m end .ваш домен } { req.ssl_sni -i ваш домен }
# use_backend cloud if { req.ssl_sni -i ваш домен}
use_backend wstunnel if { req.ssl_sni -i ваш домен}
# use_backend dot if { dst_port 853 }# лютое палево
use_backend openvpn if { req.ssl_sni -i ваш домен }
default_backend tcp_to_https
# default_backend vless #Работает с reality
use_backend tcp_to_http if { dst_port 80 }
#use_backend tcp_to_https if { dst_port 443 }
#->-----tcp-to-https------------------------
backend tcp_to_http
mode tcp
server https 127.0.0.1:8080 send-proxy-v2 #send-proxy-v2-ssl-cn
backend tcp_to_https
mode tcp
server https 127.0.0.1:8443 send-proxy-v2 #send-proxy-v2-ssl-cn
frontend https
bind 127.0.0.1:8080 accept-proxy
bind 127.0.0.1:8443 accept-proxy ssl crt /etc/ssl/haproxy/ alpn h2,http/1.1 strict-sni
acl secure dst_port eq 443
http-response set-header Strict-Transport-Security "max-age=16000000; includeSubDomains; preload;"
redirect scheme https if !{ ssl_fc }
# http-request return status 200 content-type text/plain lf-string "%[path,field(-1,/)].${ACCOUNT_THUMBPRINT}\n" if { path_beg '/.well-known/acme-challenge/' }
use_backend dns_query if { ssl_fc_sni -i ваш домен } { path /dns-query } { path_beg /dns-query/ } # { ssl_fc_alpn h2 }
use_backend http_adh if { ssl_fc_sni -i ваш домен } { path /ваш путь } || { path_beg /ваш путь/ }
Могут быть ошибки. Это лишь первый набросок который был под рукой
nidalee Автор
15.12.2024 18:20Да, я первым пробовал HAProxy, но мне не удалось завести авторизацию по IP и по логин:пароль.
lubagov
15.12.2024 18:20У меня сильно проще схема, и для другого. Я в Украине, и мне бывает нужно пользоваться российскими сайтами с российского IP. Еще что то. Тут нет такой глобальной блокировки как в РФ, и такого маразма, люблй прокси или VPN работает. Ну и некоторые сервисы в РФ вообще не хотят работать с зарубежными IP.
Есть 2 сервера, один в рф, на нем Squid, без шифрования, на самом деле шифрование не так уж и нужено, т. к. используется запрос CONNECT, и если само соединение подразумевает шифрование, то прокси просто как бы через себя пробросит порт, в общем в сеть не уйдет никакой конфиденциальной информации больше, чем если б прокси вообще небыло, разве что злоумышленник сможет узнать а куда именно (адрес) я через прокси ходил перехватывая мой трафик гдето по середине (ip адрес и порт, для подключения то открытым текстом передается).
Ну, а на втором сервере в общем-то ничего нет, просто через iptables проброшен порт. В админке уже самого сервера разрешено подключение по IP адресу, к проброшенному порту, чтоб я дома со своего провайдера мог получить доступ.
Минус прокси в отличии от VPN есть, он в том, что если нужно проьросить UDP траффик то он не пойдет.
sena
15.12.2024 18:20Без https логин и пароль для подключения к прокси будут же передаваться открытым текстом. Не сильно страшно, но всё-таки неприятно.
И можно пояснить, зачем второй сервер? Разве одного прокси недостаточно?
nidalee Автор
15.12.2024 18:20Да, без активного вмешательства цензора в трафик вполне подойдет проксировать CONNECT в HTTP. У нас в любой момент могут прикрутить на ТСПУ скрипт, который будет брать авторизацию из plaintext-http и пытаться достучаться до запрещенки самостоятельно, делая по результатам проверки выводы. ChatGPT такое напишет за пару минут. Рекламу в HTTP вставлять уже не гнушаются, дело за малым.
Uporoty
15.12.2024 18:20Они точно так же могут сходить к вам по TLS и попытаться сделать CONNECT без пароля или с неправильным рандомным паролем, и если сервер ответит им не 405 Method not allowed или 400 Bad Request, а 403 Unauthorized или 407 Proxy Authorization Required, то заблокировать его по IP, потому что на адресе явно находится прокси.
nidalee Автор
15.12.2024 18:20Прокси найдется, это да. Но у них хотя бы не будет однозначного ответа, пускает ли прокси куда не надо.
Uporoty
15.12.2024 18:20Но у них хотя бы не будет однозначного ответа, пускает ли прокси куда не надо.
Их это, к сожалению, волновать уже не будет, просто заблокируют.
nidalee Автор
15.12.2024 18:20Наверное. Есть смысл покумекать, за чем спрятать squid от active probing. Либо научить squid отдавать 400 вместо прокси-кодов...
Dm_Dm
15.12.2024 18:20А зачем вообще отдавать ответ на неправильное сообщение?
nidalee Автор
15.12.2024 18:20Полагаю, что это стандартное поведение прокси-сервера? Чтобы браузер знал, что прокси не просто не существует, а сказал, что пароль неправильный. В целом, нужды в этом нет, в целях маскировки лучше бы избавиться.
DennisP
15.12.2024 18:20Не совсем понятно, чем эта схема лучше банального SSH туннеля с SOCKS проксей?
sena
15.12.2024 18:20А как конечный пользователь будет у себя ssh туннель настраивать? С прокси просто, открыл настройки, ввёл три значения урл, логин, пароль и всё.
А как ходить на российские сайты, которые на Западе заблокированы или заблокированы для Западных айпи уже с российской стороны?
dvrpd
15.12.2024 18:20>А как конечный пользователь будет у себя ssh туннель настраивать
Например, той же переменной среды https_proxy=socks5://127.0.0.1:1080.
Uporoty
15.12.2024 18:20перед этим сначала надо саму SSH-сессию поднять. попробуйте объяснить, например, пенсионерке в преклонном возрасте, как это сделать.
uuger
15.12.2024 18:20добавить скрипт в любой доступный вариант автозагрузки и пусть он занимается поддержанием активной ssh сессии в течение всего аптайма
sena
15.12.2024 18:20Не так-то это просто. Если всё это обернуть в какой-то пакет, то наверное пойдёт, но этот пакет нужно ещё поставить, потом добавить желательно зашифрованный ключ ssh с правильными правами.
Потом нужно на сервере это всё правильно ограничить, чтобы кроме прокси больше ничего на сервере не было доступно, но это вроде бы несложно.
Отключить для российских сайтов можно и прямо в чёрном списке в настройках браузера.
Потом желательно какой-то способ запустить/остановить проксю.
Для Линукса я это ещё представляю как сделать, для Виндоса уже нет, но наверное можно. А как быть с Андроидом?
DennisP
15.12.2024 18:20Исхожу из того, что конечный пользователь и админ прокси это одно лицо. Если надо всё настроить для далекого от сетевых технологий человека, то да, это не самый хороший вариант
Очевидно, что для этого туннель должен быть на сервер в РФ, разве в случае прокси что-то меняется?
AdVv
15.12.2024 18:20Если вам не нужно кэширование, то вместо squid можно использовать https://github.com/SenseUnit/dumbproxy
Если я правильно понимаю схему, то можно вместо местного прокси использовать функционал расширения https://github.com/anticensority/runet-censorship-bypass, которое умеет брать список заблокированных сайтов и заворачивать в прокси только их.
Uporoty
15.12.2024 18:20Если вам не нужно кэширование, то вместо squid можно использовать https://github.com/SenseUnit/dumbproxy
У dumbproxy кстати есть большое преимущество по сравнению со squid: он умеет защищаться от active_probing'а с помощью hidden_domain
Psychosynthesis
15.12.2024 18:20VLESS может работать как прокси, возни с этим решением кратно меньше, ключи продаются на каждом углу.
А, и да, у всех решений формата прокси главный минус — за пределами браузера не каждая прога это нормально переваривает. Например у дискорда разрабы криворукие, там просто хз как прокси указать, есть какие-то извраты с патчем библиотек, но они не всегда работают.
nidalee Автор
15.12.2024 18:20Все верно, UDP не будет. Но я пользуюсь такой связкой без него уже года 2 и первое, что мне пришлось обходить какими-то костылями - это как раз Discord. Для ютуба и всей прочей запрещенки в браузере прекрасно подходит прокси.
Что касается VLESS, то я ярый адепт selfhosted, поэтому ключи на каждому углу меня не очень привлекают. Плюс, здесь один раз накрутил на стороне сервера - и пользуешься, где хочешь. Настроить по телефону родственнику прокси тоже на порядки проще, чем условный nekoray. Это если вы, конечно, не предлагаете на том же сервере открыть доступ к порту "прокси" VLESS-клиента. Такое я не пробовал, наверное взлетит, вопрос только что там с авторизацией.
Uporoty
15.12.2024 18:20В этом плане все сейчас гораздо проще стало - вместо Nekoray с действительно сложным для новичков интерфейсом, теперь есть Hiddify, в котором при установке надо выбрать из списка страну (чтобы автоматически применялись маршруты напрямую), а после установки нужно просто нажать плюсик и вставить ссылку на подписку (с которой он ещё потом сможет автоматически обновлять список серверов), после чего вся работа с прокси будет сводится к нажатию огромной красивой кнопки "Подключиться". Справится даже пенсионер.
nidalee Автор
15.12.2024 18:20Теоретически - да. На практике, тут в соседней теме человек пишет, что у него "на android hiddify работает, а под виндой все идёт мимо него". Я товарищам и VPN раздаю, через тот самый hiddify / v2rayNG по QR-кодам, и хочу сказать, что вопросов ко мне и по настройке, и к стабильности там сильно больше, чем вопросов по прокси (по крайней мере было, пока я с tcp vless не перешёл на grpc).
Uporoty
15.12.2024 18:20Там человек писал про не про Винду, а про Linux, и там это действительно проблема.
Проблема в том, что в Линухе нет единого стандарта централизованного хранения настроек прокси на уровне всей системы, там каждый дистрибутив/DE изобретает свой велосипед. Есть, конечно, env'ы, которые понимает большинство приложений, но понятно дело, что это уже не во власти прокси-клиента, особенно для уже запущенных приложений.
Uporoty
15.12.2024 18:20и VPN раздаю, через тот самый hiddify / v2rayNG
Почему VPN? Это именно что прокси
по крайней мере было, пока я с tcp vless не перешёл на grpc
Вот это что-то очень странное, потому что grpc транспорт испокон веков считается очень кривым и использовать его советуют только в совсем безвыходных случаях (там у вас тот же vless и тот же tcp, только оно все ещё в один слой инкапсулируется).
nidalee Автор
15.12.2024 18:20Вот это что-то очень странное, потому что grpc транспорт испокон веков считается очень кривым
Ох, у меня жизнь разделилась на "до grpc" и "после grpc". Пинг по hiddify упал в 2 раза, по v2rayNG - в 3. И сервера больше не отваливаются со странной ошибкой "io read write on closed pipe". Раньше стабильно раз в неделю что-то подкручивал и перезагружал, сейчас уже 2 недели как "ни единого разрыва".
Uporoty
15.12.2024 18:20Случайно Reality на сервере не используете? Если да, то меняйте домен маскировочного сервера, дело в нем (он либо медленный, либо далеко, либо просто вас не любит и периодически перестает вам отвечать). Либо вы натыкаетесь на какой-то системный лимит количества открытых подключений.
В вашем случае разница между голым VLESS и VLESS+gRPC - что в gRPC соединения мультиплексируются, то есть переиспользуется одно TCP-соединение до прокси для нескольких соединений от клиента к серверу назначения. Поэтому и "пинг" (меньше хендшейков), и в случае Reality меньше тычков в сторону маскировочного сервера. Но есть и недостаток - больше оверхед на саму передачу данных, и не работает XTLS-Vision.
Okeu
15.12.2024 18:20В этом плане все сейчас гораздо проще стало
мне тут вообще показывали шайтан-машину:
клиент амнезии умеет так: пишешь айпишник своего сервера (например VPS)
вписываешь юзера и пароль для входа по ssh, выбираешь какой прокси/впн хочешь - и клиент сам топает куда надо, качает и ставит что надо. После этого остается только пользоваться. Я не смотрел, конечно что он там по настройкам на самой тачке делает (есть ли какая-то настройка фаера и т.д.)
Но чел так себе vless впилил на VPS'ке, вроде даже работает)nidalee Автор
15.12.2024 18:20Амнезия - это хорошо, но есть ряд проблем, которые мешают беззаботно жить. Это те, с которыми я столкнулся в первый час. Исправлять их никто не собирается.
Okeu
15.12.2024 18:20Сам я амнезию не использую, но в целом для простых смертных это может быть хорошим подспорьем))
Dm_Dm
15.12.2024 18:20Что за хидифай, какие у него минуса?
GfxMod
15.12.2024 18:20Просто кроссплатформенный клиент для proxy/VPN. Плюсы в сравнении с условным nekoray - включение и выключение в один клик через огромную кнопку на весь экран. Максимально "для домохозяек". Ну, или для тех, кто ценит свое время.
Минусы (субъективно) - Hiddify склонен капризничать и отваливаться по любому поводу. В отдельных случаях ещё и может порядочно так систему поломать. Ну и количество настроек, конечно, не идёт ни в какое сравнение с nekoray
phikus
15.12.2024 18:20Максимально "для домохозяек".
Как раз на днях решил попробовать VLESS + Hiddify.
Восторги мне непонятны и хз что там за домохозяйки такие, мне пришлось достаточно долго тыкаться и перебирать настройки, чтобы всё заработало. В отличии от всяких OpenVPN/WG клиентов, где реально всё в 1 клик работало
Amidevi
15.12.2024 18:20Имеется ввиду "максимально для домохозяек" среди VLESS клиентов, вроде всяких Nekobox/nekoray, с первоначальной настройкой надо немножко помучиться зато потом всё сводится к нажатию одной большой кнопки.
А OpenVPN и WG это вообще уже что-то из далёкого беззаботного прошлого, про них давно уже пора забыть.
Uporoty
15.12.2024 18:20у всех решений формата прокси главный минус — за пределами браузера не каждая прога это нормально переваривает
есть tun2socks и куча разных "проксифаеров"
Dm_Dm
15.12.2024 18:20Что за ключи, как их купить, и какие риски?
Psychosynthesis
15.12.2024 18:20В поиске "купить ключ vless" - это доступ к vless-серверу.
После ставите себе любой понравившийся vless-клиент (я Invisible Man Xray использую), в него этот ключ и пользуетесь.
Рисков пока не заметил. Допускаю, что где-нить на горизонте года роскомпозор научится и этот тип прокси блочить.
Оно, по идее умеет и как туннель работать, но на седьмой винде чот этот режим глючит.
Arlekcangp
15.12.2024 18:20Не понятно, чем такой танец с конями лучше обычного vpn? Тем более что полно уже готовых сборок на основе докера. Запустил контейнер, настроил скрипт к iptables и маршрутизацию, и всë. Или же упор именно на возможность логина браузером? Но так для этого вроде как тоже решения были. Интересовался этим еще со времен, когда организации начали заставлять закрывать публичный wifi авторизацией. Думаю с тех пор многое улучшилось. Тогда для настройки они были тяжеловаты, но сейчас то уж должны были подтянуться. Я про схему, когда клиент ломится через wifi в интернет браузером, а его редиректит на форму с авторизацией. Он проходит авторизацию и... А дальше как пожелает админ - кому то отрежут всë кроме детских сайтов, а кого-то через впн пустят. Да, многие из них включали сквид в себя, но настраивались проще. По факту в простейшем случае там просто прописывался маршрут кого куда пускать/не пускать. Точно также можно было прописать идти через vpn.
nidalee Автор
15.12.2024 18:20Не понятно, чем такой танец с конями лучше обычного vpn?
Именно поэтому:
настроил скрипт к iptables и маршрутизацию
Для кого-то, включая меня, возня с iptables и маршрутизацией - это совсем не "и все".
Кроме того, поддержка split tunneling у обычного VPN - это тот еще танец с конями. Та же amnezia под Windows работает кое-как. А гонять через VPN в другой стране весь трафик, включая игры и ОС - идея сомнительная.
Или же упор именно на возможность логина браузером? Но так для этого вроде как тоже решения были.
Упор на максимальную простоту для клиента. Особенно для того, который слова "iptables" и "маршрутизация" не слышал. Друзьям гораздо проще "продать" прокси с логином и паролем. Для некоторых уже даже nekoray - слишком сложно.
Что касается порталов с авторизацией, там вроде сейчас "модно" вообще мимо них ходить по ICMP-туннелям. Хотел настроить в свое время хохмы ради, но я публичными wifi не пользуюсь, так что затею забросил.
Uporoty
15.12.2024 18:20чем такой танец с конями лучше обычного vpn
Тем, что обычные VPN такие как IPSec, OpenVPN и Wireguard уже давно детектируются и блокируются, SoftEther и SSTP уязвимы к active probing, а OpenConnect имеет характерный TLS-фингерпринт клиента.
AdVv
15.12.2024 18:20Тем, что можно ( и удобно! ) заворачивать в туннель только то, что нужно. Достаточно, чтоб софт умел работать с прокси. В частности можно прекрасно разруливать на какие сайты браузер будет ходить через прокси, а на какие напрямую.
nidalee Автор
15.12.2024 18:20Уточняю: в предложенной конфигурации, браузер всегда будет ходить через прокси, вопрос только через какой: первый (в РФ) или второй (зарубежный). Чтобы браузер ходил напрямую, ему нужно скармливать правила на стороне клиента, чего мы стараемся избежать.
sena
15.12.2024 18:20Добавить правило *.ru в настройках прокси в браузере не так уж и сложно
Но конечно, с двумя прокси удобней. Хотя больше возни для админа.
nidalee Автор
15.12.2024 18:20Хотя больше возни для админа.
Это смотря насколько админ вовлечен в настройку прокси на клиентах. Если клиентов 10, и у них всех лапки, да еще они в разных частях города - тут не грех и над централизованным решением подумать по усерднее, времени все равно уйдет меньше.
sim31r
15.12.2024 18:20Я через плагин FoxyProxy в Firefox добавлял те ресурсы, для которых нужен прокси. Он сразу и показывает какие запросы идут от браузера.
Dm_Dm
15.12.2024 18:20То есть предлагаете прямо у себя локально вести список компрометирующих сайтов?
nidalee Автор
15.12.2024 18:20Вести у себя локально можно что угодно, пользоваться средствами обхода пока не запрещено. Запрещено предоставлять услуги.
AdVv
15.12.2024 18:20В зависимости от задачи, если речь идет об малом количестве клиентов, то можно обойтись связкой внешний прокси+расширение для браузера. Либо, если клиентов много, поступить так, как сделал автор статьи и самостоятельно рулить списком на внутреннем прокси. И тут речь идет не только о блокировках РКН, но и об обходе блокировок адресов из РФ западными компаниями, intel, lenovo, canva и пр.
Dm_Dm
15.12.2024 18:20А есть какие-то образцовые сборки, которым принято доверять? Вот чтобы сделать по инструкции и минимизировать риски
mysherocker
15.12.2024 18:20Позволяет гонять через себя весь трафик не интересуясь, что там уже заблокировано, а что еще нет.
Не весь, а HTTP. И то, если конкретная программа интересуется конфигурацией HTTP прокси на уровне системы, что далеко не всегда так.
nidalee Автор
15.12.2024 18:20HTTP и HTTPS, прокси работает на уровне браузера, а не системы. Для браузеров, которые не умеют прокси с авторизацией (это, как я понимаю, все браузеры из коробки) придется ставить дополнение. Это не сильно сложно...
Не работает только UDP, но он в браузере не сильно нужен.
Uporoty
15.12.2024 18:20прокси работает на уровне браузера, а не системы
Речь о том, что если программа - не браузер, а что-то другое, то она должна быть в курсе, где в системе взять текущие параметры прокси (в винде для этого ключ в реестре есть), и уметь с ним работать.
nidalee Автор
15.12.2024 18:20Верно, поэтому в первом абзаце статьи речь идёт о браузере :)
Я не пытался прикрутить прокси ни к чему, кроме пары докер-сервисов, там все работало нормально. На Linux, если приложение заботит переменная среды HTTPS_PROXY - этого должно быть достаточно. Под виндой такой роскоши нет.
Thump
15.12.2024 18:20Зачем платить за 2 сервера (относительно мощных) и городить страшный огород, если можно проще добиться не просто того же, а даже лучше на том же техническом уровне без выхода датацентровского IP в РФ (привет капчи и даже блокировки от некоторых РФ сайтов) с помощью расширения Runet Censorship Bypass в свой любимый браузер, который скачает сразу все правила и завернёт в HTTPS-прокси только заблокированные сайты и dumbproxy сразу на зарубежный сервер (или в РФ датацентре без Роскомнадзора)?
Складывается впечатление, что автор решил просто позаморачиваться с настройкой GNU/Linux вместо «домашнего задания» по поиску простого и дешёвого решения абсолютно той же самой задачи.
nidalee Автор
15.12.2024 18:20без выхода датацентровского IP в РФ
Полагаю, что это зависит от сервера, но на серверах регру и аезы у меня не было никаких проблем с сайтами, окромя Reddit: он требует логиниться.
с помощью расширения Runet Censorship Bypass в свой любимый браузер, который скачает сразу все правила и завернёт в HTTPS-прокси только заблокированные сайты
Расширения - это хорошо, но если прокси все же захочется использовать за пределами браузера, то возникает стандартная проблема: через прокси гоняем либо все, либо ничего. Ну либо долго и упорно курим маршруты, если в вашей ОС они вообще предусмотрены и редактируются.
Складывается впечатление, что автор решил просто позаморачиваться с настройкой GNU/Linux вместо «домашнего задания» по поиску простого и дешёвого решения абсолютно той же самой задачи.
Автор действительно любит, скажем так, попердолиться. Любит сделать себе файлопомойку на одного человека, шарилку скриншотов, стример музыки и все такое прочее. Поэтому вместо того, чтобы разбираться, что там нынче из дешевых решений считается кошерным, а что нет, само-собой разумеется для него было сделать свое.
Я никогда не претендовал на единственно верное решение, просто поделился своим, которое работает уже года два безо всяких проблем. Чем больше зоопарк решений, кроме моего - тем лучше. Меньше шансов, что РКН займутся конкретно моим.
Thump
15.12.2024 18:20Полагаю, что это зависит от сервера, но на серверах регру и аезы у меня не было никаких проблем с сайтами
Нет, это зависит от «обезопашенности» российского сайта, на который вы в этой схеме пойдёте с нерезидентного (датацентрового) IP, а это справедливо считается необычным и нормальные живые люди с таких IP действительно не ходят.
Расширения - это хорошо, но если прокси все же захочется использовать за пределами браузера
То прокси у вас уже есть. Всё равно в HTTPS прокси абсолютно что угодно технически не завернуть, тут уж мало кому нужно. IPsec пока работает, маршрутизаторы не отменили.
Фактически это расширение регулярно скачивает готовый PAC-файл и даёт возможность добавлять свои адреса прокси и дополнительные проксируемые адреса. Качаете PAC, добавляете туда свой адрес прокси и вкорячиваете в систему средствами ОС, или скриптуете это. Наверное, существует что-нибудь, что может это делать за вас.
само-собой разумеется для него было сделать свое
Но развернуть свой dumbproxy — то же самое «своё». Списки заблокированных сайтов в этой статье — тот же самый источник, тот же самый разработчик, что и автор расширения и списков сайтов.
Для сборки, воспользуемся antizapret-pac-generator-light
nidalee Автор
15.12.2024 18:20Нет, это зависит от «обезопашенности» российского сайта, на который вы в этой схеме пойдёте с нерезидентного (датацентрового) IP, а это справедливо считается необычным и нормальные живые люди с таких IP действительно не ходят.
Как я уже написал, живу в РФ, регулярно хожу на Госуслуги и прочее, проблемы за два года были только с Reddit. И то, когда я случайно вышел из учетки.
Фактически это расширение регулярно скачивает готовый PAC-файл и даёт возможность добавлять свои адреса прокси и дополнительные проксируемые адреса. Качаете PAC, добавляете туда свой адрес прокси и вкорячиваете в систему средствами ОС, или скриптуете это.
Ну, в предложенном мной варианте это делает squid и antizapret-pac-generator-light. Предлагаемое вами расширение позволяет обойтись без первого прокси, но, во-первых, к таким подключениям в теории больше вопросов, чем к коннектам между датацентрами. А во-вторых, настраивать PAC-файл, маршруты и все такое прочее придется на каждом клиенте в зависимости от назначения. Где-то в переменную прописать, где-то в браузер вбить. Мой вариант просто скармливается клиенту без сопутствующих костылей.
Thump
15.12.2024 18:20Архитектурно так и есть. Либо локальное управление конечным юзером, либо корпоративный squid, который конечные юзеры потрогать не могут.
Настройка расширения минимальна — вам стоит взглянуть.
К этому я бы добавил бесплатный домен третьего уровня и nat-vps, и вдруг решение превращается в скачивание расширения, вбив туда своего адреса proxy $5 в год и эта штука работает вообще без сбоев и управления.
DennisP
15.12.2024 18:20У меня всё проще - банальный SSH Socks на зарубежный сервер и расширение FoxyProxy в браузере. Туда я добавляю интересующие меня сайты в ручном режиме.
nidalee Автор
15.12.2024 18:20Туда я добавляю интересующие меня сайты в ручном режиме.
Да, с этого я и начинал, потом поиграл в Factorio и понял, что автоматизация - наше все.
DennisP
15.12.2024 18:20а насколько просто добавлять домены вручную? Может быть актуально, например, на случай блокировок по айпи или в случае гео-блокировки по инициативе самого ресурса.
nidalee Автор
15.12.2024 18:20а насколько просто добавлять домены вручную?
Их нужно дописать (по одному на строчку) в файл
/opt/antizapret-pac-generator-light/config/include-hosts-custom.txtна сервере, который собирает список, и запустить сборку списка вручную (или подождать полуночи, пока процесс запустится из крона).
sim31r
15.12.2024 18:20Для Ютуба у меня под десяток правил, кроме самого Ютуба там периодически идут запросы к googlevideo.com/
play.google.com/
И подобные.
Naves
15.12.2024 18:20Пролистал статью по диагонали, зацепился глаз за:
1) Уберите бездумную портянку sysctl,
совершенно непонятно зачем там, вроде же docker не используется
net.ipv4.ip_forward = 1net.ipv6.conf.all.forwarding = 12) Squid по умолчанию отправляет конечному серверу адрес клиента, нежданчик.
https://www.squid-cache.org/Doc/config/forwarded_for/
нужно выключить
3) генерить ssh-ключи на сервере, чтобы их скопировать потом клиенту. Не надо так. Private ключ клиента должен генерить сам клиент, и отправлять серверу только свой публичный. У вас здесь все с ног на голову. Еще раз, не надо так. И файл с ssh private key должен быть под паролем.
Лучше привыкнуть сразу делать правильно, чем потом внезапно обнаружить, что какой-то случайный троян обнаружил текстовичок с ssh-ключем, и прошелся по всем сохраненным серверам.
4) Кеши в squid проще выключить совсем, не нужны они сегодня, и там.
опция cache_dir убрать совсем.
Занятно, что РКН мытьем и катаньем повышает грамотность населения в плане работы интернета и проксей. С другой стороны это порождает множество статей, в которых совершенно случайно могут вставить компрометирующие сервисы команды.
nidalee Автор
15.12.2024 18:20Уберите бездумную портянку sysctl,
Да, насчет sysctl у меня самого вопросы. Я, наверное, убирать ее не буду, а просто помечу, что это портянка экспериментальная. Я ее в целом и так задвинул подальше.
Squid по умолчанию отправляет конечному серверу адрес клиента, нежданчик.
Не могу сказать, что я скрываю адрес клиента. Мне, в целом, все равно. Вообще, трафик клиентов я стараюсь не трогать. Но сейчас раскуриваю, какие варианты есть замаскировать squid от active probing, и посмотрю заодно насчет вашей директивы. Наверное, можно и добавить.
Лучше привыкнуть сразу делать правильно, чем потом внезапно обнаружить, что какой-то случайный троян обнаружил текстовичок с ssh-ключем, и прошелся по всем сохраненным серверам.
Потихоньку подбираемся к солонке в столовой. ИМХО, если троян прошелся по вашей системе, то root доступ к несчастному прокси - это одна из ваших наименьших проблем.
опция cache_dir убрать совсем.
В статье упоминается. Как и упоминается умопомрачительная эффективность кеша в целых 0%. Я оставил. :)
Naves
15.12.2024 18:20Вы сильно недооцениваете существование троянов, которые просто сидят и ждут годами появления в системе всяких текстовых файлов с выгрузками 1С и ssh-ключами.
nidalee Автор
15.12.2024 18:20Я думаю, что любой уважающий себя троян начнет с паролей в браузере, после чего проблема ssh-ключей от сервера за 500 рублей в месяц отойдет на второй, если не на третий, план.
Shado_vi
15.12.2024 18:203proxy пробовали?
сколько с 0 вы потратили времени примерно что бы разобраться с конфигами кальмара?
nidalee Автор
15.12.2024 18:203proxy пробовали?
Пробовал, крутится на всех серверах, но как тупой прокси. Тупо пропускает все через себя, если надо.
сколько с 0 вы потратили времени примерно что бы разобраться с конфигами кальмара?
calamaris или squid?
На calamaris я почти не тратил времени, а запряг для этих целей ChatGPT (который его и предложил для мониторинга).
Если squid, то я не помню. Дело было 2 или 3 года назад. День?
AdVv
15.12.2024 18:203proxy умеет работать с https ? Уточню, не пробрасывать https трафик клиента через метод connect через plain-http, а именно шифровать канал между клиентом и прокси ?
Tippy-Tip
15.12.2024 18:20nidalee Автор
15.12.2024 18:20Это расшифровывать.
Naves
15.12.2024 18:20https://github.com/3proxy/3proxy/blob/master/doc/html/plugins/SSLPlugin.ru.html
и для шифрования трафика прокси-сервера
К слову, через обычный SOCKS-proxy запущенный за бугром на произвольном порту facebook иногда не открывается. Видимо TLS-сертификаты проверяются и на рандомных портах, кроме стандартных 443.
Uporoty
15.12.2024 18:20Какая связь между проверкой сертификатов, произвольным портом и неоткрытием фейсбука через прокси?
Naves
15.12.2024 18:20Фейсбук или гугл замедляли не через полную блокировку по IP-адресам, а через проверку сертификатов при установке соединений. При использовании нешифрованного socks-прокси видно на какой сервер идет клиент, и этот запрос точно так же замедлялся, как при прямом подключении без проксей и VPN.
Uporoty
15.12.2024 18:20Фейсбук или гугл замедляли не через полную блокировку по IP-адресам, а через проверку сертификатов при установке соединений
Неа. Сертификат сервера там не проверяется, проверяется только поле SNI из запроса. Достаточно запрещённое строки в SNI от клиента, сертификат сервера уже не играет роли.
При использовании нешифрованного socks-прокси видно на какой сервер идет клиент, и этот запрос точно так же замедлялся, как при прямом подключении без проксей и VPN.
А вот это что-то очень новенькое, потому что раньше РКН полностью игнорировал даже простые не шифрованные прокси (да и до сих пор игнорирует у большинства пользователей), вы первый, кто сообщил об обратном.
Naves
15.12.2024 18:20>проверяется только поле SNI из запроса
да, более правильный термин
>потому что раньше РКН полностью игнорировал даже простые не шифрованные прокси
Сам был сильно удивлен. В прошлом месяце не работало, сейчас простая прокся работает. Скорее всего, мне просто повезло попасть в какой-то тестовый пул провайдеров, и/или моя прокся была в отслеживаемом ДЦ.
zmiuko
15.12.2024 18:20Практика показывает, что вы не интересны РНК, как и весь ваш хранящийся семилетний траф ровно до той поры, пока вы не нарушаете закон. Как только вы начинаете валять дурака, безрассудно веря в свою безнаказанность, представляя что коварный майор замучается разгребать https шлак и, едва ли, не в ручную, то ваши изыски в области запрета на дополнительную шифрацию трафика (а за какой такой целью?) идёт логичным и отягчающим обоснованием (вы зачем наточили нож перед ограблением?). И итого: плюс статья. Специалисту одноцветно чем вы шифруетесь - любой вами выбранный алгоритм обратим. Специалист умеет в теорию информации и выступает в роли инспектора, как в ГИБДД - важен факт, не важно как. Это важно знать и помнить любому уважающему себя инженеру.
MountainGoat
15.12.2024 18:20До этого так же уверенно писали "Помните! Специалист может увидеть из кинескопа, чем вы дома занимаетесь!"
Самой главной уязвимостью в такой системе является возможность придти к автору домой и изъять историю браузера с компа. А поскольку для этого совершенно не требуется, чтобы у автора была эта самая история, браузер или комп, то вот тут и проходит черта проблемы, которая технологически не решается.
rionnagel
15.12.2024 18:20Я бы номинировал на премию "наихудший рабочий способ", если для личного использования. Сервера 2, весь трафик через прокси, на юзерском компе надо надстраивать что-то в каких-то расширениях, вася-сборка сквида. Наверное я просто нелюблю прокси. Но вообще имеет место быть в зависимости от решаемой проблемы. Да, мне больше всего не нравится даже не то, что на компе пользователя надо чё-то настраивать в расширениях, а то, что трафик, который по сути проксировать не нужно всё равно проксируется (хоть и через сервер в рф).
Без впн... я бы предложил через 1 сервер зарубежом с nginx в режиме стрим и bind с генерированием конфигов через скрипты (ну либо вообще фэйкрут). Чтобы работала простая подмена днс на заблокированных ресурсах, а не на заблокированных шло, как шло. На стороне пользователя просто вбить днс сервер (ну или впн до сервера с маршрутом только на 1 этот адрес, а не 0.0.0.0/0).
nidalee Автор
15.12.2024 18:20У вас просто задачи другие.
Вы попробуйте про маршруты и DNS объяснить, например, пенсионерке на другом конце города по телефону.Или на работе, на MacOS прописать левый DNS (я проверил - нельзя), когда даже удаление некоторых файлов требует права админа, которые вам никто давать не будет.
Прокси, в отличие от VPN и прочих SSH туннелей требует минимально возможные права и работает даже на кофеварках (слегка утрирую). Да, в современных браузерах почему-то не подразумевается использование прокси с аутентификацией. Впрочем, я видел несколько костылей для браузеров, когда прокси можно использовать как флаг при старте или включить поля для логин:пароль в конфигах браузера. Все эти костыли проще заменить банальным расширением, прав на него тоже никаких не нужно. И на MacOS, и на Linux, и на Windows, и на Android - просто устанавливаешь Firefox и просто устанавливаешь FoxyProxy. Все работает. Само-собой, прокси можно прикрутить к почти (?) любому браузеру. Прокси штука такая, что под капотом она совместима с чем угодно и не требует подпирать себя костылями. В контексте браузера весь затык исключительно в логине и пароле.
Кстати, если кому-то с руки протестировать, работает ли в Linux на Chrome и Firefox прокси с аутентификацией как переменная HTTPS_PROXY - было бы интересно, а то у меня все линуксы без гуев.
rionnagel
15.12.2024 18:20Ну про маршруты объяснять то никому не надо, это всё должно делаться на стороне сервера (в случае с впн). А вбить другие днс явно не сложней, чем ставить расширение на браузер и вбивать прокси. Другое дело, что при блокировке по sni будут проблемы (как ниже отметили) без заворачивания в впн.
Да в том-то и дело, что в случае, если не можем прописать прокси на всю систему (через переменные пути на линуксе раньше точно проблем не было), то имеем проблемы. Если кроме браузера у тебя с десяток приложений, половина из которых не поддерживает прокси, а остальная половина требует отдельной настройки... Это просто неудобно. Ну да, наверное вариант, если у вас нет возможности настроить впн. Но если возможность есть - я бы однозначно предпочел впн.
nidalee Автор
15.12.2024 18:20Ну подождите минутку... А какие приложения вообще нуждаются в впн и прокси, кроме браузера? Я не припомню ни одного, кроме Discord.
Uporoty
15.12.2024 18:20Без впн... я бы предложил через 1 сервер зарубежом с nginx в режиме стрим и bind с генерированием конфигов через скрипты (ну либо вообще фэйкрут)
И как ваша схема поможет против фильтрации запрещенных ресурсов по SNI? Она сработает только против блокировок по IP, а таких сейчас уже не так уж и много осталось.
same_one
Популярность вашего решения резко вырастет, если добавить ссылку на гитхаб и ещё Dockerfile.
nidalee Автор
В Docker умею только как юзер.
lantonov
Мда если честно это такой геморрой и vpn проще будет поднять и маршруы закидать на клиенте всго 2 действия
nidalee Автор
Это ваше право. Для меня прокси проще, а x-ui поднимается и настраивается примерно за схожее количество шагов (если не тупо весь трафик через него гнать):
Ставим x-ui \ Ставим squid
Настраиваем inbound \ Настраиваем squid
Прописываем маршруты \ Автоматизируем сборку файла с заблокированными доменами
PROFIT
Другое дело, что в случае с прокси на стороне клиента ничего делать не нужно - максимум расширение для браузера с поддержкой авторизации для прокси поставить.
lantonov
поднал тунель настролил маршруты подсети на vpn и кайфуешь вот список сетей могу кинть гугла и фейсбука
same_one
Представьте, что скинули history в файл.
sena
Не надо это популяризировать, squid-openssl на удалённом сервере это, мягко говоря, не самая лучшая идея.
AdVv
Поясните свою точку зрения ?
sena
https://habr.com/ru/articles/866746/comments/#comment_27677704
squid-openssl предназначен для SSL bumping, то есть для того чтобы кешировать и фильтровать зашифрованный контент. Это более-менее нормально если это будет внутри домашней сети и на сервере, которому ты доверяешь. Но если это на удалённом хостинге, то теоретически его могут взломать и получить доступ ко всему трафику.
sena
ЗЫ Посмотрел ещё раз конфиги - не уверен на 100%, но похоже я неправ и автор использует squid-openssl для заворачивания https в https.
nidalee Автор
Вы правы в этом сообщении, и не правы в прошлом: мы не расшифровываем ssl, а проксируем. Делать MITM это тот еще геморрой, я даже не возьмусь писать инструкцию. Да и нужды в этом нет никакой.
Вот как выглядит трафик для сервера в отчете за вчера:
Единственное, что реально "утекает" при включенном логгинге - это IP клиентов и SNI сайтов, на которые они ходят. В том числе и поэтому в конце гайда есть инструкция о том, как логгинг access можно отключить. При этом отчеты calamaris намеренно не включают в себя информацию о том, кто и куда ходит. Хотя в самом логе такая информация есть.