Краткое описание
Добавить в podkop штатный механизм для pre-sniff routing / no-sniff exceptions, чтобы отдельный трафик можно было направлять в выбранный outbound до общего TLS sniff.
Проблема, которую решает
При использовании Cloudflare Tunnel (cloudflared) через podkop + sing-box fake-ip/tproxy возникает проблема с TLS sniff.
cloudflared подключается к Cloudflare edge endpoint вида:
region1.v2.argotunnel.com:7844
region2.v2.argotunnel.com:7844
Но внутри TLS handshake использует SNI:
h2.cftunnel.com
Из-за общего TLS sniff routing может начать учитывать SNI h2.cftunnel.com, а не исходный destination region*.v2.argotunnel.com:7844.
В результате наблюдаются проблемы:
TLS handshake with edge error: EOF
или трафик уходит напрямую в Cloudflare edge, минуя VPN:
router_wan_ip -> 198.41.x.x:7844
Добавление h2.cftunnel.com / cftunnel.com в domain list не помогает, потому что это SNI/служебное имя, а не endpoint, к которому должен физически подключаться cloudflared.
💡 Предлагаемое решение
Добавить возможность задавать исключения, которые применяются до общего sniff rule. Например:
- additional tproxy inbound;
- pre-sniff route rule;
- custom nft rule before default tproxy-in;
- per-port/per-fake-ip no-sniff exception.
Пример желаемой логики:
match:
ip_cidr: 198.18.0.0/15
tcp_port: 7844
route:
outbound: main-out
sniff: false
Технически workaround выглядит так:
{
"type": "tproxy",
"tag": "cf-cloudflared-in",
"listen": "127.0.0.1",
"listen_port": 1603
}
И route rule до общего sniff:
{
"action": "route",
"inbound": "cf-cloudflared-in",
"outbound": "main-out"
}
Плюс nft rule до стандартного tproxy-in:
ip daddr 198.18.0.0/15 tcp dport 7844
tproxy ip to 127.0.0.1:1603 counter accept
comment "cf-cloudflared-no-sniff"
Ключевое чтобы пакет не попадал дальше в обычный tproxy-in со sniff.
Workaround
No response
Идеи реализации (опционально)
No response
Краткое описание
Добавить в podkop штатный механизм для pre-sniff routing / no-sniff exceptions, чтобы отдельный трафик можно было направлять в выбранный outbound до общего TLS sniff.
Проблема, которую решает
При использовании Cloudflare Tunnel (cloudflared) через podkop + sing-box fake-ip/tproxy возникает проблема с TLS sniff.
cloudflared подключается к Cloudflare edge endpoint вида:
region1.v2.argotunnel.com:7844
region2.v2.argotunnel.com:7844
Но внутри TLS handshake использует SNI:
h2.cftunnel.com
Из-за общего TLS sniff routing может начать учитывать SNI h2.cftunnel.com, а не исходный destination region*.v2.argotunnel.com:7844.
В результате наблюдаются проблемы:
TLS handshake with edge error: EOF
или трафик уходит напрямую в Cloudflare edge, минуя VPN:
router_wan_ip -> 198.41.x.x:7844
Добавление h2.cftunnel.com / cftunnel.com в domain list не помогает, потому что это SNI/служебное имя, а не endpoint, к которому должен физически подключаться cloudflared.
💡 Предлагаемое решение
Добавить возможность задавать исключения, которые применяются до общего sniff rule. Например:
Пример желаемой логики:
match:
ip_cidr: 198.18.0.0/15
tcp_port: 7844
route:
outbound: main-out
sniff: false
Технически workaround выглядит так:
{
"type": "tproxy",
"tag": "cf-cloudflared-in",
"listen": "127.0.0.1",
"listen_port": 1603
}
И route rule до общего sniff:
{
"action": "route",
"inbound": "cf-cloudflared-in",
"outbound": "main-out"
}
Плюс nft rule до стандартного tproxy-in:
ip daddr 198.18.0.0/15 tcp dport 7844
tproxy ip to 127.0.0.1:1603 counter accept
comment "cf-cloudflared-no-sniff"
Ключевое чтобы пакет не попадал дальше в обычный tproxy-in со sniff.
Workaround
No response
Идеи реализации (опционально)
No response