go mmproxy

go-mmproxy

이는 mmproxy의 런타임 안정성을 개선하는 동시에 연결 및 패킷 처리량 측면에서 잠재적으로 더 높은 성능을 제공하기 위해 만들어진 mmproxy의 Go 재구현입니다.

go-mmproxy 는 HAProxy의 PROXY 프로토콜(NGINX와 같은 다른 프로젝트에서도 채택)을 풀어서 최종 서버에 대한 네트워크 연결이 프록시 서버 대신 클라이언트의 IP 주소와 포트 번호에서 나오도록 하는 독립 실행형 애플리케이션입니다. 기본 메커니즘을 공유하기 때문에 Cloudflare의 mmproxy 블로그 게시물은 go-mmproxy 내부적으로 어떻게 작동하는지에 대한 훌륭한 글을 제공합니다.

건물

go install github.com/path-network/go-mmproxy@latest

go-mmproxy 바이너리를 빌드하려면 최소한 go 1.21 필요합니다. 패키지 관리자가 충분히 새로운 버전의 golang을 갖고 있지 않다면 Go의 시작하기를 참조하세요.

요구사항

go-mmproxy 실행해야 합니다.

• 통신이 루프백 인터페이스를 통해 발생하므로 프록시 대상과 동일한 서버에 있어야 합니다.
• 루트로 또는 CAP_NET_ADMIN 기능을 사용하여 IP_TRANSPARENT 소켓 옵션을 설정할 수 있습니다.

달리기

라우팅 설정

루프백에서 발생하는 모든 트래픽을 루프백으로 라우팅합니다.

ip rule add from 127.0.0.1/8 iif lo table 123
ip route add local 0.0.0.0/0 dev lo table 123

ip -6 rule add from ::1/128 iif lo table 123
ip -6 route add local ::/0 dev lo table 123

--mark 옵션이 go-mmproxy 에 제공되면 루프백 인터페이스로 라우팅되는 모든 패킷에 표시가 설정됩니다. 예를 들어 루프백의 트래픽을 시스템 외부로 라우팅해야 하는 경우와 같이 iptables를 사용하여 고급 라우팅 규칙을 설정하는 데 사용할 수 있습니다.

UDP 패킷 라우팅

UDP는 연결이 없기 때문에 소켓이 0.0.0.0 에 바인딩되면 커널 스택은 원래 패킷을 받은 인터페이스를 사용하는 대신 스푸핑된 소스 주소에 응답을 보내기 위해 인터페이스를 검색합니다. 발견된 인터페이스는 위에 지정된 규칙을 피하는 루프백 인터페이스가 아닐 가능성이 높습니다. 이 문제를 해결하는 가장 간단한 방법은 최종 서버의 리스너를 127.0.0.1 (또는 ::1 )에 바인딩하는 것입니다. 이는 프록시되지 않은 연결 수신을 방지하기 위해 일반적으로 권장됩니다.

go-mmproxy 시작

 Usage of ./go-mmproxy:
  -4 string
    	Address to which IPv4 traffic will be forwarded to (default "127.0.0.1:443")
  -6 string
    	Address to which IPv6 traffic will be forwarded to (default "[::1]:443")
  -allowed-subnets string
    	Path to a file that contains allowed subnets of the proxy servers
  -close-after int
    	Number of seconds after which UDP socket will be cleaned up (default 60)
  -l string
    	Address the proxy listens on (default "0.0.0.0:8443")
  -listeners int
    	Number of listener sockets that will be opened for the listen address (Linux 3.9+) (default 1)
  -mark int
    	The mark that will be set on outbound packets
  -p string
    	Protocol that will be proxied: tcp, udp (default "tcp")
  -v int
    	0 - no logging of individual connections
    	1 - log errors occurring in individual connections
    	2 - log all state changes of individual connections

호출 예시:

sudo ./go-mmproxy -l 0.0.0.0:25577 -4 127.0.0.1:25578 -6 [::1]:25578 --allowed-subnets ./path-prefixes.txt

기준

설정

벤치마크는 Intel Core i9-8950HK CPU @ 2.90GHz(논리 코어 12개)를 갖춘 Dell XPS 9570에서 실행되었습니다. 프록시가 트래픽을 보낸 업스트림 서비스가 bpf-echo 서버에 의해 조롱되었습니다. 트래픽은 tcpkali v1.1.1에 의해 생성되었습니다.

모든 경우에 로드 생성을 위해 다음 명령이 사용되었습니다(연결 50개, 런타임 10초, 각 연결에 대해 PROXYv1 헤더 전송, PINGrn TCP 메시지로 사용).

 tcpkali -c 50 -T 10s -e1 'PROXY TCP4 127.0.0.1 127.0.0.1 {connection.uid} 25578rn' -m 'PINGrn' 127.0.0.1:1122

결과

	⇅Mbps	↓Mbps	↑Mbps	↓ 패킷/초	↑ 패킷/초
클라우드플레어/mmproxy	1524.454	756.385	768.069	70365.9	65921.9
go-mmproxy GOMAXPROCS=1	7418.312	2858.794	4559.518	262062.7	391334.6
go-mmproxy	45483.233	16142.348	29340.885	1477889.6	2518271.5
프록시 없음	52640.116	22561.129	30078.987	2065805.4	2581621.3