Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Компьютеры и программы

Маршрут локальных ресурсов через VPN WireGuard в Oracle Cloud

На чтение 8 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. Описание проблемы
  4. Почему решение с Ubuntu VM сработало
  5. Рекомендуемое решение с Windows Host
  6. Шаги для полной настройки WireGuard и NAT на Windows
  7. Заключение

Вопрос или проблема

В настоящее время я пытаюсь настроить VPN WireGuard на Oracle, чтобы получить доступ к моим локальным ресурсам за сетью CGNAT.

Вот моя настройка:

Топология сети

Экземпляр Oracle:

wg0.conf:

[Interface]
PrivateKey = <секрет>
ListenPort = 51820
Address = 192.168.7.1/24, aaaa:bbbb:cccc:dddd::11/112
PostUp = /etc/wireguard/helper/add-nat-routing.sh
PostDown = /etc/wireguard/helper/remove-nat-routing.sh

[Peer]
PublicKey = <секрет>
AllowedIPs = 192.168.7.2/32, aaaa:bbbb:cccc:dddd::12/128, 10.101.7.0/24

[Peer]
PublicKey = <секрет>
AllowedIPs = 192.168.7.3/32, aaaa:bbbb:cccc:dddd::13/128

add-nat-routing.sh:

#!/bin/bash
IPT="/sbin/iptables"
IPT6="/sbin/ip6tables"

IN_FACE="enp0s6"                   # Сетевой интерфейс, подключенный к интернету
WG_FACE="wg0"                    # Сетевой интерфейс WG
SUB_NET="192.168.7.0/24"          # Подсеть WG IPv4 или CIDR
WG_PORT="51820"                  # Порт udp WG
SUB_NET_6="fd42:42:42::/64"      # Подсеть WG IPv6
IPV6_ADDR="aaaa:bbbb:cccc:dddd::12"
IPV6_ADDR1="aaaa:bbbb:cccc:dddd::13"

## IPv4 ##
$IPT -t nat -I POSTROUTING 1 -o $IN_FACE -j MASQUERADE
$IPT -I INPUT 1 -i $WG_FACE -j ACCEPT
$IPT -I FORWARD 1 -i $IN_FACE -o $WG_FACE -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPT -I FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT -I INPUT 1 -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT

# перенаправление портов

## Plex
sudo iptables -I FORWARD -i enp0s6 -o wg0 -p tcp --syn --dport 32400 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -t nat -A PREROUTING -i enp0s6 -p tcp --dport 32400 -j DNAT --to-destination 192.168.7.2
sudo iptables -t nat -A POSTROUTING -o wg0 -p tcp --dport 32400 -d 192.168.7.2 -j SNAT --to-source 192.168.7.1

## IPv6 (раскомментировать) ##
killall dhclient # убить dhcp клиенты
### ipv6 клиент 1
ip -6 neigh add proxy $IPV6_ADDR dev $IN_FACE
ip -6 addr del $IPV6_ADDR dev $IN_FACE

### ipv6 клиент 2
ip -6 neigh add proxy $IPV6_ADDR1 dev $IN_FACE
ip -6 addr del $IPV6_ADDR1 dev $IN_FACE

#$IPT6 -t nat -I POSTROUTING 1 -s $SUB_NET_6 -o $IN_FACE -j MASQUERADE
$IPT6 -I INPUT 1 -i $WG_FACE -j ACCEPT
$IPT6 -I FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT6 -I FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT

remove-nat-routing.sh:

#!/bin/bash
IPT="/sbin/iptables"
IPT6="/sbin/ip6tables"

IN_FACE="enp0s6"                   # Сетевой интерфейс, подключенный к интернету
WG_FACE="wg0"                    # Сетевой интерфейс WG
SUB_NET="192.168.7.0/24"          # Подсеть WG IPv4 или CIDR
WG_PORT="51820"                  # Порт udp WG
SUB_NET_6="fd42:42:42::/64"      # Подсеть WG IPv6
IPV6_ADDR="aaaa:bbbb:cccc:dddd::12"
IPV6_ADDR1="aaaa:bbbb:cccc:dddd::13"

# Правила IPv4 #
$IPT -t nat -D POSTROUTING -o $IN_FACE -j MASQUERADE
$IPT -D INPUT -i $WG_FACE -j ACCEPT
$IPT -D FORWARD -i $IN_FACE -o $WG_FACE -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IPT -D FORWARD -i $WG_FACE -o $IN_FACE -j ACCEPT
$IPT -D INPUT -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT

# перенаправление портов
## Plex
sudo iptables -D FORWARD -i enp0s6 -o wg0 -p tcp --syn --dport 32400 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -t nat -D PREROUTING -i enp0s6 -p tcp --dport 32400 -j DNAT --to-destination 192.168.7.2
sudo iptables -t nat -D POSTROUTING -o wg0 -p tcp --dport 32400 -d 192.168.7.2 -j SNAT --to-source 192.168.7.1

# Правила IPv6 (раскомментировать) #
ip -6 neigh del proxy $IPV6_ADDR dev $IN_FACE
ip -6 neigh del proxy $IPV6_ADDR1 dev $IN_FACE
#$IPT6 -t nat -D POSTROUTING -s $SUB_NET_6 -o $IN_FACE -j MASQUERADE
$IPT6 -D INPUT -i $WG_FACE -j ACCEPT
$IPT6 -D FORWARD -i $IN_FACE -o $WG_FACE -j ACCEPT
$IPT6 -D FORWARD -i $WG_FACE -o $IN_FACE -j ACCEPT

Таблица маршрутизации:

default via 10.0.0.1 dev enp0s6
default via 10.0.0.1 dev enp0s6 proto dhcp src 10.0.0.251 metric 100
10.0.0.0/24 dev enp0s6 proto kernel scope link src 10.0.0.251 metric 100
10.0.0.1 dev enp0s6 proto dhcp scope link src 10.0.0.251 metric 100
10.101.7.0/24 dev wg0 scope link
169.254.0.0/16 dev enp0s6 scope link
169.254.0.0/16 dev enp0s6 proto dhcp scope link src 10.0.0.251 metric 100
169.254.169.254 via 10.0.0.1 dev enp0s6 proto dhcp src 10.0.0.251 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-29316d3b9da8 proto kernel scope link src 172.18.0.1
192.168.7.0/24 dev wg0 proto kernel scope link src 192.168.7.1

Windows машина:

Включить службу маршрутизации и удаленного доступа
Включить пересылку пакетов:

Set-NetIPInterface -Forwarding Enabled

wg0.conf:

[Interface]
PrivateKey = YAzh9/NKd1oT3bu1k4oldamUhP2BxKItvM+xkDkmwUs=
Address = 192.168.7.2/32, aaaa:bbbb:cccc:dddd::12/128
DNS = 1.1.1.1, 8.8.8.8, 2606:4700:4700::1111, 2001:4860:4860::8888

[Peer]
PublicKey = CH+TZnuK3VNnXFwKuezsynA9HqXbRKJJJe2g8/OIhnA=
AllowedIPs = 192.168.7.0/24
Endpoint = <публичный_ip_облака>:51820

Таблица маршрутизации:

IPv4 Route Table
===========================================================================
Активные маршруты:
Сетевое назначение        Маска подсети          Шлюз       Интерфейс  Метрика
          0.0.0.0          0.0.0.0     10.101.7.254     10.101.7.142     25
       10.101.7.0    255.255.255.0         В сети      10.101.7.142    281
     10.101.7.142  255.255.255.255         В сети      10.101.7.142    281
     10.101.7.255  255.255.255.255         В сети      10.101.7.142    281
        127.0.0.0        255.0.0.0         В сети         127.0.0.1    331
        127.0.0.1  255.255.255.255         В сети         127.0.0.1    331
  127.255.255.255  255.255.255.255         В сети         127.0.0.1    331
      172.21.32.0    255.255.240.0         В сети       172.21.32.1   5256
      172.21.32.1  255.255.255.255         В сети       172.21.32.1   5256
    172.21.47.255  255.255.255.255         В сети       172.21.32.1   5256
      192.168.7.0    255.255.255.0         В сети       192.168.7.2      5
      192.168.7.2  255.255.255.255         В сети       192.168.7.2    261
    192.168.7.255  255.255.255.255         В сети       192.168.7.2    261
        224.0.0.0        240.0.0.0         В сети         127.0.0.1    331
        224.0.0.0        240.0.0.0         В сети      10.101.7.142    281
        224.0.0.0        240.0.0.0         В сети       172.21.32.1   5256
  255.255.255.255  255.255.255.255         В сети         127.0.0.1    331
  255.255.255.255  255.255.255.255         В сети      10.101.7.142    281
  255.255.255.255  255.255.255.255         В сети       172.21.32.1   5256
===========================================================================

С облачного экземпляра я могу пинговать мой ПК-хост по адресам 10.101.7.142 и 192.168.7.2. Со своего ПК с Windows я могу пинговать экземпляр облака Oracle по адресу 192.168.7.1, как обычно. Но я не могу пинговать свой телефон по адресу 10.101.7.59 с облачного экземпляра, если не установлю шлюз на своем телефоне как 10.101.7.142, который хранит таблицу маршрутизации для 192.168.7.0/24. Это ожидаемо, потому что мой маршрутизатор на 10.101.7.254 не знает, как маршрутизировать в сеть 192.168.7.0/24.

Интересно, что я попробовал использовать гипервизор Ubuntu VM внутри моего ПК с Windows для инициации VPN-соединения вместо этого и добавил правило маршрутизации для пересылки 192.168.7.0 на эту VM. Теперь с облачного экземпляра я могу пинговать все свои устройства в сети 10.101.7.0/24. Вот настройка для этого:

wg0.conf Oracle:

[Interface]
PrivateKey = <секрет>
ListenPort = 51820
Address = 192.168.7.1/24, aaaa:bbbb:cccc:dddd::11/112
PostUp = /etc/wireguard/helper/add-nat-routing.sh
PostDown = /etc/wireguard/helper/remove-nat-routing.sh

[Peer]
PublicKey = <секрет>
AllowedIPs = 192.168.7.2/32, aaaa:bbbb:cccc:dddd::12/128

[Peer] # ubuntu vm
PublicKey = <секрет>
AllowedIPs = 192.168.7.3/32, aaaa:bbbb:cccc:dddd::13/128, 10.101.7.0/24

wg0.conf Ubuntu VM:

[Interface]
Address = 192.168.7.3/32, aaaa:bbbb:cccc:dddd::13/128
DNS = 1.1.1.1, 8.8.8.8, 2606:4700:4700::1111, 2001:4860:4860::8888
PrivateKey = MNDrU/wYHUW+aeJRP5AeC+P72IXHahoD7OdiCRi1HVQ=

[Peer]
AllowedIPs = 192.168.7.0/24
Endpoint = <публичный_ip_облака>:51820
PublicKey = CH+TZnuK3VNnXFwKuezsynA9HqXbRKJJJe2g8/OIhnA=
PersistentKeepalive = 25

Хост Windows:

route add 192.168.7.0 mask 255.255.255.0 172.21.34.107

где 172.21.34.107 – это IP адрес моей Ubuntu VM в сети гипервизора 172.21.32.0/20.

Мой вопрос в том, как я могу сделать это, просто используя мой ПК с Windows, и почему второе решение, где я использую VM Ubuntu, работает. Как мой телефон знает, как маршрутизировать обратно этот трафик в сеть 192.168.7.0/24, не имея таблицы маршрутизации для этого на маршрутизаторе или не устанавливая шлюз на моем ПК с Windows? Спасибо заранее за вашу помощь.

Как я и подозревал, сеть гипервизора 172.21.32.0/20 фактически выполнила SNAT к сети 10.101.7.0/24. Я решил проблему, добавив NetNat внутри Windows для сети 192.168.7.0/24:

New-NetNat -Name wg0nat -InternalIPInterfaceAddressPrefix 192.168.7.0/24

Ответ или решение

Настройка маршрутизации локальных ресурсов через VPN WireGuard на Oracle Cloud может быть сложной, особенно при работе с CGNAT сетями. Ниже приведены как объяснения, так и предлагаемые решения вашей проблемы, основанные на представленной информации.

Описание проблемы

Вы задали вопрос о маршрутизации трафика с ваших устройств в локальной сети (например, смартфона) через VPN-соединение в Oracle Cloud. Проблема заключается в том, что ваше локальное устройство (телефон) не знает, как маршрутизировать информацию обратно к сети 192.168.7.0/24, поскольку маршрутизатор по умолчанию не имеет соответствующих маршрутов для этой сети.

Почему решение с Ubuntu VM сработало

Когда вы использовали Ubuntu VM для установления VPN-соединения, VM эффективно действовала как шлюз. Это произошло по следующим причинам:

  1. Маршрутизация через VM: Ubuntu VM смогла принимать пакеты и направлять их на вашу локальную сеть, поскольку сеть Hyper-V может использовать NAT для маршрутизации трафика, который приходит из VPN в вашу локальную сеть (10.101.7.0/24).

  2. Отсутствие маршрутизатора: Ваш телефон мог без проблем общаться с облачной инстанцией, так как маршруты были правильно настроены на VM, и она могла отвечать на запросы от локальной сети.

Рекомендуемое решение с Windows Host

Чтобы обеспечить такую же функциональность без необходимости использования Ubuntu VM, вам нужно настроить NAT на вашей Windows-машине. Вы уже нашли правильное решение, создав NAT-сетевой интерфейс с помощью команды:

New-NetNat -Name wg0nat -InternalIPInterfaceAddressPrefix 192.168.7.0/24

Эта команда позволяет Windows перенаправлять трафик от сети 192.168.7.0/24 к интернету, передавая его через адаптер, который вы используете для подключения к VPN.

Шаги для полной настройки WireGuard и NAT на Windows

  1. Проверьте маршруты:
    Убедитесь, что на вашем Windows-устройстве правильно настроены маршруты, и 192.168.7.0/24 доступна через созданный NAT.

  2. Настройка WireGuard:
    Убедитесь, что конфигурационные файлы (wg0.conf) для вашей Windows-машины и облачной инстанции настроены корректно, как вы уже описали. Проверьте, чтобы настроенные IP-адреса соответствовали.

  3. Настройка маршрутов на телефоне:
    Если возможно, настройте ваш смартфон на использование Windows-машины в качестве шлюза. Для этого в настройках IP адреса укажите IP адрес вашей Windows-машины (например, 10.101.7.142) как шлюз. Это позволит вашему телефону знать, куда отправлять пакеты, предназначенные для сети 192.168.7.0/24.

  4. Маршрутизация на роутере:
    Если у вас есть доступ к настройкам маршрутизатора, можно добавить маршруты на уровень роутера, чтобы он знал, как справляться с трафиком в сеть 192.168.7.0/24.

Заключение

Решение, которое вы применили с DHCP и созданием NAT на вашей Windows-машине, должно значительно упростить маршрутизацию локальных устройств без промежуточных VM. Убедитесь в правильности конфигурации и, при необходимости, протестируйте связи, чтобы убедиться, что устройства могут открывать соединения и принимать трафик из сети VPN без каких-либо преград.

networking routing vpn wireguard
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности