☰

포트 443 TCP 터널의 Wireguard, 차단된 포트 우회, OpenWRT 솔루션

tag-icon • tag-icon firewall vpn tunneling wireguard
포트 443 TCP 터널의 Wireguard, 차단된 포트 우회, OpenWRT 솔루션

문제가 발생했습니다. OpenWRT를 사용하여 많은 임베디드 장치를 Wireguard 서버에 연결하고 싶지만 80, 443 및 기타 포트를 제외한 모든 포트가 차단됩니다. 또한 네트워크에서는 TCP만 허용됩니다.

WireGuard 터널 UDP를 TCP로 연결해야 하는 것 같습니다. 내 서버에서 SSHL(포트 공유) 서비스를 사용하여 443(또는 방화벽에서 허용하는 다른 포트)에서 HTTPS 서버와 WireGuard 터널을 모두 실행하려고 합니다. 여러 사용자를 지원하는 터널을 갖고 싶기 때문에 빠른 socat 해킹이 더 많은 클라이언트에서 작동하지 않을 것이라고 생각합니다.

  • 시도해 보았는데 wireguard-proxySSLH를 통한 포트 공유에는 완벽하게 작동하지만 Rust로 작성되어 OpenWRT에 배포할 수 없습니다(시도했지만 컴파일 오류가 발생했습니다). - 테스트도 해봤는데 udp2raw전용 포트에서는 잘 작동하지만 SSLH 포트 멀티플렉서를 사용할 때는 연결할 수 없습니다.

OpenWRT 빌드 시스템에서 크로스 컴파일하고 수정된 네트워크 장비와 함께 사용할 수 있는 C/C++로 작성된 터널링 소프트웨어를 찾고 있습니다.

답변1

당신은 그것을 사용할 수 있습니다socat터널링 소프트웨어로.

이는 포트 51820에서 수신 대기하는 WireGuard를 사용한 일반적인 설정(대화식으로 수행됨)입니다. 시작 서비스에는 여전히 완전한 통합이 필요합니다.

OpenWRT(그러나 실제로는 다른 Linux에서 테스트됨)

  • 평소와 같이 Wireguard 인터페이스를 활성화하십시오.

    ... MTU 제외: 아래 설명의 설명을 참조하세요. 1420-64=1356의 MTU를 사용하겠습니다. 예( 를 wg0.conf사용할 때 실제로 수행되어야 함 wg-quick):

    ip link set wg0 mtu 1356

  • 터미널 1:

    sslh -n --listen 0.0.0.0:443 \
    --tls 127.0.0.1:8443 \
    --anyprot 127.0.0.1:51820 \
    -f

    sslhWireGuard의 프로토콜이 인식되지 않아 --anyprot목적지로 이동합니다.

  • 터미널 2:

    socat -T 120 \
    tcp4-listen:51820,bind=127.0.0.1,reuseaddr,nodelay,fork \
    udp4-connect:127.0.0.1:51820

    ~처럼socat제안다른 경우:

    참고: 두 Socat "라인 측" 간에 패킷을 전송하려는 경우 UDP와 같이 패킷 경계를 유지하는 프로토콜이 필요합니다.TCP는 Nodelay 옵션과 함께 사용될 수 있습니다..

    sslh특별히 사용되지 는 않지만노드 레이아웃, socat둘 다 할 것입니다. 이것이 이 부분에 도움이 되기를 바랍니다.

    이는 -T 120포크가 끝나기 전의 비활성 지연입니다. socat클라이언트가 로밍하고 연결이 끊어진 경우 유용합니다. 클라이언트 WireGuard 지속성을 유지하려면 예상보다 높은 값으로 설정해야 합니다. 어쨌든, 이는 TLS가 아닌 DDoS 사례에는 별로 도움이 되지 않습니다. socatDoS에만 도움이 될 수 있는 여러 개의 포크가 있을 것입니다(WireGuard 자체는 이러한 트래픽을 무시합니다).

고객

  • 터미널 1:

    socat -T 120 \
    udp4-listen:51821,bind=127.0.0.1,fork \
    tcp4:public-endpoint:51820,nodelay

    실제로 클라이언트가 로밍하는 경우 socatTCP 부분이 정상적으로 실패하는 데 시간이 걸릴 수 있으므로 명령을 다시 시작해야 할 수도 있습니다.

  • 라인배커 인터페이스

    이전과 마찬가지로 MTU를 낮춥니다. Linux에서는 다음과 같습니다.

    ip link set wg0 mtu 1356

    그리고 피어 끝점을 변경하여 현재 로컬 시스템에 있는 터널 입구로 전환합니다(다시 클라이언트에서 수행해야 함 wg0.conf).

    wg set wg0 peer XXXXXXXXX= endpoint 127.0.0.1:51821

이제 클라이언트가 터널 내부에서 패킷을 보내고 인증하면 서버의 WireGuard는 클라이언트 엔드포인트(local에서 127.0.0.1:randomport로 socat)를 업데이트하고 응답할 수 있습니다. 이를 통해 전이중 통신이 가능해집니다.

client ⟺ WG ⟺ UDP ⟺ socat ⟺ TCP over Internet 
                                          ⇧
                                          ⇩
server ⟺ WG ⟺ UDP ⟺ socat ⟺ TCP ⟺ sslh

노트

  • MTU 참고 사항

    일반적인 80바이트의 오버헤드(1500-80=1420) WireGuard 예약 외에 TCP 오버헤드도 추가해야 합니다. 이는 외부 터널 계층이 두 개의 TCP 패킷에서 페이로드가 너무 커지는 것을 기본 프로토콜이 인식하지 못하는 것을 방지하기 위한 것입니다 socat. sslh이로 인해 적어도 두 번째로 캡슐화된 UDP 페이로드가 손상되어 재전송이 발생할 수 있습니다.

    이 오버헤드는 실제로 동적입니다. IPv4의 경우 IP의 경우 최소 20, TCP의 경우 20입니다. 그런 다음 최신 TCP 연결은 2+8+2=12바이트를 타임스탬프로 사용하고 패킷이 손실되면 임의의 수의 SACK를 사용해야 합니다. (2+2*4+2=12): 20+20+12+12=64를 생각해 보겠습니다. 정확한 값은 중요하지 않습니다(각 옵션을 정렬하기 위해 실제로 두 TCP 옵션 사이에 두 개의 TCP NOP가 있습니까? 모르겠습니다). 그래서 결국 저는 WireGuard MTU를 1420-64=1356으로 선택했습니다.

    실제 물리적 LAN에 대한 일부 테스트에서는 ping -M do -s $MTU-28 -f 10.x.x.x인터페이스에서 MTU=1420을 유지하면 약 40%의 패킷 손실이 발생한 반면 MTU=1356에서는 패킷이 손실되지 않았으며 더 높은 MTU로도 충분한 것으로 나타났습니다.

  • 포트 443은 제한되어 있으며 SSL이 필요합니다.

    포트 443을 제한하는 방화벽이 해당 포트의 SSL 트래픽만 예상하는 경우 상황은 더욱 복잡해집니다. 하나는 sslh다음으로 교체되어야합니다haproxy또는nginx(둘 다 OpenWRT에 패키지된 것 같습니다. 필요한 기능을 사용할 수 있는지는 모르겠습니다) TLS 패스스루 기능을 사용하여 수신된 ClientHello를 기반으로 TLS 연결을 라우팅합니다.신경망연구소. 그러면 두 s는 / 대신 / socat와 통신 하지만 이 경우 MTU가 어떤 영향을 받을지는 잘 모르겠습니다.tcp-listentcpopenssl-listenopenssl

관련 정보