From e63a980b2b43382dbde8f2a5e4bfc6756a6349bd Mon Sep 17 00:00:00 2001 From: erjemin Date: Fri, 6 Mar 2026 19:32:34 +0300 Subject: [PATCH] =?UTF-8?q?add:=20=D0=9F=D1=80=D0=BE=D0=B7=D1=80=D0=B0?= =?UTF-8?q?=D1=87=D0=BD=D1=8B=D0=B9=20=D0=BF=D1=80=D0=BE=D0=BA=D1=81=D0=B8?= =?UTF-8?q?=20=D0=BA=D0=BE=D0=BD=D1=82=D0=B5=D0=B9=D0=BD=D0=B5=D1=80=D0=B0?= =?UTF-8?q?=20=D1=87=D0=B5=D1=80=D0=B5=D0=B7=20Shadowsocks=20=D0=B8=20tun2?= =?UTF-8?q?socks=20(05)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...container-via-shadowsocks-and-tun2socks.md | 61 +++++++++++++++++-- 1 file changed, 55 insertions(+), 6 deletions(-) diff --git a/docker/docker-proxy-container-via-shadowsocks-and-tun2socks.md b/docker/docker-proxy-container-via-shadowsocks-and-tun2socks.md index a37f354..de359ec 100644 --- a/docker/docker-proxy-container-via-shadowsocks-and-tun2socks.md +++ b/docker/docker-proxy-container-via-shadowsocks-and-tun2socks.md @@ -228,12 +228,12 @@ ls /dev/net/tun **Третьим стартует** контейнер `audiobookshelf`. В нём почти все по старому. Но теперь он зависит от `tun2socks`, так что гарантированно запустится после него. Кроме того, у него нет проброса портов `8000:80` (они у нас теперь - в контейнере tun2socks). Вместо этого у него `network_mode: "service:tun2socks"`. Это значит, что он будет - использовать сетевой стек контейнера tun2socks. В результате весь его трафик будет идти через TUN-интерфейс - Дальше уже `tun2socks` определит что с ним делать. Если трафик пришел снаружи, с порта 8000, то он попадёт - в Audiobookshelf, как и раньше. Если же сам Audiobookshelf начнет что-то скачивать, то запрос уйдет через - TUN-интерфейс, попадет в `tun2socks`, который отфорвардит его через SOCKS5-прокси `ss-ru` на Outline/VPS - (на внешнем хостинге). + в контейнере tun2socks). Вместо этого у него `network_mode: "service:tun2socks"`. В целом, `network_mode: + "service:...` -- это мощная, но специфичная функция Docker, которая 'склеивает' сетевые стеки контейнеров в один, + а это значит, что контейнер `audiobookshelf` будет использовать сетевой стек контейнера `tun2socks` и в результате + весь трафик будет идти через TUN-интерфейс. Дальше уже сам `tun2socks` определит что с ним делать. Если трафик пришел снаружи, с порта 8000, то он попадёт в Audiobookshelf, как и раньше, а если же сам Audiobookshelf начнет что-то + скачивать, то запрос уйдет через TUN-интерфейс, попадет в `tun2socks`, который отфорвардит его через SOCKS5-прокси + `ss-ru` на Outline/VPS (на внешнем хостинге). ## Запуск и проверка @@ -275,3 +275,52 @@ sudo docker logs audiobookshelf --tail 100 ...и Google и ИИ-ассистенты в помощь. Node.js -- это не самая простая среда для отладки. + +## P.S. Важное замечание о защите Audiobookshelf от SSRF + +Во время настройки, в логах, можно столкнуться с ошибкой вида: `Call to 172.25.0.3 is blocked` или `invalid feed payload`. +Это не ошибка сети и не проблема RSS. Это встроенная защита Audiobookshelf от SSRF атак. + +### Что такое SSRF + +SSRF (Server Side Request Forgery) — это тип атаки, когда сервер заставляют делать запросы во внутреннюю сеть. +Например злоумышленник может подложить RSS-фид c ссылкой на внутренний сервис. Например: `http://127.0.0.1:8080/admin` +или `http://172.25.0.3:5000`. + +Если сервер загрузит такой URL, атакующий потенциально сможет: + - читать внутренние сервисы + - получать токены + - обращаться к Docker API + - сканировать внутреннюю сеть + +Поэтому многие современные приложения блокируют такие запросы. И Audiobookshelf не исключение. + +Audiobookshelf использует библиотеку `ssrf-req-filter`. Она проверяет IP адрес, в который резолвится домен, и блокирует некоторые диапазоны: + - `127.0.0.0/8` + - `10.0.0.0/8` + - `172.16.0.0/12` + - `192.168.0.0/16` + - `169.254.0.0/16` + +То есть любые внутренние адреса. Включая адреса Docker сети. + +Когда использовалась схема `Audiobookshelf → HTTP Proxy → Shadowsocks` то HTTP proxy находился в Docker сети. Например: +`privoxy:8118` или `redsocks:12345` + +После DNS-резолва запрос фактически отправлялся на адрес контейнера прокси внутри Docker сети. Например, `172.25.0.3`. И +SSRF-фильтр Audiobookshelf это видел и блокировал запрос. Именно поэтому в логах появлялось: `Call to 172.25.0.3 +is blocked`. + +### Почему HTTP_PROXY часто ломает Audiobookshelf + +Audiobookshelf использует библиотеку axios. А он: + - плохо работает с редиректами через прокси + - иногда резолвит DNS на стороне прокси + - иногда резолвит DNS локально + +В результате: часть запросов проходит; часть падает; RSS может читаться, но mp3 не скачиваются и так далее. + +Опытным путем я определил, что наиболее надёжный способ — сетевой туннель (`tun2socks`), при котором приложение не знает о прокси вообще. + + +