"Recent posts
#41
Russian - Русский / Re: os-xray — плагин Xray-core...
Last post by Spylive - September 24, 2026, 01:17:56 PMos-xray v3.1.2 — первый стабильный релиз нашего форка от оригинального проекта MrTheory
Данный проект является форком оригинального проекта MrTheory/os-xray, основанным на ветке разработки:
https://github.com/MrTheory/os-xray/tree/develop
Оригинальная ветка develop послужила основой проекта и предоставила базовую функциональность os-xray.
В рамках форка основной упор был сделан на стабилизацию работы, исправление проблем совместимости и подготовку production-релиза для актуальных версий OPNsense.
После тестирования и исправления выявленных проблем выпущен первый стабильный релиз нашего форка:
Основные изменения относительно оригинальной develop версии:
1. Исправлен порядок запуска при загрузке OPNsense
В процессе эксплуатации была обнаружена проблема взаимодействия между загрузкой OPNsense, настройкой маршрутизации и созданием TUN-интерфейса.
В некоторых сценариях OPNsense пытался применить настройки интерфейсов и маршрутов до того, как Xray/tun2socks успевали создать виртуальный интерфейс.
Возникали ошибки:
В v3.1.2 изменён порядок инициализации:
Теперь после перезагрузки системы TUN-интерфейс корректно поднимается до применения маршрутов.
---
2. Улучшена инициализация TUN-интерфейса
Добавлено:
---
3. Исправлен механизм запуска сервисов
Изменения:
---
4. Улучшена диагностика подключения
Исправлен механизм testconnect:
---
5. Проведён аудит стабильности перед релизом
Проверено:
---
6. Новая структура разработки форка
После стабилизации проект переведён на собственную структуру веток:
Текущий стабильный релиз:
---
Репозитории:
Оригинальный проект MrTheory:
https://github.com/MrTheory/os-xray
Наш форк:
https://github.com/SpyLive/os-xray
Спасибо MrTheory за оригинальную разработку и основу проекта.
Дальнейшее развитие форка будет продолжаться с сохранением открытого подхода и обратной совместимости с оригинальной архитектурой os-xray.
Данный проект является форком оригинального проекта MrTheory/os-xray, основанным на ветке разработки:
https://github.com/MrTheory/os-xray/tree/develop
Оригинальная ветка develop послужила основой проекта и предоставила базовую функциональность os-xray.
В рамках форка основной упор был сделан на стабилизацию работы, исправление проблем совместимости и подготовку production-релиза для актуальных версий OPNsense.
После тестирования и исправления выявленных проблем выпущен первый стабильный релиз нашего форка:
Code Select
os-xray v3.1.2
Основные изменения относительно оригинальной develop версии:
1. Исправлен порядок запуска при загрузке OPNsense
В процессе эксплуатации была обнаружена проблема взаимодействия между загрузкой OPNsense, настройкой маршрутизации и созданием TUN-интерфейса.
В некоторых сценариях OPNsense пытался применить настройки интерфейсов и маршрутов до того, как Xray/tun2socks успевали создать виртуальный интерфейс.
Возникали ошибки:
Code Select
Unable to configure nonexistent interface
refusing to set interface route on addressless interface
В v3.1.2 изменён порядок инициализации:
Code Select
xray-core
↓
tun2socks
↓
создание TUN-интерфейса
↓
назначение IP и MTU
↓
reload routing/firewall
Теперь после перезагрузки системы TUN-интерфейс корректно поднимается до применения маршрутов.
---
2. Улучшена инициализация TUN-интерфейса
Добавлено:
- увеличено время ожидания появления TUN-интерфейса;
- автоматическая установка MTU;
- назначение IPv4-адреса из конфигурации OPNsense;
- проверка корректности адресации перед обновлением маршрутизации.
---
3. Исправлен механизм запуска сервисов
Изменения:
- удалён устаревший дублирующий startup hook;
- оставлен единый механизм запуска через
Code Select
50-xray;- исправлена проверка UUID инстансов при старте.
---
4. Улучшена диагностика подключения
Исправлен механизм testconnect:
- используется актуальный SOCKS5 порт из конфигурации;
- DNS-запросы выполняются через Xray;
- устранены ошибки из-за локального DNS resolver OPNsense.
---
5. Проведён аудит стабильности перед релизом
Проверено:
- соответствие Git и установленной системы OPNsense;
- корректность boot lifecycle;
- запуск xray-core и tun2socks;
- создание и настройка TUN-интерфейса;
- маршрутизация через PF;
- реальный проход трафика через VPN;
- работа диагностических инструментов;
- статические тесты совместимости.
---
6. Новая структура разработки форка
После стабилизации проект переведён на собственную структуру веток:
Code Select
main
└── стабильные релизы форка
develop
└── дальнейшая разработка
fix/*
└── отдельные исправления
Текущий стабильный релиз:
Code Select
os-xray v3.1.2
---
Репозитории:
Оригинальный проект MrTheory:
https://github.com/MrTheory/os-xray
Наш форк:
https://github.com/SpyLive/os-xray
Спасибо MrTheory за оригинальную разработку и основу проекта.
Дальнейшее развитие форка будет продолжаться с сохранением открытого подхода и обратной совместимости с оригинальной архитектурой os-xray.
#42
German - Deutsch / Re: [Hardware] Temperaturen
Last post by Patrick M. Hausen - September 24, 2026, 12:14:56 PMCaddy als Reverse Proxy wäre in die OPNsense integriert.
#43
Hardware and Performance / Re: Upgrade from J6413 Questio...
Last post by Nullman - September 24, 2026, 12:12:38 PMQuote from: meyergru on September 23, 2026, 06:05:00 PMQuote from: nero355 on September 23, 2026, 04:09:13 PMMaybe shop around on the used market for something nice with 4 x Intel and something like the Intel N100 SoC for a good price ??
Or maybe something totally different that turns out to be a steal somehow ^_^
Alas, the "cheap" hardware options have left the building a while ago :-(
Some manufacturers like Qotom and Yanling have started to manufacture brand new units with DDR4 memory and 8th gen old Intel cpus, but they are slapping them with 2.5 and 10G NICs. Prices are more than acceptable.
#44
German - Deutsch / Re: [Hardware] Temperaturen
Last post by HBerger - September 24, 2026, 11:54:13 AMSorry, momentan erfordert das normale Leben grad mal bissi Aufmerksamkeit, war erstmal offline, und meine Hardware (also die Computer) sind es noch. Werde mich aber bald wieder damit beschäftigen können/dürfen.
Mein Anwendungsfall:
Home cloud / internnet ohne business kritischen background.
Ich hab nen relativ fetten proxmox server, consumer hardware basis. Da laufen paar services drauf, die on außen ansprechbar sein müssen, git, Jenkins, webdav, nen gameserver....
Das ganze hinter nem dyndns Zugang via docsis 3.1 modem.
Vorher hatte ich jahrelang nen linksys router, mit openwrt. Mit Umstellung der Leitung wurde der bissi zu langsam und wenn einem der Provider schon Gigabit aufdrängen muss... Will man's auch (THEORETISCH) nutzen.
Und die interne namensaufloesung (eigene Netz) war nicht zufriedenstellend.
Seid 2 Jahren hab ich das opnsense Teil Nu, bin zufrieden damit. Bis jetzt die ssd abrauchte...
Die configuration war absolut Standard, dns/dhcp via kea + standard online filter list zum rausfiltern des gröbsten schmutzes. Paar portforwardings noch dazu, das war eigentlich alles. Das ganze auf Hobby level, wenn das ausfällt, ärgert es nur mich
Die nächsten Themen die ich angehen will/muss haben nur tangentiell mit dem Router zu tun.
Reverse proxy Umstellung von nginx auf was besser wartbares mit let's encrypt integration (caddy z.b) und wohin packen...
Mein Anwendungsfall:
Home cloud / internnet ohne business kritischen background.
Ich hab nen relativ fetten proxmox server, consumer hardware basis. Da laufen paar services drauf, die on außen ansprechbar sein müssen, git, Jenkins, webdav, nen gameserver....
Das ganze hinter nem dyndns Zugang via docsis 3.1 modem.
Vorher hatte ich jahrelang nen linksys router, mit openwrt. Mit Umstellung der Leitung wurde der bissi zu langsam und wenn einem der Provider schon Gigabit aufdrängen muss... Will man's auch (THEORETISCH) nutzen.
Und die interne namensaufloesung (eigene Netz) war nicht zufriedenstellend.
Seid 2 Jahren hab ich das opnsense Teil Nu, bin zufrieden damit. Bis jetzt die ssd abrauchte...
Die configuration war absolut Standard, dns/dhcp via kea + standard online filter list zum rausfiltern des gröbsten schmutzes. Paar portforwardings noch dazu, das war eigentlich alles. Das ganze auf Hobby level, wenn das ausfällt, ärgert es nur mich
Die nächsten Themen die ich angehen will/muss haben nur tangentiell mit dem Router zu tun.
Reverse proxy Umstellung von nginx auf was besser wartbares mit let's encrypt integration (caddy z.b) und wohin packen...
#45
General Discussion / Re: nginx reverse proxy not ac...
Last post by Razorblade - September 24, 2026, 09:55:23 AMSorry, didn't receive a notification for your reply.
Yes, that could be an option but wouldn't resolve my problem.
The other certificate is working fine, so there must be an option to get the letsencrypt certificate working.
What could be issue with the certificate or nginx
Yes, that could be an option but wouldn't resolve my problem.
The other certificate is working fine, so there must be an option to get the letsencrypt certificate working.
What could be issue with the certificate or nginx
#46
26.1, 26,4 Series / Re: Unstable internet connecti...
Last post by GCustom - September 24, 2026, 09:10:05 AMQuote from: pseudonym3k on February 17, 2026, 05:43:21 PMQuote from: demyers on February 09, 2026, 05:23:36 PMThis might not be your problem, but I've found that some providers, particularly wireless providers, sometimes drop the abnormally small ping packets sent by dpinger. For all of my gateways I set "Data Length" to 56 (you'll need to switch on "Advanced Mode" to see this option).Just came in here again to say changing the data length to 56 has solved the issue for me (as far as dpinger giving false positives). I have been externally monitoring my own IP as well as the IP I am using for the monitor. The few failures I get now are due to monitor IP unreachable but my own connection was working.
I still need to think on monitoring as a whole in my situation. It is useful to me to know when my connection was disrupted, but only if actually true. If dpinger could check several IPs in series, and only if all fail assume the gateway unusable, it would mitigate the false positives from a single monitor IP being unreachable.
This one has been biting me several times over the past few weeks with my combination of ISPs and monitor addresses. I have multiple ISPs, and gateway flapping while I'm on a livestream is brutal.
Changing Data Length from the default 1 to 56 has already made a dramatic difference for me, so thanks for that. But I think the larger problem is still relying on a single monitor IP as the authority for whether a gateway is usable.
I'd really like to see multiple monitor targets per gateway, with some simple quorum/weighting logic, e.g. if one target stops answering but two others are healthy, don't declare the connection down. Those same few well-known targets could be reused across gateways while each gateway probes them through its own connection.
Recovery could use some asymmetry too: fail me off reasonably fast, bring me back more slowly. I'd rather require sustained evidence that a recovered connection is healthy before putting new states back on it than flap back and forth during an intermittent problem.
In short: one unreachable IP shouldn't be enough to declare an entire Internet connection dead, and recovery doesn't necessarily need to be as eager as failure detection.
#47
26.7 Series / Re: Why is he doing this? grap...
Last post by Patrick M. Hausen - September 24, 2026, 09:03:11 AMYou have multiple apparently conflicting repositories.
#48
26.7 Series / Why is he doing this? graphite...
Last post by halasizs - September 24, 2026, 08:35:07 AMWhy is he doing this? Do you always erase and install the same thing back? I've noticed him before.
You cannot view this attachment.
You cannot view this attachment.
#49
General Discussion / Re: http_proxy for bogons-upda...
Last post by OPNjk - September 24, 2026, 08:33:54 AMI recently added a "URL Table (IPs)" alias to the configuration of this firewall cluster.
What I realized: when I configure the table's URL in the GUI the request is being sent via the configured proxy. The hourly refetch of the URL is not done via the proxy at all: the proxy log is empty and I verified in a packet capture that the firewall retrieves the file directly. The log on the standby firewall (that does not have Internet access in the setup) has following log entry that also points in that direction:
I had a quick look into iter_addresses source code (alias/uri.py) and it looks as though no proxy is being set there?
What I realized: when I configure the table's URL in the GUI the request is being sent via the configured proxy. The hourly refetch of the URL is not done via the proxy at all: the proxy log is empty and I verified in a packet capture that the firewall retrieves the file directly. The log on the standby firewall (that does not have Internet access in the setup) has following log entry that also points in that direction:
Code Select
(Caused by NewConnectionError("HTTPSConnection(host='<hostname>', port=443): Failed to establish a new connection: [Errno 65] No route to host")))
I had a quick look into iter_addresses source code (alias/uri.py) and it looks as though no proxy is being set there?
#50
26.7 Series / Re: [26.7.4_1]Intermittent con...
Last post by meyergru - September 24, 2026, 08:14:13 AMThanks. This does not look like the LAPIC calibration problem from the thread I linked.
Your LAPIC frequency of about 500 MHz looks sane and is almost exactly what was reported for the working Proxmox case there. The broken case had a frequency off by roughly three orders of magnitude and around 65k timer interrupts/sec on every vCPU.
The `vmstat -i` numbers are interesting, but note that the displayed rate is averaged since boot, so it may hide what happens during one of the short stalls.
Since you are using `kvmclock`, I think one simple A/B test would still be worthwhile:
Leave everything else unchanged and see whether the stalls still occur. With several events per hour it should not take too long to get a useful result.
You can switch back with:
I would not conclude from the DTrace samples yet that the TCP retransmission timers are the cause. They may also be a consequence of the actual stall: if packet processing stops briefly, retransmission timers expire and `softclock_thread` subsequently has a lot of work to do.
The snapshot-related KVM clock problem I mentioned earlier also looks less likely in your case, since you have many events which clearly do not coincide with snapshots or backups.
Your LAPIC frequency of about 500 MHz looks sane and is almost exactly what was reported for the working Proxmox case there. The broken case had a frequency off by roughly three orders of magnitude and around 65k timer interrupts/sec on every vCPU.
The `vmstat -i` numbers are interesting, but note that the displayed rate is averaged since boot, so it may hide what happens during one of the short stalls.
Since you are using `kvmclock`, I think one simple A/B test would still be worthwhile:
Code Select
sysctl kern.timecounter.hardware=ACPI-fast
Leave everything else unchanged and see whether the stalls still occur. With several events per hour it should not take too long to get a useful result.
You can switch back with:
Code Select
sysctl kern.timecounter.hardware=kvmclock
I would not conclude from the DTrace samples yet that the TCP retransmission timers are the cause. They may also be a consequence of the actual stall: if packet processing stops briefly, retransmission timers expire and `softclock_thread` subsequently has a lot of work to do.
The snapshot-related KVM clock problem I mentioned earlier also looks less likely in your case, since you have many events which clearly do not coincide with snapshots or backups.
