Маршрутизировать весь сетевой трафик через соединение openvpn, а также принимать входящие запросы на реальный IP-адрес хоста.
Я ищу решение для маршрутизации всего трафика с сервера через OpenVPN, но оставляю возможность размещать приложения на сервере, к которому можно получить доступ за пределами локальной сети.
Чтобы быть более конкретным: на сервере размещены два приложения. Есть одно приложение, которое связывает порт 80, и одно, которое связывает порт 8080. Весь трафик к этим службам и от них должен идти напрямую, весь остальной трафик должен проходить через VPN-туннель.
На данный момент запросы принимаются напрямую, но не отвечают, когда работает VPN. Все сервисы могут быть доступны при отключении VPN:
Как я могу настроить OpenVPN, например, с помощью сценария up, чтобы эти маршруты были правильно маршрутизированы?
Обзор моих сетевых интерфейсов:
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
4 ответа
У меня была такая же проблема, как и у вас. Вы должны отключить 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
Конечно, это (возможно) - Маршрутизация на основе политик они называют это.
Вы можете использовать маркировку брандмауэра, а затем использовать ip rule,
LARTC - это то, что вы ищете, чтобы прочитать внимательно.
Вы можете игнорировать или отменять нажатие с сервера redirect-gateway вариант. https://community.openvpn.net/openvpn/wiki/IgnoreRedirectGateway
Игнорирование перенаправления-шлюза
Если вы используете OpenVPN в качестве клиента, а используемый вами сервер использует push "redirect-gateway", тогда ваш клиент перенаправляет весь интернет-трафик через VPN. Иногда клиенты не хотят этого, но они не могут изменить конфигурацию сервера. На этой странице объясняется, как переопределить шлюз перенаправления, чтобы клиенту не нужно было перенаправлять Интернет, даже если сервер говорит об этом. Способ 1: игнорировать
Есть 2 варианта, которые можно использовать для игнорирования маршрутов, выдвигаемых сервером:
--route-noexec Не добавлять и не удалять маршруты автоматически. Вместо этого передайте маршруты скрипту --route-up, используя переменные среды.
--route-nopull При использовании с --client или --pull принимать параметры, выдвигаемые сервером, ИСКЛЮЧИТЬ параметры маршрутов и параметры dhcp, такие как DNS-серверы. При использовании на клиенте этот параметр эффективно запрещает серверу добавлять маршруты в таблицу маршрутизации клиента, однако следует помнить, что этот параметр по-прежнему позволяет серверу устанавливать свойства TCP/IP интерфейса клиента TUN/TAP.
Способ 2: переопределить
Здесь мы просто добавим маршруты, которые переопределяют --redirect-gateway. Это будет работать так же, как работает флаг def1 для --redirect-gateway. Это может отличаться, если сервер использует флаг def1 для опции --redirect-gateway или нет (проверяя журнал при подключении). Обратите внимание, что net_gateway является внутренней переменной для openvpn и не требует каких-либо изменений. Если вы не знаете, использует ли ваш сервер def1, и не хотите проверять журналы, чтобы выяснить это, просто предположите, что они действительно используют 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 маршрут 128.0.0.0 128.0.0.0 net_gateway
Если сервер использует def1 или вы не знаете, добавьте следующие параметры в конфигурацию клиента:
маршрут 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 маршрут 192.0.0.0 192.0.0.0 net_gateway
Тогда трафик, поступающий извне, будет проходить через обычный шлюз, а трафик из подсети VPN будет переходить в VPN. Если за VPN-подсетью находятся другие сети, вам придется добавить маршруты для них вручную.
маршрут 10.0.0.0 255.255.255.0 vpn_gateway
Я полагаю, что правильным решением будет раздельное туннелирование, или это то, что я буду делать на клиентской рабочей станции, но ваша ситуация немного отличается, потому что есть сервер: возможно ли добавить второй сетевой интерфейс?
В этом случае вы можете направить весь ваш VPN-трафик по первому интерфейсу, и при этом позволить вашему сервису прослушивать второй.