VPN 전에 Tor 준비: 시작 게이트를 올바르게 정렬하기

tor 프로세스를 지켜본 다음 VPN을 시작하는 것은 이 스택을 잘못 구성하는 가장 흔한 방법이다. 데몬은 클라이언트 스트림을 실어 나를 수 있기 훨씬 전에 나타나며, 고정된 대기는 의존성으로 위장한 추측일 뿐이다. 게이트는 다음 구성 요소가 실제로 필요로 하는 상태여야 한다. 아래 네 단계를 순서대로 밟고, 각 단계를 조정할 지연이 아니라 별도의 조건으로 다루어라.

1단계: 실제로 가지고 있는 전송을 고르라

나머지 설계가 그것에 달려 있으므로 프로토콜부터 시작하라. Tor의 SOCKS 인터페이스는 UDP ASSOCIATE를 구현하지 않으므로, 그 위로 전달되는 모든 것은 TCP 스트림이어야 한다. UDP를 쓰는 OpenVPN 프로필은 슈퍼바이저를 어떻게 작성하든 이 경로로는 동작하지 않는다. 프로필을 TCP로 바꾸고, 시작 로직을 건드리기 전에 원격 피어가 이를 받아들이는지 확인하라.

다음으로 클라이언트가 SOCKS 프록시에 닿을 수 있는지 확인하라. OpenVPN 2.6은 TCP 프로필용 socks-proxy 옵션을 문서화하며, 클라이언트마다 프록시 지원이 다르다. 프록시 옵션을 조용히 무시하는 실행기는 직접 연결하고도 동작하는 것처럼 보이며, 이는 실패보다 나쁘다.

이후의 모든 점검이 그것에 달려 있으므로 고른 전송을 런북에 적어라.

2단계: 프로세스 목록이 아니라 bootstrap 단계를 읽어라

Tor 제어 프로토콜은 GETINFO status/bootstrap-phase에 최신 bootstrap 상태를 진행률과 요약 태그와 함께 응답한다. 그 응답이 유용한 이유는 제어기가 데몬이 bootstrap을 이미 마친 뒤에 접속할 수 있기 때문이다. 이벤트만 듣는 슈퍼바이저는 슈퍼바이저가 시작되기 전에 Tor가 준비되어 있던 경우를 놓친다.

제어 연결을 제대로 인증하라. 제어 포트는 관리 인터페이스이며, 그와 대화할 수 있는 누구든 데몬을 재구성할 수 있다. localhost에 두고, 쿠키 또는 비밀번호 인증을 켜 둔 채로 유지하며, 시작 스크립트를 단순하게 만들려고 둘 중 하나를 제거하지 마라.

시작할 때 단계를 한 번 읽고, 그다음 실시간 보기를 위해 진행 이벤트를 구독하라.

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

진행률 100과 done 태그가 있는 응답은 데몬이 자체 시작을 마쳤다는 뜻이다. 아직 목적지로 향하는 쓸 만한 회로가 있다는 뜻은 아니다.

3단계: 클라이언트 회로 이벤트를 기다려라

Tor 이벤트 프로토콜은 CIRCUIT_ESTABLISHED를 정의하며, 이는 클라이언트가 사용할 수 있는 회로를 가졌다고 알린다. 이것이 캐리어 게이트가 원하는 준비 신호인데, 백분율보다 필요한 능력에 더 가깝기 때문이다. 그 이벤트를 구독하고 전환을 기록하여, 로그가 프로세스가 나타난 때가 아니라 캐리어가 쓸 수 있게 된 때를 보여 주게 하라.

이벤트를 시도의 허가로 다루되, 특정 목적지에 대한 보장으로 보지는 마라. 출구 정책은 여전히 원격 피어를 거부할 수 있고, VPN 자체의 핸드셰이크도 Tor와 무관한 이유로 여전히 실패할 수 있다.

코드에서 두 조건을 분리해 두라. ready라는 단일 불리언은 둘을 합쳐 다음 사건을 읽을 수 없게 만든다.

4단계: VPN을 자체 핸드셰이크에 게이트하라

VPN에는 자체 준비 조건이 있으며, 터널이 올라왔음을 증명하는 것은 그것뿐이다. 클라이언트가 할당된 주소와 함께 연결 상태를 보고할 때까지 기다린 뒤, 프록시 요구가 그대로 유지되었는지 확인하라. 실패 한 번에 socks-proxy 옵션을 버리는 재시도 루프는 직접 연결하여 설계 전체를 조용히 무력화한다.

피어에 닿을 수 없을 때 무슨 일이 일어날지를 알 필요가 생기기 전에 정하라. 눈에 보이는 실패가 있는 제한된 재시도는 무한 루프보다 운영하기 쉽고, 모니터링 시스템에 경보할 거리를 준다. 같은 결정이 캐리어에도 적용되므로, Tor가 다시 시작되면 VPN은 죽은 회로 위에 남겨 두지 말고 내렸다가 다시 게이트해야 한다.

마지막으로 VPN이 내려가 있는 동안 애플리케이션 자체의 정책을 유지하라. 올바르게 기다리는 슈퍼바이저는 무관한 프로세스가 트래픽을 직접 보내는 것을 막지 않는다.

견뎌야 하는 네 가지 전환을 점검하라

네 가지 경우가 설계를 덮는다. Tor가 먼저 올라오는 콜드 스타트, 이미 준비된 Tor에 붙는 슈퍼바이저, 사용할 수 없는 VPN 피어, 터널이 올라가 있는 동안 캐리어를 잃는 경우이며, 각각 기대되는 전환이 다르고 게이트를 제대로 작성했다면 각각 다른 로그 줄을 만든다.

그것들을 의도적으로 하나씩 실행하고, 프로세스 목록이 아니라 상태 변화를 읽어라.

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

캐리어가 끊기면 VPN은 낡은 터널에 매달려 있지 말고 한 번의 재시도 간격 안에 함께 내려가야 한다. Tor가 돌아오면 게이트는 프로세스 시작 후가 아니라 회로 이벤트 후에만 다시 열려야 한다. 각 실패에서 어떤 조건이 빠졌는지 기록하면, 다음 당직자는 타임스탬프에서 순서를 재구성할 필요가 없다.