일부 Linux 컴퓨터에서 netcat을 사용하고 있지만 (이 다른 질문 참조 ) 예기치 않은 동작이 발생합니다.
허용 된 답변의 가이드와 달리 UDP 터널링을 사용하여 DNS 쿼리를 수행하지 않습니다. 로그인 할 수 있지만 소프트웨어를 설치할 수없는 원격 서버가 있고 컴퓨터에서 서버로 UDP 트래픽을 터널링하려고 시도한 다음 서버에서 내 컴퓨터로 UDP 응답을 보내도록 별도의 터널을 설정하려고합니다 .
내 컴퓨터에서 서버로가는 터널은 완벽하게 작동하지만 서버 측에서는 UDP 서버의 응답을 수신하는 netcat 인스턴스가 첫 번째 응답을받은 후 리스너를 닫습니다. 따라서 요청을 보내고 1 개의 응답을 다시받을 수 있지만 이후의 요청은 서버에 정상적으로 응답하지만 응답이 수신되지 않습니다. netstat를 사용하면 응답을 받기 전에 netcat이 수신 대기 중이지만 응답을받은 후 포트가 닫힙니다.
내 컴퓨터의 netcat 인스턴스는 모든 것을 잘 처리하는 것 같습니다. 두 시스템 모두 netcat v1.10-38을 실행 중입니다. 어떤 아이디어가 일어나고 있습니까?
답변
따라서 netcat이라는 여러 가지가 있습니다. 우분투에는 / etc / alternatives symbolic-link-hackery도 있습니다.
문제의 일부는 UDP가 세션을 수행하지 않는다는 것입니다. 아래에서 /usr/share/doc/netcat-traditional/README.gz 파일의 일부를 복사했습니다.
-u가 지정되면 TCP 대신 UDP 연결이 열립니다. netcat은 내부적으로 대부분의 커널이 지원하는 “connected UDP socket”메커니즘을 내부적으로 사용하지만 UDP는 비 연결 프로토콜이기 때문에 실제로는 “연결”이 아닙니다. netcat은 나가는 UDP 연결이 즉시 “개방”되었다고 주장하지만 표준 입력에서 무언가를 읽을 때까지 데이터가 전송되지 않습니다. 그 후에야 상대방 서버에 실제로 UDP 서버가 있는지 확인할 수 있으며 종종 알 수 없습니다. 대부분의 UDP 프로토콜은 시간 초과 및 재 시도를 사용하여 작업을 수행하며 대부분의 경우 전혀 응답하지 않으므로 시간 초과를 지정하고 최선을 다해야합니다.
알았어요. 어쩌면 그것은 그다지 설명이 전부가 아니지만 내가 찾을 수있는 것입니다.
아직하지 않았다면 대기와 관련이있는 netcat 옵션을 실험 해보고 싶을 것입니다 …
-
“듣기”모드에 있도록 -l 및 -u 사용
-
-vv 정확히 무슨 일이 일어나고 있는지
-
-q -1 … EOF를받은 후에도 “영원히 기다려야합니다”(다시 듣고 싶습니까?)
답변
사용할 수 있습니다 socat. 매우 좋은 옵션이 있습니다 fork.
fork연결을 설정 한 후 하위 프로세스에서 채널을 처리하고 상위 프로세스가 청취 또는 루프 연결 (예)을 통해 더 많은 연결을 생성하려고합니다.
클라이언트 (예, 클라이언트에서 실행) :
$ ssh -L 7753:localhost:7753 YourServer.com "/usr/bin/socat tcp4-listen:7753,reuseaddr,fork UDP:8.8.8.8:53"
고객:
$ sudo socat udp4-listen:53,reuseaddr,fork tcp:localhost:7753
$ dig @127.0.0.1 google.com