Clash: Некоторые проблемы режима Fake IP в качестве прокси шлюза

Созданный на 12 мая 2019  ·  17Комментарии  ·  Источник: Dreamacro/clash

  1. В настоящее время Clash не отвечает на ICMP-пакеты с поддельным IP-адресом, что может вызвать неожиданное поведение некоторых приложений.
  2. Поскольку используется поддельный IP-адрес, а в Clash в настоящее время нет возможностей пересылки UDP, некоторые приложения UDP будут пытаться подключиться к поддельному IP-адресу и терпят неудачу (например, TeamSpeak)

Все 17 Комментарий

Режим TUN решит эти две проблемы

Я хотел бы спросить, теперь я использую clash как прозрачный прокси на маршрутизаторе и надеюсь использовать fake-ip. Могу ли я использовать режим TUN? Если да, могу ли я поделиться некоторой информацией о конфигурации?

Я надеюсь использовать поддельный IP-адрес (по сравнению с redir-host), потому что я думаю, что это более разумно. В настоящее время почти все ситуации работают хорошо. Единственная проблема в том, что соединение не удается, когда обнаружение короля славы задерживается. ip проблема, поэтому я хотел бы спросить.

Большое спасибо.

TUN еще не реализован. Моя текущая практика - взять fakeip без UDP и взять redir-host (то есть открыть два экземпляра Clash)

В сб, 27 июля 2019 г., в 2:43 AylinZhao [email protected] написал:

Я хотел бы спросить, теперь я использую clash как прозрачный прокси на маршрутизаторе и надеюсь использовать fake-ip, могу ли я использовать режим TUN? Если да, могу ли я поделиться некоторой информацией о конфигурации?

Хочу использовать подделку
Причина использования ip (по сравнению с redir-host) заключается в том, что он более разумен. В настоящее время почти все ситуации работают хорошо. Единственная проблема заключается в том, что соединение не может быть подключено, когда обнаружение короля славы задерживается.
ip проблема, поэтому хочу спросить.

Большое спасибо.

-
Вы получаете это, потому что вы являетесь автором темы.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Dreamacro/clash/issues/179?email_source=notifications&email_token=AB6FI752JQQZPMZBH4KYEHLQBNAWRA5CNFSM4HMJDBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBW63LNMVXHJK25MZBH4KYEHLQBNAWRA5CNFSM4HMJDBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBH4KYEHLQBNAWRA5CNFSM5
или отключить поток
https://github.com/notifications/unsubscribe-auth/AB6FI7YKTOA2BX525XOUELLQBNAWRANCNFSM4HMJDBCQ
.

@BirkhoffLee Спасибо, идея очень хорошая, могу ли я переключаться на разные экземпляры через iptables?Если да, можете ли вы рассказать о способе переадресации?

@BirkhoffLee Спасибо, идея очень хорошая, перенаправляется ли она на разные экземпляры через iptables?Если да, можете ли вы рассказать о способе переадресации?

Тот же метод, что и экземпляр, но два iptables DNAT:

# 到 fake ip range 的 tcp 全部轉發到 clash fakeip
iptables -t nat -A clash_lan -p tcp -d 198.18.0.0/16 -j DNAT --to-destination 10.0.1.6:23456

# 其他 tcp 80/443 全部轉發到 clash redirhost
iptables -t nat -A clash_lan \! -d 198.18.0.0/16 -p tcp --dport 80 -j DNAT --to-destination 10.0.1.6:9999
iptables -t nat -A clash_lan \! -d 198.18.0.0/16 -p tcp --dport 443 -j DNAT --to-destination 10.0.1.6:9999

iptables -t nat -A PREROUTING -p tcp -j clash_lan

Плюс поддельный DNS, изобретенный Суккой

iptables -t nat -N clash_fakedns
iptables -t nat -A clash_fakedns -p udp --dport 53 -j DNAT --to-destination 10.0.1.6:23453
iptables -t nat -A clash_fakedns -p tcp --dport 53 -j DNAT --to-destination 10.0.1.6:23453

iptables -t nat -A PREROUTING -p udp -d 198.19.0.0/24 -j clash_fakedns
iptables -t nat -A PREROUTING -p tcp -d 198.19.0.0/24 -j clash_fakedns

Таким образом, устройство, которому требуется поддельный IP-адрес, может изменить DNS на 198.19.0.1.

РЕДАКТИРОВАТЬ: исправленный поддельный IP-адрес CIDR

Спасибо, что поделился. Я понимаю, что это нужно для реализации разных стратегий разрешения, устанавливая разные DNS для разных устройств.

Моя текущая ситуация такова, что при условии, что маршрутизатор настроен с прозрачным прокси, то же самое устройство (мой мобильный телефон), некоторый трафик UDP (тест задержки King of Honor) надеется обработать правильно, я не знаю, есть ли какой-либо способ.

Предпочтительное решение - все делается на маршрутизаторе и прозрачно для всех устройств.

Спасибо, что поделился. Я понимаю, что это нужно для реализации разных стратегий разрешения, устанавливая разные DNS для разных устройств.

Моя текущая ситуация такова, что при условии, что маршрутизатор настроен с прозрачным прокси, то же самое устройство (мой мобильный телефон), некоторый трафик UDP (тест задержки King of Honor) надеется обработать правильно, я не знаю, есть ли какой-либо способ.

Предпочтительное решение - все делается на маршрутизаторе и прозрачно для всех устройств.

Еще нет

Понимаю, еще раз спасибо

Можете ли вы считать такую ​​модель fake-ip-proxy-only:

  1. Для доменных имен, требующих прокси, верните поддельный IP
  2. Для других доменных имен всегда будет возвращаться реальный ip
    2.1 Если есть правило доменного имени, которое определяет прямое соединение, требуется реальный IP
    2.2 Для сегмента ip, который требует прокси (географические правила), ему также необходимо сначала запросить реальный ip, а затем сравнить базу данных гео, а затем инициировать соединение
    2.3 Для остальных напрямую подключенных сегментов IP также требуется реальный IP

Таким образом, ненужные запросы DNS по-прежнему не генерируются для доменных имен, которые необходимо проксировать.
Для сегмента ip, которому требуется прокси, время инициации соединения такое же.
В остальных случаях требуется настоящий IP.

Я не знаю, правильно ли я понимаю процесс, поправьте меня.

Можете ли вы считать такую ​​модель fake-ip-proxy-only:

  1. Для доменных имен, требующих прокси, верните поддельный IP
  2. Для других доменных имен всегда будет возвращаться реальный ip
    2.1 Если есть правило доменного имени, которое определяет прямое соединение, требуется реальный IP
    2.2 Для сегмента ip, который требует прокси (географические правила), ему также необходимо сначала запросить реальный ip, а затем сравнить базу данных гео, а затем инициировать соединение
    2.3 Для остальных напрямую подключенных сегментов IP также требуется реальный IP

Таким образом, ненужные запросы DNS по-прежнему не генерируются для доменных имен, которые необходимо проксировать.
Для сегмента ip, которому требуется прокси, время инициации соединения такое же.
В остальных случаях требуется настоящий IP.

Я не знаю, правильно ли я понимаю процесс, поправьте меня.

Только поддельный возврат ip выполняется для доменного имени, которое будет проксировано в правилах, а остальные все возвращают реальный ip?

@beyondkmp да

@BirkhoffLee Спасибо, идея очень хорошая, перенаправляется ли она на разные экземпляры через iptables?Если да, можете ли вы рассказать о способе переадресации?

Тот же метод, что и экземпляр, но два iptables DNAT:

# 到 fake ip range 的 tcp 全部轉發到 clash fakeip
iptables -t nat -A clash_lan -p tcp -d 198.18.0.0/16 -j DNAT --to-destination 10.0.1.6:23456

# 其他 tcp 80/443 全部轉發到 clash redirhost
iptables -t nat -A clash_lan \! -d 198.18.0.0/16 -p tcp --dport 80 -j DNAT --to-destination 10.0.1.6:9999
iptables -t nat -A clash_lan \! -d 198.18.0.0/16 -p tcp --dport 443 -j DNAT --to-destination 10.0.1.6:9999

iptables -t nat -A PREROUTING -p tcp -j clash_lan

Плюс поддельный DNS, изобретенный Суккой

iptables -t nat -N clash_fakedns
iptables -t nat -A clash_fakedns -p udp --dport 53 -j DNAT --to-destination 10.0.1.6:23453
iptables -t nat -A clash_fakedns -p tcp --dport 53 -j DNAT --to-destination 10.0.1.6:23453

iptables -t nat -A PREROUTING -p udp -d 198.19.0.0/24 -j clash_fakedns
iptables -t nat -A PREROUTING -p tcp -d 198.19.0.0/24 -j clash_fakedns

Таким образом, устройство, которому требуется поддельный IP-адрес, может изменить DNS на 198.19.0.1.

РЕДАКТИРОВАТЬ: исправленный поддельный IP-адрес CIDR

Ваш метод хорош, хочу попробовать, могу я спросить,
Как открыть 2 инстанса Clash? Один из портов прокси установлен на 9999?

  1. В настоящее время Clash не отвечает на ICMP-пакеты с поддельным IP-адресом, что может вызвать неожиданное поведение некоторых приложений.
  2. Поскольку используется поддельный IP-адрес, а в Clash в настоящее время нет возможностей пересылки UDP, некоторые приложения UDP будут пытаться подключиться к поддельному IP-адресу и терпят неудачу (например, TeamSpeak)

https://github.com/vernesong/OpenClash/releases/tag/v0.33.7-beta
Openclash версии 0.33.7 предоставляет решение, создавая список доменных имен, чтобы разрешить конкретным доменным именам использовать определенные DNS.

https://github.com/Dreamacro/clash/releases/tag/TUN Вы можете попробовать экспериментальный двоичный файл TUN

Этот механизм подделки настолько сложен, что сразу распаковать и получить хост вроде v2ray не удобнее.

В режиме поддельного IP-адреса JMGO Cloud не может подключиться к Интернету.

Можете ли вы считать такую ​​модель fake-ip-proxy-only:

  1. Для доменных имен, требующих прокси, верните поддельный IP
  2. Для других доменных имен всегда будет возвращаться реальный ip
    2.1 Если есть правило доменного имени, которое определяет прямое соединение, требуется реальный IP
    2.2 Для сегмента ip, который требует прокси (географические правила), ему также необходимо сначала запросить реальный ip, а затем сравнить базу данных гео, а затем инициировать соединение
    2.3 Для остальных напрямую подключенных сегментов IP также требуется реальный IP

Таким образом, ненужные запросы DNS по-прежнему не генерируются для доменных имен, которые необходимо проксировать.
Для сегмента ip, которому требуется прокси, время инициации соединения такое же.
В остальных случаях требуется настоящий IP.

Я не знаю, правильно ли я понимаю процесс, поправьте меня.

Я надеюсь, что разработчики смогут рассмотреть такие новые возможности, но это все еще кажется невозможным.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги