Messages

Возможно что-то делаю не так, но какая-то нестабильная вещь. Если поставить галочку
Dynamic gateway policy - This interface does not require an intermediate system to act as a gateway
то ещё как-то начинает работать, но медленно, лагает, на след день пришлось перезапустить.

Для эксперимента - такое же туннельное соединение через WG с промежуточной панелью 3XUI (которая затем подключается по тому же vless соединению) работает норм и шустро, ютуб везде открывается.

Подскажите, пожалуйста, не работает. Само подключение через программу на ПК работает норм, сервисы норм открываются, скорость есть. Настройки подключения такие, вроде ничего особого.

{
    "tag": "proxy",
    "protocol": "vless",
    "settings": {
        "vnext": [
            {
                "address": "адрес",
                "port": порт,
                "users": [
                    {
                        "id": "ид",
                        "encryption": "none",
                        "flow": ""
                    }
                ]
            }
        ]
    },
    "streamSettings": {
        "network": "xhttp",
        "security": "reality",
        "realitySettings": {
            "serverName": "сайт",
            "fingerprint": "chrome",
            "show": false,
            "publicKey": "ключ",
            "shortId": "928c",
            "spiderX": "ещё какой-то пароль"
        },
        "xhttpSettings": {
            "path": "/",
            "mode": "auto"
        }
    }
}

В разделе диагностики сервисы подняты, какой-то трафик есть, и в первый момент после запуска сервиса какая-либо страница открывается, а дальше затык.

TUN Interface   proxytun2socks0
TUN Status   running
TUN IP   10.255.0.1/30
MTU   1500 bytes
Bytes In   136.1 KiB
Bytes Out   125.9 KiB
Packets In   549
Packets Out   671
xray-core Uptime   7m 3s
tun2socks Uptime   7m 3s
Server Ping RTT   21.997 ms

При проверке Could not connect — xray-core may be stopped or port unreachable. Если проверять из консоли командой то код ответа 301.

Outbond настроено, для удобства отладки планшет напрямую отправил через правила в шлюз тунеля. Что и как ещё можно посмотреть?

На соседнем сервере стоит 3X-UI панель, она подключена по этой же ссылке - через неё траффик тоже идёт. А вот через OPNsense нефига.

Так же не понятно откуда взяты/придуманы адреса 10.255.0.1 (интерфейса), 10.255.0.2 (шлюза). Если с интерфейсом понятно, то с чего решается, что шлюз именно 2. Но влияет это или нет - не знаю.

Ни захват пакетов, ни таблица Lixe view фаэрвола ничего толком не показывает, как проследить где пакеты теряются - не понимаю.

Добрый день!

Прошу помощи, в вопросе. Уровень знаний ближе к начальному, но и не первый день разбираюсь с вопросом.

Есть роутер Keenetic с белым IP, установлен, условно, сервер Wireguard. К нему удалённо подключается WireGuard на OPNsense. Версия OPNsense - 26.1.2_5, последняя.

Настройки WG OPN: Allowed IP: 0.0.0.0/0, Disable routes = вкл, Gateway=172.16.6.1.

В настройках создан интерфейс WG (всё по умолчанию), Dynamic gateway policy откл.

В настройках шлюзов так же создан шлюз WG_GW c IP 172.16.6.1 с автоматической проверкой доступности шлюза.

В статических маршрутах есть такой маршрут: сеть 192.168.0.0 шлюз WG_GW (172.16.6.1).

Конфигурация сети: локальная сеть Keenetic (192.168.0.0), локальная сеть OPNsense (192.168.10.0), сеть WG (172.16.6.0).

Теперь по проблеме.

Если клиент из сети Keenetic, допустим, 192.168.0.100 обращается по адресу 192.168.10.100, то всё нормально, он получает ответ.

А вот если клиент из сети Keenetic заходит в эту сеть из вне через переадресацию портов, например: 123.456.789.10:80 (Keenetic NAT 192.168.10.100:80), то на стороне OPNsense пакет доходит до 192.168.10.100:80, формируется ответ и уходит в интерфейс WAN вместо WG.

Если бы адреса выхода были фиксированы и я мог бы создать статический маршрут, то проблемы бы не было, но это невозможно по следующим причинам. 1. соврешенно не хочется, чтобы выход в интернет был через WG. 2. Если я сделаю статический маршрут 0.0.0.0/0 - шлюз WG_GW (172.16.6.1), то поначалу всё работает (даже если смириться с неудобством пункта 1), но после отвала связи - WG не может переподключиться, потому что он ищет соединение в отвалившемся шлюзе.

Для эксперимента, но это не цель, создано правило IN - LAN - Src: Lan Net, Dest: !LAN net - GW - WG_GW. (я опущу тот нюанс, что создана группа шлюзов с контролем отвала, сейчас это не имеет значения.) И даже тут всё работает - клиенты полностью уходят в WG. Но вот как перенаправить туда ответный пакет - я хоть убей не пойму. Какие правила только не создавал, включал/отключал SNAT по сетям - не помогает: интерфейс WG не подменяет адрес источника. Адрес источника всегда тот, что был у клиента. Понимаю, что у идеале SNAT должен был бы делать Keenetic, но тоже глухо - пакет отправляется в тунель с адресом источника точки выхода клиента.

С настройками Disable routes = вкл, Gateway=172.16.6.1 я тоже игрался, не помогло. Я предполагал, что Disable routes = вкл может отменять некоторые действия правил, но в итоге никакой разницы не увидел применительно к пути возврата пакета. Если мне память не изменяет, то при отключенной опции маршрут 0.0.0.0/0 - шлюз WG_GW создаётся автоматически.

Относительно того, что я пробовал - признаюсь - немного плаваю в вопросе, но я пробовал делать как вхлодящие, так и исходящие правила в LAN, чтобы все пакеты от нужного клиента шли в шлюз WG, но ещё раз повторюсь - это срабатывало только на запросах, которые формирует сам клиент. А вот его ответы всегда идут в WAN.