Linux + Сети

У обратного прокси очень простая функция - он ставится перед приложением (или группой приложений), и служит посредником между пользователем и сервисом.

Как упомянуто выше, обратный прокси маршрутизирует пользовательские запросы на соответствующий сервер (при условии, конечно, что вы используете несколько серверов). На этом месте те, кто использует один сервер с одним экземпляром приложения, вполне справедливо зададутся вопросом, имеет ли вообще смысл внедрять обратный прокси-сервер. Ответ: да, смысл есть.
Обратный прокси будет полезен и в инсталляциях с одним сервером, за счёт предоставления таких своих преимуществ как: ограничение скорости, IP-фильтрация и контроль доступа, аутентификация, проверка запросов и кэширование.

Ingress контроллер

Если в двух словах, то в мире Kubernetes ingress контроллер является обратным прокси (кстати именно поэтому тот же Istio в прошлой статье был упомянут в контексте перечисления вариантов обратных прокси).

Он действует по принципу обратного прокси, маршрутизируя трафик из внешней сети к целевому сервису в пределах кластера Kubernetes, и позволяя вам настроить балансировщик нагрузки HTTP и HTTPS для кластера.

Чтобы лучше понять принцип работы, давайте сделаем шаг назад и попробуем разобраться, что такое Ingress.

Kubernetes Ingress - это объект API, задача которого определять как приходящий трафик из интернета будет направляться на внутренние сервисы кластера, которые затем в свою очередь будут отправлять запросы Pod'ам. Сам по себе Ingress не имеет влияния на систему, представляя собой просто набор правил для Ingress контроллера. Для проведения аналогии можно сравнить Ingress с автомобилем, у которого снят двигатель, а Ingress контроллер с самим двигателем, то есть при наличие Ingress ресурса, без установленного контроллера, работать ничего не будет.

Ingress контроллер принимает трафик снаружи Kubernetes платформы, и распределяет его по Pod'ам внутри платформы, таким образом накладывая еще один уровень абстракции на маршрутизацию трафика. Контроллеры Ingress преобразуют конфигурации из ресурсов Ingress в правила маршрутизации, распознаваемые и реализуемые обратными прокси-серверами.

Обычно Ingress контроллеры используются для предоставления доступа к множеству сервисов через единую точку входа (DNS-имя или IP-адрес).

В частности, входные контроллеры используются для:

• предоставления нескольких служб под одним DNS-именем

• реализации маршрутизации на основе пути, при которой разные URL-адреса сопоставляются с разными службами

• реализации маршрутизации на основе хоста, при которой разные имена хостов сопоставляются с разными службами

• реализации базовой аутентификации, или других методы контроля доступа для ваших приложений.

• включения ограничения скорости для ваших приложения

Заключение

Если ingress контроллер делает практически ту же самую работу, что и обратный прокси (обрабатывает входящий трафик и перенаправляет на соответствующий сервер/сервис), то чем они отличаются?
Ingress контроллер - это частный случай прокси-сервера, предназначенный для работы в кластерах Kubernetes. Он находится не на границе инфраструктуры, а на границе кластера.

где <server-port> - это порт который будет слушать сервер ss (пример 8421)
<password> - любой пароль, желательно только что сгенерированный

1.3) Потом выполняем

systemctl restart shadowsocks-libev.service
systemctl status shadowsocks-libev.service

проверяем, что сервер завелся

2.1) Теперь переходим к роутеру.

Ставим на него пакеты

opkg install shadowsocks-libev-ss-tunnel shadowsocks-libev-config

2.2) теперь редактируем конфиг

vi /opt/etc/shadowsocks.json

{
"server": "<server-ip>",
"mode":"tcp_and_udp",
"server_port":<server-port>,
"local_address": "0.0.0.0",
"local_port":<local-port>,
"password":"<password>",
"timeout":300,
"method":"chacha20-ietf-poly1305",
"tunnel_address": "127.0.0.1:<wireguard-port>"
}

где <server-port> и <password> это те же самые, которые добавили на сервер в пункте 1.2
<server-ip> - ip адрес сервера на котором крутится wireguard и ss
<local-port> - любой свободный порт на роутере, который мы будем указывать в настройках wg соединения (пример 51822)
<wireguard-port> - это порт на котором на сервере крутится wg соединение (пример 51820)

2.3) правил файл

vi /opt/etc/init.d/S22shadowsocks

меняем на строку PROCS=ss-* на PROCS=ss-tunnel
перезапускаем ss на роутере и проверяем, что работает

/opt/etc/init.d/S22shadowsocks restart
/opt/etc/init.d/S22shadowsocks check

3.1) Идем в веб морду роутера, в настройки нужного wg соединения и в пире вместо <server-ip>:<wireguard-port> вставляем 127.0.0.1:<local-port>

П.С.: Схема работы

Все! соединение должно теперь установиться. В итоге трафик через wg интерфейс будет заворачиваться в ss и идти уже под ним. Так как и ss и wg используют шифрование, то у меня скорость туннеля упала в двое, по сравнению с простым wg без заворачивания в ss. Зато надежно

П.С.: Так же есть проект, где реализована маршрутизация только к определенным ресурсам. То есть роутер использует интернет провайдера, а на определенные сайты (не будем говорить какие) ходит через впн