[Давайте совместно разберемся как настроить CloudFlare Masque (WARP - это уже прошлое)]

В 22.05.2025 в 14:11, uneasy сказал:

Крутяк! А локацию здесь тоже менять нельзя, как в Warp'e? Для варпа пытался делать "warp-in-warp", но заставить работать так и не получилось.

Нет, действует ровно также, как и WARP. Дает те же IP в тех же датацентрах. Да и по скорости, очевидно, выигрыша нет.  А до masque щупальца пока не дотянулись.

[Давайте совместно разберемся как настроить CloudFlare Masque (WARP - это уже прошлое)]

Да, интересно. Соединяется мгновенно, Tun поднимает.

~ #  curl  --interface tun1 http://myip.wtf/json
{
  "YourFuckingIPAddress": "104.28.246.229",
  "YourFuckingLocation": "Chelyabinsk, CHE, Russia",
  "YourFuckingHostname": "104.28.246.229",
  "YourFuckingISP": "Cloudflare, Inc.",
  "YourFuckingTorExit": false,
  "YourFuckingCity": "Chelyabinsk",
  "YourFuckingCountry": "Russia",
  "YourFuckingCountryCode": "RU"
}

Но вот с маршрутизацией у него что-то не работает - установил tun1 как дефолтный на тестовую политику (ровно также, как и на tun0 sing-box):

# ip route add defualt dev  tun1 table 21

Но устройства из этой политики, увы, в интернет не выходят. Что-то там с tun1 не так. Будем ждать..

[Поддержка TUN интерфейсов, созданных в Entware?]

7 часов назад, FLK сказал:

Баяните, сеньор) 

В личку гляньте)

Простите, сэр. Не все возможно найти в поиске.. За наводку гран-мерси.

 

****** Описанный в личке workaround касается именно политик, т.е. списка ВХОДЯЩИХ соединений по маркировке IP-пакетов..

Но использовать его в маршрутизации по destination адресам через "Маршрутизацию" не получится - dev tun0 по прежнему не будет виден в конфигураторе.. Т.е. он не отменяет всякие квасы и экскины..  Вторая важная задача - отправить destination ip-list в туннель. И сделать это из конфигуратора.

Т.е. необходимо ВИДЕТЬ  dev tun0  в конфигураторе.

[Поддержка TUN интерфейсов, созданных в Entware?]

Хотелось бы, чтобы была возможность в конфигураторе создать произвольный  tun-интерфейс и связать его с уже существующим в системе, например, поднятым в Entware (Xray, Sing-box, etc). В этом случае появляется возможность привести работу с туннелями к общей логике политик Keenetic-а. Что заодно избавит от дикой кучи левого софта, предназначенного для маршрутизации в такие туннели, типа квасов, xkeen-ов и иже с ними.

[MagiTrickle - Маршрутизация трафика на основе DNS запросов]

Скажите, а если есть список не доменов, а конкретных ip адресов?

Могу я их добавить в правила?

[Настройка туннеля IPv6 от Hurricane Electric]

Почти получилось. Однако при апдейте туннеля возникает ошибка Network Error:

W] May 21 17:09:00 ndm: DynDns::Profile: "_WEBADMIN": IPv4 update not run (not run). 
[E] May 21 17:09:13 ndm: Io::Http::Client: [1404] failed to resolve "ykryuchko:Qp7y*******lqA7m@ipv4.tunnelbroker.net". 
[W] May 21 17:09:13 ndm: DynDns::Profile: "UpadteHE": IPv4: update failure (network error). 
 

***** Update

Сохранил username и токен в соответствующих полях - теперь пишет "updated successfully".

 

[Настройка туннеля IPv6 от Hurricane Electric]

Простите, если этот вопрос из FAQ, но я не нашел ответа, извините.

Туннель на Hurricane Electric настроен, работает. Однако мой провайдер через пару недель сменит у меня IP-address (такова традиция).

В этом случае для обновления моего endpoint предполагается послать запрос следующего вида:

ttps://name:update_key@ipv4.tunnelbroker.net/nic/update?hostname=tunnel_id

Каким образом это реализовано в KeeneticOS?