На Хабре есть уже десятки статей о том, как поднять свой 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На этом, пожалуй, все.
ссылка на оригинал статьи https://habr.com/ru/articles/866746/
Добавить комментарий