방화벽과 NAT 뒤에 있는 두 대의 컴퓨터를 직접 연결하는 일은 여전히 번거롭다. 대개는 포트 포워딩을 열거나, 공인 IP를 가진 중계 서버를 세우거나, 별도의 터널링 서비스를 붙여야 한다. threatexpert가 공개한 gonc는 이 문제를 다른 방식으로 접근한다. Go로 작성된 넷캣(netcat) 계열 도구인 gonc는 양쪽이 동일한 패스프레이즈 하나만 공유하면 서로의 네트워크 주소를 자동으로 찾아내고 NAT를 관통해 점대점(P2P) 연결을 맺는다. 별도 설정 파일이나 고정 IP 없이 셸 접근, 파일 전송, 프록시를 한 바이너리로 처리하는 것이 목표다.
어떻게 서로를 찾아내는가
전통적인 넷캣은 IP와 포트를 알아야만 연결할 수 있다. gonc는 여기에 -p2p 옵션과 공유 패스프레이즈를 얹어 주소 교환 단계를 자동화한다. 공개 STUN 서버로 각자의 외부 매핑 주소를 알아내고, 공개 MQTT 서비스를 통해 그 정보를 주고받는다. 이때 패스프레이즈는 상대를 찾는 식별자인 동시에 인증서를 유도하는 재료로도 쓰인다. TCP는 TLS 1.3, UDP는 DTLS로 암호화하며, 패스프레이즈 기반의 상호 인증까지 수행하므로 중간에 주소를 교환하는 공개 서비스가 통신 내용을 들여다볼 수는 없다. 안전한 값이 필요하면 gonc -psk . 명령으로 고엔트로피 패스프레이즈를 생성해 대체할 수 있다.
gonc는 NAT를 세 유형으로 분류한다. 여러 STUN 서버에 대해 내부 포트가 동일한 외부 포트로 매핑되면 easy, 서버마다 일관되지만 다른 포트로 매핑되면 hard, 목적지에 따라 포트가 달라지면 가장 까다로운 symmetric다. gonc는 자체 진단에서 각 프로토콜 주소 뒤에 (easy)/(hard)/(symm) 표시를 붙여 홀 펀칭 성공 가능성을 미리 보여준다. symmetric 유형은 상대가 easy나 hard일 때만 P2P가 성립한다는 점도 명시된다.
NAT 관통을 위한 실제 전략
관통 자체는 여러 기법을 조합해 이뤄진다. 양쪽이 IPv6를 지원하면 TCP6 직결을 우선하고, TCP에서는 양쪽이 동시에 리슨하면서 서로에게 다이얼을 걸어 홀 펀칭 성공률을 높인다. UDP에서는 더 쉬운 쪽이 첫 패킷을 지연시켜 까다로운 쪽의 포트 변화를 유발하지 않도록 하고, 까다로운 쪽은 낮은 TTL의 패킷을 보내 원격 방화벽의 간섭을 줄인다. 그래도 안 되면 이른바 '생일 역설' 전략을 쓴다. 한쪽이 600개의 무작위 출발 포트를, 다른 쪽이 600개의 무작위 목적 포트를 시도해 포트 충돌 확률을 끌어올리는 방식이다. 예제에서는 양쪽에 IPv6가 있어도 -4 옵션으로 IPv4를 강제해 실제 NAT 관통을 시연한다.
타이밍 문제도 다룬다. 한쪽이 늦게 실행되면 약 30초 안에 상대를 찾지 못해 종료되는데, 이를 피하기 위해 MQTT 메시지 구독 기반의 대기 메커니즘을 제공한다. -mqtt-wait으로 계속 대기시키고 -mqtt-hello로 상대에게 신호를 보내 두 프로세스의 시작 시점을 맞추는 식이다.
셸, 파일, 프록시까지
gonc의 확장성은 -e 옵션에 있다. -e /bin/sh처럼 각 연결에 실행할 프로그램을 지정하면 원격 셸이 되고, 내장 가상 명령을 붙이면 별도 도구 없이 여러 서비스를 구성할 수 있다. -httpserver로 파일이나 디렉터리를 통째로 노출하면 수신 측은 재귀적으로 전체를 내려받되 중단 시 재실행으로 이어받기가 가능하고, 브라우저로 목록을 열어 선택 다운로드할 수도 있다. 프록시 쪽에서는 -e :s5s로 표준 SOCKS5를, -tls와 -psk를 더하면 TLS 위의 암호화된 SOCKS5를 만들 수 있고, 반대편은 :s5c로 이를 다시 표준 SOCKS5로 풀어 로컬 클라이언트에 제공한다. -auth로 인증, -acl로 접근 제어, -keep-open으로 다중 클라이언트 수용이 가능하다. 원격망의 10.0.0.1:3389 같은 대상은 127.b.c.d 형태로 인코딩된 주소를 통해 로컬 프록시로 우회 연결되도록 설계돼, 원격 데스크톱 같은 일반 클라이언트를 그대로 쓸 수 있다.
흥미로운 활용은 WireGuard 보조다. gonc가 UDP를 넷캣 방식으로 중계해 WireGuard 피어 사이의 NAT 관통을 돕고, -k 플래그로 네트워크가 끊겨도 자동 재연결하게 만든다. 이때 패스프레이즈로 WireGuard 피어의 공개키를 그대로 쓰는 점이 특징이다.
실무에서 따져볼 점
gonc의 매력은 명확하다. 중앙 서버 없이, 설정을 최소화한 채로, 암호화와 상호 인증이 기본 내장된 P2P를 얻는다. 다만 한계와 전제도 분명하다. 주소 교환이 공개 STUN·MQTT에 의존하므로 해당 서비스가 막힌 폐쇄망에서는 동작을 장담하기 어렵고, 양쪽 모두 symmetric NAT라면 순수 P2P는 실패한다. 이 경우 UDP 포워딩을 지원하는 SOCKS5 릴레이를 한쪽에만 -x 옵션으로 물리면 그쪽 NAT가 사실상 easy처럼 동작해 연결이 성립하며, 데이터는 여전히 종단 간 암호화가 유지된다는 점은 설계상 합리적이다. 릴레이는 자신의 VPS에서 gonc 내장 SOCKS5로 직접 띄울 수 있는데, 세션마다 무작위 포트를 쓰는 UDP 특성상 방화벽에서 1080 포트만 여는 것으로는 부족하다는 주의사항도 함께 기억해야 한다. 원격 셸과 프록시, 트래픽 포워딩을 손쉽게 붙일 수 있다는 것은 곧 오남용 시 위험도 크다는 뜻이므로, 접근 제어(-acl)와 인증을 기본값처럼 챙기고 권한 있는 환경에서만 쓰는 규율이 필요하다.