Сервер Wireguard и клиент openvpn - Переадресация трафика с wg0 на tun0 (туннель openvpn)
У меня есть Raspberry Pi с запущенным клиентом OpenVPN, подключающимся к провайдеру VPN, а также с сервером Wireguard, чтобы я мог подключиться к своей домашней локальной сети извне. Я хочу подключиться к моему дому через wireguard и отправить весь трафик через соединение Openvpn.
Это мой вывод ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.5 netmask 255.255.255.0 broadcast 192.168.1.255
wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1420
inet 172.1.1.1 netmask 255.255.255.0 destination 172.1.1.1
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.8.17 netmask 255.255.255.0 destination 10.8.8.17
eth0 - это шлюз в интернет (подключен к моему домашнему роутеру)
Когда я подключаюсь к серверу Wireguard без запущенного клиента OpenVPN, я могу подключиться к своей внутренней локальной сети (192.168.1.X), а также перенаправить свои запросы в Интернет через raspberry pi (eth0). Когда я включаю клиент OpenVPN (настройка 0), я не могу подключиться к внутренней локальной сети, а также не могу подключиться к Интернету.
Что я хочу сделать, так это подключиться к моему дому через wireguard и получить весь трафик, туннелированный через соединение openvpn (tun0).
Это мой вывод из "route -n":
Перед запуском OpenVPN (wireguard работает нормально):
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 202 0 0 eth0
172.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
После запуска openVPN tun0 (проводное соединение не достигает клиентов интернета и локальной сети):
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.8.8.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.1.1 0.0.0.0 UG 202 0 0 eth0
10.8.8.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
95.142.172.143 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
128.0.0.0 10.8.8.1 128.0.0.0 UG 0 0 0 tun0
172.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wg0
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
Мои правила брандмауэра:
-A FORWARD -i wg0 -j ACCEPT
-A POSTROUTING -o eth0 -j MASQUERADE
Отсутствуют ли какие-либо правила брандмауэра или какие-либо маршруты, которые я должен добавить, чтобы это работало? Что я должен был иметь?
Спасибо!!
3 ответа
Короче говоря: решение
Создайте новую таблицу маршрутизации:
ip route add default via 192.168.1.5 dev eth0 table 7
ip rule add fwmark 0x55 priority 1000 table 7
ip route flush cache
Где 192.168.1.5 - это IP вашего внешнего интерфейса (eth0). Теперь добавьте это в ваш wg0.conf:
FwMark = 0x55
Теперь вы сможете подключаться к вашему домашнему серверу через WireGuard, даже когда открыт туннель OpenVPN.
Более длинное объяснение
Когда вы запускаете свой туннель OpenVPN, в основной таблице маршрутизации устанавливается новый маршрут. Этот маршрут может выглядеть так: 0.0.0.0/1 via 10.8.8.1 dev tun0 и иметь в виду, что весь ваш интернет-трафик должен отправляться через туннель.
Это замечательно, но всякий раз, когда вы хотите установить связь с вашим компьютером маршрутизации через незащищенный интерфейс, ответы вашего компьютера также будут отправлены в туннель. Вот почему вы больше не можете получить доступ к вашему серверу через https, даже если вы перенаправили на него порт 443. Его ответы будут просто отправлены в туннель и будут потеряны.
Настроив вторую таблицу маршрутизации, которую можно просмотреть через ip route show table 7 и правило 0x55, которое мы в основном сказали вашей машине направлять каждый помеченный пакет через обычный незащищенный интерфейс eth0. Остальные все равно будут отправлены в туннель.
Что еще можно сделать?
OpenVPN-сервер
Я действительно нашел решение тогда, когда я даже не слышал о WireGuard. В то время я хотел подключиться к своей домашней сети через OpenVPN и не смог этого сделать, когда на сервере был туннель. Однако мой собственный OpenVPN-сервер прослушивал порт 993, поэтому я пометил каждый пакет "0x55", который проходил через этот порт:
sudo iptables -t mangle -A OUTPUT -p tcp -m multiport --sport 993 -j MARK --set-mark 0x55
Это сделало возможным VPN-соединение с моим VPN-сервером.
Порты электронной почты не защищены
Мой VPN-провайдер не позволяет отправлять почту через VPN, потому что были проблемы со спамом. Это правило будет маршрутизировать соединение с моими почтовыми аккаунтами, не пропуская их через туннель:
iptables -t mangle -A PREROUTING -p tcp --dport 25 -j MARK --set-mark 0x55
MAC-адреса без VPN
Возможно, вы хотите, чтобы полное устройство было "незащищенным". Если вы используете шведский сервер и не хотите видеть шведскую рекламу на YouTube на своем планшете, вы можете сделать это:
iptables -t mangle -A PREROUTING -m mac --mac-source 4c:h7:9f:0l:17:k1 -j MARK --set-mark 0x55
вам, конечно, придется использовать MAC-адрес вашего планшета.
У меня точно такая же настройка (openVPN-Server<->openVPN-Client / Wireguard-Server (MiddleMan)<->Wireguard-Client), но решить ее удалось только наполовину.
Когда я добавляю следующие правила iptables в MiddleMan в конфигурации MiddleMan WireGuard:
PreUp = iptables -t nat -A POSTROUTING -s 10.200.200.0/24 -o tun0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.200.200.0/24 -o tun0 -j MASQUERADE
где 10.200.200.0 - это сеть wg0, настройте интерфейс openvpn и добавьте следующие правила в конфигурацию openVPN на MiddleMan:
route-nopull
route 192.168.178.0 255.255.255.0
где 192.168.178.0 - внутренняя сеть сервера openVPN, я могу пропинговать и получить доступ к сети 192.168.178.0 с помощью клиента WireGuard (мобильный телефон).
Но я до сих пор не знаю, как перенаправить интернет с сервера openVPN на клиент Wireguard. Если я перетаскиваю все маршруты с сервера openVPN на MiddleMan, шлюз по умолчанию на MiddleMan заменяется, и клиент WireGuard не получает доступ к MiddleMan. Мне просто нужно знать правильную маршрутизацию, как перенаправить интернет-трафик с сервера openVPN на клиент WireGuard без замены шлюза по умолчанию на MiddleMan.
Вы сказали: "Я хочу подключиться к моему дому через wireguard и отправить весь трафик через соединение Openvpn", что не имеет смысла. Я интерпретирую это как "Я хочу подключиться к своему дому через проводную охрану и отправить ВЕСЬ ДРУГОЙ трафик через соединение Openvpn".
Когда вы запускаете сервер OpenVPN, ваш маршрут по умолчанию изменяется с 192.168.1.1 на 10.8.8.1, который маршрутизируется через tun0. Похоже, что равноправным адресом tun0 является 95.142.172.143, для которого определен собственный маршрут /32, поэтому трафик для этого всегда отправляется напрямую в Интернет через eth0. Этот статический маршрут освобождает конечную точку туннеля от маршрутизации по умолчанию, и без нее туннель не будет работать.
Это говорит о том, что ваш клиент OpenVPN настроен на маршрутизацию всего трафика на удаленную сторону туннеля OpenVPN. Это типичная конфигурация OpenVPN, она будет использоваться, когда вы не доверяете локальной сети и хотите, чтобы весь ваш трафик был надежно зашифрован и направлен через сервер OpenVPN.
Как только вы запускаете сервер OpenVPN, весь трафик для вашего сервера Wireguard перенаправляется по этому маршруту по умолчанию через туннель OpenVPN, и он переходит во все, что находится на другой стороне этого туннеля, где он, предположительно, сбрасывается.
Я предполагаю, что вам нужно указать статический маршрут к вашему серверу Wireguard, аналогично тому, как OpenVPN добавил маршрут /32 для своего сервера (95.142.172.143). Например, если ваш сервер Wireguard был 100.100.100.10, вы бы добавили статический маршрут для этого IP-адреса через eth0. Вы сможете сказать, правильно ли вы это поняли, потому что он будет напоминать результат, полученный в таблице маршрутизации, приведенной выше для 95.142.172.143. Для тестирования в командной строке после запуска сервера OpenVPN попробуйте:
# route add -host IP-OF-REMOTE-WIREGUARD-SERVER gw DEFAULT-GATEWAY-IP
Где "DEFAULT-GATEWAY-IP" - это IP-адрес вашего интернет-провайдера, который выглядит как 192.168.1.1 из приведенных выше примеров. Затем, когда вы выполните команду "netstat -rn", вы должны увидеть новый маршрут с флагами "UGH" точно так же, как маршрут 95.142.172.143 в выходных данных "netstat" в вопросе.
Подводя итог, следует отметить, что туннели должны проходить через необработанное интернет-соединение. Ваша настройка не работает, потому что он пытается заполнить туннель Wireguard внутри туннеля OpenVPN.