---: minor
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# Прозрачный прокси контейнера через Shadowsocks и tun2socks
|
||||
|
||||

|
||||

|
||||
[](https://typograph.cube2.ru/)
|
||||
|
||||
У меня есть Docker-контейнер Audiobookshelf, в котором я слушаю аудиокниги и подкасты. Он сам скачивает подкасты
|
||||
@@ -227,8 +227,8 @@ ls /dev/net/tun
|
||||
|
||||
**Третьим стартует** контейнер `audiobookshelf`. В нём почти всё по-старому. Но теперь он зависит от `tun2socks`,
|
||||
так что гарантированно запустится после него. Кроме того, у него нет проброса портов `8000:80` (они у нас теперь
|
||||
в контейнере tun2socks). Вместо этого у него `network_mode: «service:tun2socks"`. В целом, `network_mode:
|
||||
«service:…"` — это мощная, но специфичная функция Docker, которая «склеивает» сетевые стеки контейнеров в один,
|
||||
в контейнере tun2socks). Вместо этого у него `network_mode: "service:tun2socks"`. В целом, `network_mode:
|
||||
"service:…"` — это мощная, но специфичная функция Docker, которая «склеивает» сетевые стеки контейнеров в один,
|
||||
а это значит, что контейнер `audiobookshelf` будет использовать сетевой стек контейнера `tun2socks` и в результате
|
||||
весь трафик будет идти через TUN-интерфейс. Дальше уже сам `tun2socks` определит, что с ним делать. Если трафик пришел снаружи, с порта 8000, то он попадёт в Audiobookshelf, как и раньше, а если же сам Audiobookshelf начнет что-то скачивать, то запрос уйдет через TUN-интерфейс, попадет в `tun2socks`, который перенаправит его через SOCKS5-прокси
|
||||
`ss-ru` на Outline/VPS (на внешнем хостинге).
|
||||
|
||||
Reference in New Issue
Block a user