WireGuard로만 통하는 HTTPS 서비스를 위한 loopback의 Dante SOCKS

전용 SOCKS 리스너를 loopback에 바인딩하고 TCP 목적지 하나만 허용하십시오. Dante의 발신 소스, 커널 경로, DNS, 터널 손실 정책은 분리해 두십시오.

이 런북은 VPN 서버나 인터넷에 프록시 포트를 게시하지 않고도 프록시를 인지하는 애플리케이션에 기존 WireGuard 경로로의 접근을 제공합니다. SOCKS 데몬이 애플리케이션 인터페이스를 제공하고, WireGuard가 이미 승인된 IP 경로를 제공하며, 둘 다 사용자를 대신해 인증하지는 않습니다. 아래의 각 단계는 점검할 수 있는 결과를 만들고, 각각 되돌리는 방법이 있습니다. 인스턴스를 중지하거나, 규칙을 제거하거나, 애플리케이션의 프록시 설정을 없애면 됩니다. 여기서 호스트의 기본 경로는 바뀌지 않습니다.

이 예제는 Dante 1.4.x가 신뢰할 수 있는 Linux 워크스테이션에 전용 관리형 인스턴스로 설치되어 있고, 패키지가 제공하는 서비스 계정과 로깅 구성이 그 자리에 남아 있다고 가정합니다. 워크스테이션은 10.77.0.2 주소를 WireGuard 인터페이스에 보유하고, 그 터널을 통해 10.60.0.20:443 에 도달하며, 서비스의 정식 이름은 app.corp.example 입니다.

1단계: 리스너를 loopback에만 바인딩

네트워크, 메서드, 규칙 섹션을 인스턴스의 활성 구성에 넣고 예제 주소를 바꾸십시오. 모든 서버 설정은 규칙 블록 앞에 옵니다:

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

이것은 조각이며 패키지의 사용자 및 로깅 설정을 대신하지 않습니다. 사용하지 않는 로컬 포트를 고르고, 이 전용 인스턴스에 다른 리스너, 더 넓은 통과 규칙, 계약을 바꿀 상위 체이닝 항목이 없는지 확인하십시오. 이전 구성이 socks pass 을 목적지 제한 없이 남겼다면 무엇이든 시험하기 전에 제거하십시오.

이 단계의 되돌리기는 인스턴스를 중지하는 것입니다. 되돌리는 동안 구성 파일은 디스크에 남아 있어도 됩니다.

2단계: 규칙을 하나가 아니라 둘로 작성

Dante 구성 참조 는 두 규칙 유형에 서로 다른 역할을 부여합니다. 클라이언트 규칙은 loopback 리스너로의 연결을 허용하고, 그 목적지는 리스너 자체의 주소입니다. SOCKS 규칙은 요청된 이후 연결을 승인된 호스트와 포트로 허용합니다. 일치하지 않는 요청은 기본적으로 차단되므로, 규칙이 빠진 경우는 끊긴 경로와 똑같이 보입니다.

이 구성이 의도적으로 하지 않는 일에 주목하십시오. SOCKS 비밀번호를 요구하지 않습니다. 이는 신뢰할 수 있는 로컬 호스트에 적합하며, 사용자 인증은 아닙니다. 그 머신의 다른 프로세스도 loopback을 쓸 수 있습니다. 원격 애플리케이션 자체의 인증은 그대로 두고, 이 인증 없는 형태를 신뢰할 수 없는 로컬 사용자나 LAN을 향한 리스너에 다시 쓰지 마십시오.

3단계: 올바른 소스에서 경로 확인

external 는 발신 소스 주소를 선택할 뿐 WireGuard 경로를 설치하지 않습니다. 예제 소스와 목적지에 대한 읽기 전용 조회:

ip -4 route get 10.60.0.20 from 10.77.0.2

이것은 Dante의 실제 네트워크 네임스페이스에서 실행하고, 우연히 열어 둔 셸에서 실행하지 마십시오. 경로, WireGuard 피어 선택, 원격 측 권한, 반환 경로가 모두 그 소스 주소에 맞아야 합니다. 성공한 조회는 필요하지만 충분하지 않습니다. 원격 끝이 요청을 받아들이는지에 대해서는 아무것도 말하지 않기 때문입니다.

조회를 통과시키려고 기본 경로를 추가하고 싶은 유혹을 물리치십시오. 프록시 포트는 이 워크스테이션에만 있으며, 그것을 만들려고 호스트의 기본 경로를 바꾸면 설계 전체가 뒤집힙니다.

4단계: 의도한 신원으로 시험

소유자가 설치된 구성을 검증하고 서비스 관리자를 통해 인스턴스를 시작한 뒤의 예시 요청은 다음과 같습니다:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

다음과 함께 socks5h 이면 Dante가 목적지 확인을 수행하지만, Dante는 이 워크스테이션에서 실행되므로 그 설정만으로 DNS를 터널의 원격 끝으로 보내지는 않습니다. Dante가 사용하는 승인된 리졸버가 그 이름에 대해 허용된 주소를 반환해야 합니다. 빈 no-proxy 목록은 상속된 예외가 SOCKS를 조용히 우회하지 못하게 합니다.

시험에서 HTTPS 호스트 이름과 인증서 검증을 유지하고, 그다음 실제 리스너를 살펴 계약의 양쪽 절반을 확인하십시오. 허용된 요청은 성공하고 제외된 목적지는 실패해야 합니다. 지원되지 않는 전달 명령이 계속 거부되는지도 확인하십시오. 이 조각은 TCP 위의 SOCKS CONNECT 명령만 허용하며 일반 UDP나 기기 전체 터널 같은 것은 허용하지 않습니다.

5단계: 터널이 끊겼을 때의 동작 결정

이것을 운영이라고 부르기 전에 터널 손실과 인스턴스 재시작을 시험하십시오. WireGuard 다음에 Dante를 시작하는 감독자는 페일클로즈 라우팅을 만들지 않고, 페일클로즈 DNS도 만들지 않습니다. 둘 다 네트워크 소유자를 통해 강제해야 합니다. 터널이 내려가 있을 때 애플리케이션이 무엇을 하는지 보십시오. 깔끔한 오류는 좋은 결과이고, 공용 리졸버로 조용히 넘어가는 것은 아닙니다.

바인딩된 터널 주소가 바뀌면 업데이트를 조정하십시오. external 가 그것에 고정되어 있기 때문입니다. 이 구성이 더 이상 필요 없으면 이 인스턴스와 애플리케이션의 프록시 설정을 함께 은퇴시키고, WireGuard 경로는 그 소유자에게 남겨 두십시오.

관련 글