Маршрутизация всего сетевого трафика через соединение openvpn, а также прием входящих запросов на реальный IP-адрес хоста
Я ищу решение для маршрутизации всего трафика с сервера через OpenVPN, но сохраняю возможность размещения приложений на сервере, к которым можно получить доступ вне локальной сети.
Чтобы быть более конкретным: На сервере размещены два приложения. Одно приложение связывает порт 80, а другое - порт 8080. Весь трафик к этим службам и от них должен идти напрямую, весь остальной трафик должен проходить через туннель VPN.
В настоящий момент запросы принимаются напрямую, но не отвечают, когда работает VPN. Когда я отключу VPN, можно будет получить доступ ко всем службам:
Как мне настроить OpenVPN, например, с помощью сценария запуска, чтобы эти маршруты маршрутизировались правильно?
Обзор моих сетевых интерфейсов:
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:537169 errors:0 dropped:0 overruns:0 frame:0
TX packets:537169 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:147901148 (147.9 MB) TX bytes:147901148 (147.9 MB)
p4p1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.2.201 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: xxx/64 Scope:Global
inet6 addr: xxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8062700 errors:0 dropped:180 overruns:0 frame:0
TX packets:10937639 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7942028079 (7.9 GB) TX bytes:12229412785 (12.2 GB)
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:XX P-t-P:XX Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:6382168 errors:0 dropped:0 overruns:0 frame:0
TX packets:6004894 errors:0 dropped:46397 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:7066816609 (7.0 GB) TX bytes:4808493953 (4.8 GB)
Таблицы маршрутизации до подключения к VPN:
ip route show
default via 192.168.2.254 dev p4p1
192.168.2.0/24 dev p4p1 proto kernel scope link src 192.168.2.201
Таблицы маршрутизации после подключения к VPN:
ip route show
0.0.0.0/1 via 10.124.1.5 dev tun0
default via 192.168.2.254 dev p4p1
10.124.1.1 via 10.124.1.5 dev tun0
10.124.1.5 dev tun0 proto kernel scope link src 10.124.1.6
109.201.154.152 via 192.168.2.254 dev p4p1
128.0.0.0/1 via 10.124.1.5 dev tun0
192.168.2.0/24 dev p4p1 proto kernel scope link src 192.168.2.201
У меня была такая же проблема, как и у вас. Вы должны отключить rp_filter и перенаправить весь трафик с целевого порта 80 и 8080 на ваш обычный интерфейс.
Отключить фильтрацию обратного пути
for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
echo 0 > $i
done
Мы собираемся использовать таблицу 100. Убедитесь, что она больше не используется! Мы собираемся его очистить.
ip route flush table 100
ip route del default table 100
ip rule del fwmark 1 table 100
ip route flush cache
iptables -t mangle -F PREROUTING
Создайте таблицу для всех подключений (не VPN-туннель)
ip route show table main | grep -Ev ^default | grep -Ev tun0 \
| while read ROUTE ; do
ip route add table 100 $ROUTE
done
ip route add default table 100 via 192.168.2.254
ip rule add fwmark 1 table 100
ip route flush cache
Обход порта 80 и 8080
iptables -t mangle -A PREROUTING -i p4p1 -p tcp -m multiport --dports 80,8080 -j MARK --set-mark 1
Я считаю, что правильным решением будет Раздельное туннелирование , или то, что я буду делать на клиентской рабочей станции,но ваша ситуация немного отличается, потому что есть сервер: можно ли добавить второй сетевой интерфейс?
В этом случае вы можете маршрутизировать весь свой VPN-трафик через первый интерфейс, и все же позволить вашей службе прослушивать второй интерфейс .
Вы можете игнорировать или переопределить нажатие с сервера шлюз перенаправления .
https://community.openvpn.net/openvpn/wiki/IgnoreRedirectGateway
Игнорирование шлюза перенаправления
Если вы используете OpenVPN в качестве клиента, и вы используете сервер используя push "redirect-gateway", ваш клиент перенаправляет весь интернет трафик через VPN. Иногда клиенты этого не хотят, но могут не изменять конфигурацию сервера. На этой странице объясняется, как переопределить шлюз перенаправления, чтобы клиенту не нужно было перенаправлять Интернет, даже если сервер говорит. Метод 1: игнорировать
Есть 2 варианта, которые можно использовать для игнорирования маршрутов, отправленных server:
- route-noexec Не добавлять или удалять маршруты автоматически. Вместо этого передайте маршруты в сценарий --route-up, используя переменные окружения.
- route-nopull При использовании с --client или --pull принимать параметры, переданные сервером, ЗА ИСКЛЮЧЕНИЕМ для маршрутов и параметров DHCP, таких как DNS-серверы. При использовании на клиенте этот параметр эффективно запрещает серверу добавление маршрутов в таблицу маршрутизации клиента, однако учтите, что это опция по-прежнему позволяет серверу устанавливать свойства TCP / IP для интерфейс TUN / TAP клиента.
Метод 2: override
Здесь мы просто добавим маршруты, которые отменяют --redirect-gateway. Этот будет работать так же, как флаг def1 для --redirect-gateway. Этот может быть другим, если сервер использует флаг def1 для --redirect-gateway или нет (проверяя журнал при подключении). Обратите внимание, что net_gateway - это внутренняя переменная openvpn. и не нужно ни на что менять. Если вы не знаете, ваш сервер использует def1 и не хочет проверять журналы, чтобы понять это out, просто предположим, что они ДЕЙСТВИТЕЛЬНО используют def1 и используют 4 маршрута. Это будет работать несмотря ни на что.
def1 - Используйте этот флаг, чтобы переопределить шлюз по умолчанию, используя 0.0.0.0/1 и 128.0.0.0/1, а не 0.0.0.0/0. Это дает преимущество переопределения, но не уничтожения исходного шлюза по умолчанию.
Если сервер НЕ использует def1, добавьте следующие параметры в Конфигурация клиентов:
маршрут 0.0.0.0 128.0.0.0 net_gateway route 128.0.0.0 128.0.0.0 net_gateway
Если сервер ДЕЙСТВИТЕЛЬНО использует def1 или если вы не знаете, добавьте следующее параметры конфигурации клиентов:
route 0.0.0.0 192.0.0.0 net_gateway маршрут 64.0.0.0 192.0.0.0 net_gateway маршрут 128.0.0.0 192.0.0.0 net_gateway route 192.0.0.0 192.0.0.0 net_gateway
Тогда трафик, приходящий извне, будет проходить через обычный шлюз, а трафик из подсети VPN будет идти в VPN. Если за подсетью VPN находятся другие сети, вам придется добавить маршруты для них вручную.
route 10.0.0.0 255.255.255.0 vpn_gateway