Общие сведения о перенаправлении для шлюза приложений
С помощью Шлюза приложений вы можете перенаправлять трафик. В этой службе реализован универсальный механизм перенаправления, который позволяет перенаправлять трафик, поступающий на один прослушиватель, на другой прослушиватель или на внешний сайт. Это упрощает настройку приложения, оптимизирует использование ресурсов и обеспечивает поддержку новых сценариев перенаправления, включая перенаправление на основе пути и глобальное перенаправление.
Обычный сценарий перенаправления для многих веб-приложений — поддержка автоматического перенаправления с HTTP на HTTPS, чтобы весь обмен данными между приложением и его пользователями осуществлялся по зашифрованному каналу. В прошлом клиенты использовали такие методы, как создание выделенного внутреннего пула, единственным назначением которого было перенаправление запросов, получаемых по HTTP, на HTTPS. Благодаря поддержке перенаправления в Шлюзе приложений вам для этого достаточно лишь добавить новую конфигурацию перенаправления в правило маршрутизации и указать другой прослушиватель с протоколом HTTPS в качестве целевого прослушивателя.
Типы перенаправления
Тип перенаправления задает код состояния ответа, чтобы клиенты получили данные о назначении перенаправления. Поддерживаются следующие типы перенаправления:
- 301 (окончательно перемещено) . Указывает, что целевому ресурсу был назначен новый постоянный URI. Для всех последующих ссылок на этот ресурс будет использоваться один из заключенных в него URI. Используйте код состояния 301 для перенаправления с HTTP на HTTPS.
- 302 (найдено) . Указывает, что целевой ресурс временно находится под другим URI. Так как перенаправление может измениться в некоторых случаях, клиент должен продолжать использовать действующий URI запроса для будущих запросов.
- 307 (временное перенаправление) . Указывает, что целевой ресурс временно находится под другим URI. Агент пользователя не должен изменять метод запроса, если он выполняет автоматическое перенаправление на этот URI. Так как перенаправление может измениться со временем, клиент должен продолжать использовать исходный действующий URI запроса для будущих запросов.
- 308 (постоянное перенаправление) . Указывает, что целевому ресурсу был назначен новый постоянный URI. Для всех последующих ссылок на этот ресурс следует использовать один из заключенных в него URI.
Возможности перенаправления
Перенаправление прослушивателя
Перенаправляет один прослушиватель на другой прослушиватель. Перенаправление прослушивателя обычно используется для включения перенаправления HTTP на HTTPS.
При настройке перенаправлений с помощью прослушивателя с несколькими сайтами необходимо, чтобы все имена узлов (с подстановочными знаками или без них) были определены как часть исходного прослушивателя также являются частью целевого прослушивателя. Это гарантирует, что трафик не удаляется из-за отсутствия имен узлов в целевом прослушивателе при настройке перенаправления HTTP на HTTPS.
Перенаправление на основе пути
Этот тип перенаправления включает перенаправление только в определенной области сайта, например перенаправление HTTP на HTTPS-запросы для области корзины покупок, обозначенной параметром /cart/*.
Перенаправление на внешний сайт
Благодаря этому изменению клиентам потребуется создать новый объект конфигурации перенаправления, который задает целевой прослушиватель или внешний сайт, на которые требуется организовать перенаправление. Элемент конфигурации также поддерживает параметры, позволяющие разрешить добавление пути URI и строки запроса к URL-адресу перенаправления. Вы можете также выбрать тип перенаправления. После создания эта конфигурация перенаправления присоединяется к исходному прослушивателю посредством нового правила. При использовании базового правила конфигурация перенаправления связывается с исходным прослушивателем и является глобальным перенаправлением. При использовании правила на основе пути конфигурация перенаправления определяется в сопоставлении URL-пути. Поэтому она применяется только к области конкретного пути на сайте.
OpenVPN перенаправить трафик
Иногда требуется пустить только определенный трафик через VPN, что бы не нагружать и так не быстрое защищенное соединение.
Для примера у нас есть домашний пк в сети 192.168.0.0/24(например 192.168.0.15). На этом пк установлен клиент OpenVPN, который создал виртуальный адаптер с адресом в сети 10.8.0.0/24(например 10.8.0.4). Сервер VPN имеет внутренний адрес 10.8.0.5. Ниже будет конфиг, который направит в VPN только запросы относящиеся к сети 10.8.0.0/24 все остальные буду идти как обычно, не замедляя VPN соединение. Особенно это заметно когда на пк стоит торрент качалка.
Заходим на свой сервер OPENVPN через ssh.
Идем в папку где лежит конфиг сервера, по умолчанию /etc/openvpn/server.conf
открываем, ищем строку (она пускает весь траффик через VPN)
И заменяем ее на следующее:
Все, можно перезапустить сервер и пробовать.
Таким образом можно направлять трафик через VPN только для заблокированных сайтов. Например:
MNorin.com
Блог про Linux, Bash и другие информационные технологии
Настройка iptables от простого к сложному. Часть 3.
Давайте посмотрим, как работать с тем, что называют iptables routing, или перенаправлением пакетов при помощи iptables.
В первой и второй частях мы рассматривали настройку iptables, касающуюся блокировки пакетов, а теперь посмотрим, как не блокировать их, а направлять туда, куда нам нужно.
Маскарадинг (или маскирование)
Маскарадинг — это метод обработки пакетов, при котором пакеты передаются через некоторую машину, работающую как шлюз. Эта машина при пересылке пакетов помечает их, чтобы знать, какой машине в сети вернуть полученный ответ. Таким образом, несколько машин из внутренней сети могут обращаться к внешней сети, а извне это будет выглядеть так, как будто обращения идут от той самой машины, являющейся шлюзом. Маскарадинг связан в первую очередь с NAT (Network Address Translation), пакеты при трансляции адресов маскируются, чтобы ответ вернулся именно к источнику запроса.
Например, у нас есть некоторая локальная сеть с адресами 192.168.0.0/24, в этой сети есть шлюз с адресом 192.168.0.1, имеющий два сетевых интерфейса, eth0 и eth1. eth0 — внешний, подключенный к провайдеру, например, с адресом 192.168.100.25, eth1 — внутренний, подключенный к локальной сети, тот самый, на котором адрес 192.168.0.1. Необходимо обеспечить работу всех клиентов из локальной сети в сети Интернет таким образом, чтобы это было для них прозрачно.
В таком случае в первую очередь необходимо включить форвардинг пакетов между сетевыми интерфейсами шлюза, чтобы пропускать трафик из внутренней сети наружу. Есть два варианта, как это можно сделать. Первый — раскомментировать в файле /etc/sysctl.conf строчку
После этого вам надо будет перезагрузиться, чтобы убедиться, что форвардинг работает. Второй — включить форвард вручную командой
Этот способ заработает без перезагрузки. Можно использовать оба, а можно в скрипте, например, использовать при загрузке правил iptables только второй.
После этого мы можем задать правило для адресной трансляции:
Это правило после обработки пакетов осуществит маскирование, если пакеты из внутренней сети направлены куда-то в другую подсеть. Если нам нужно маскировать пакеты для конкретной подсети, к примеру, из одной локальной подсети (192.168.2.0/24) в другую (192.168.0.0/24), то мы можем создать следующее правило:
Перенаправление пакетов на другой порт
Перенаправление портов можно использовать для самых разных задач. Например, перенаправление пользователей из разных сетей на разные экземпляры веб-сервера, перенаправление порта на другой, если изменился порт какого-то сервиса, настройка прозрачного проксирования и так далее. Общая идея в том, что пакеты с определенного порта перенаправляются на другой порт на том же сетевом интерфейсе той же самой машины, либо на loopback’е.
Для перенаправления порта, например, 80, с внешнего интерфейса на порт 80 на loopback-интерфейсе мы можем использовать правило
Это правило позволит перенаправить пакеты на loopback, изменив назначение пакета путем трансляции адреса (Destination NAT), и после этого можно будет их отфильтровать в цепочке, которая будет задана для loopback-интерфейса. Естественно, нужно будет сделать и обратную трансляцию:
Таким образом, происходит обратный процесс, при этом изменяется Source NAT, то есть, транслируется адрес источника соединения.
Форвардинг портов на другую машину
По сути форвардинг портов на другую машину не отличается от форварда портов в пределах одной машины, но по существу это не одно и то же, поскольку пакеты будут передаваться не в пределах одной машины, как в случае с loopback-интерфейсом, когда фактически пакеты транслируются в пределах сетевого стека. Обычно форвардинг портов производится с определенного порта внешнего интерфейса на определенный порт машины во внутренней сети, поэтому между сетевыми интерфейсами должен быть настроен форвардинг. Например, проброс порта 3389 для работы удаленного рабочего стола (RDP) с внешнего сетевого интерфейса (192.168.100.25) на порт 3389 на одну из машин во внутренней сети (192.168.0.15):
Таблица форвардинга
При настройке iptables мы уже использовали таблицу форвардинга, но единственное, что мы делали — это очищали правила командой
В этой таблице не рекомендуется фильтровать трафик, рекомендуется ее использовать только для перенаправления трафика. Фильтрацию необходимо выполнять либо до форвардинга, либо уже после. В таблице FORWARD вы определяете, куда должны форвардиться пакеты, а куда нет. Например:
— разрешить форвардинг между eth0 и eth1
— разрешить форвардинг между eth0 и eth2
— запретить форвардинг между eth1 и eth2
Правила в таком случае могут выглядеть так:
либо еще короче:
Разница между DROP и REJECT
При сбросе пакетов используют обычно две цели — DROP и REJECT, при этом нужно понимать, почему вы используете именно этот вариант. Основное различие состоит в том, что при использовании DROP не будет отправлен ICMP-ответ, по которому можно будет определить, что в соединении отказано. Оно просто не пройдет. Когда вы используете REJECT, то вы явно получите ответ, что в соединении отказано. Поэтому при составлении таблиц правил iptables лучше использовать REJECT, а когда вы окончательно определитесь с конфигурацией, можно изменить REJECT на DROP.