Clash: 게이트웨이 프록시로서의 가짜 IP 모드의 몇 가지 문제

TUN 모드는이 두 가지 문제를 해결합니다.

이제 클래시를 라우터에서 투명 프록시로 사용하고 fake-ip를 사용하고 싶습니다. TUN 모드를 사용할 수 있습니까? 그렇다면 일부 구성 정보를 공유 할 수 있습니까?

더 합리적이라고 생각하기 때문에 가짜 IP (redir-host 대비)를 사용하고 싶습니다. 현재 거의 모든 상황이 잘 작동합니다. 유일한 문제는 King Glory 탐지가 지연되면 연결이 실패한다는 것입니다. udp는 가짜 ip 문제를 사용하므로 물어보고 싶습니다.

감사합니다.

TUN은 아직 구현되지 않았습니다. 현재 사용하는 방법은 UDP없이 fakeip을 사용하고 필요한 경우 redir-host를 사용하는 것입니다 (즉, 두 개의 Clash 인스턴스를 엽니 다).

2019 년 7 월 27 일 토요일 오전 2시 43 분 AylinZhao [email protected] 작성 :

이제 클래시를 라우터에서 투명 프록시로 사용하고 fake-ip를 사용하고 싶습니다. TUN 모드를 사용할 수 있습니까? 그렇다면 일부 구성 정보를 공유 할 수 있습니까?

가짜를 사용하고 싶다
ip (redir-host에 비해)의 이유는 더 합리적이기 때문입니다. 현재 거의 모든 상황이 잘 작동하고 있습니다. 유일한 문제는 영광의 왕 탐지가 지연되면 연결이 실패한다는 것입니다. udp는 가짜를 사용합니다.
ip 문제이므로 물어보고 싶습니다.

감사합니다.

—
스레드를 작성했기 때문에 수신 한 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Dreamacro/clash/issues/179?email_source=notifications&email_token=AB6FI752JQQZPMZBH4KYEHLQBNAWRA5CNFSM4HMJDBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJ25MVBW63LNMVXHJ25MVBW63LNMVXHJK25MZBH4KYEHLQBNAWRA5CNFSM4HMJDBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJK515MZ559,issued
또는 스레드 음소거
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

Plus Sukka가 발명 한 가짜 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

이러한 방식으로 Fake 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

Plus Sukka가 발명 한 가짜 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

이러한 방식으로 Fake IP가 필요한 장치는 DNS를 198.19.0.1로 변경할 수 있습니다.

편집 : 가짜 IP CIDR 수정

당신의 방법은 좋습니다. 시도해보고 싶습니다.
2 개의 Clash 인스턴스를 여는 방법은 무엇입니까? 프록시 포트 중 하나가 9999로 설정되어 있습니까?

1. 현재 Clash는 가짜 IP의 ICMP 패킷에 응답하지 않으므로 일부 응용 프로그램에서 예기치 않은 동작이 발생할 수 있습니다.
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 클라우드는 인터넷에 연결할 수 없습니다.

이러한 모델 fake-ip-proxy-only를 고려할 수 있습니까?

1. 프록시가 필요한 도메인 이름의 경우 가짜 IP를 반환합니다.
2. 다른 도메인 이름의 경우 항상 실제 IP가 반환됩니다.
   2.1 직접 연결을 정의하는 도메인 이름 규칙이있는 경우 실제 IP가 필요합니다.
   2.2 프록시 (지리 규칙)가 필요한 IP 세그먼트의 경우 먼저 실제 IP를 쿼리 한 다음 지리적 데이터베이스를 비교 한 다음 연결을 시작해야합니다.
   2.3 나머지 직접 연결된 IP 세그먼트의 경우 실제 IP도 필요합니다.

이러한 방식으로 프록시해야하는 도메인 이름에 대해 불필요한 DNS 쿼리가 여전히 생성되지 않습니다.
프록시가 필요한 IP 세그먼트의 경우 연결을 시작하는 시간은 동일합니다.
다른 상황에서는 실제 IP가 필요합니다.

프로세스에 대한 이해가 올바른지 모르겠습니다. 수정 해주세요.

개발자가 이러한 새로운 기능을 고려할 수 있기를 바라지 만 여전히 그렇게하는 것은 불가능 해 보입니다.