Question 1

Yandex Telemost가 참가자 이름으로 OpenFlux를 감지하고 차단하는 것을 방지하는 방법은 무엇입니까?

Accepted Answer

OpenFlux는 이전에 고정된 참가자 이름 "OpenFlux"로 Yandex Telemost 회의에 참가했기 때문에 사용자 이름만으로 터널을 쉽게 탐지하고 차단할 수 있었습니다. 이 문제는 core v0.5.1 및 app v2.4.1에서 수정되었습니다. 이제 Telemost 레인은 무작위로 생성된 브라우저와 유사한 RTCP CNAME과 함께 "Гость"(Guest)로 참가하므로 참가자 목록에서 더 이상 터널이 드러나지 않습니다. 수정 사항을 적용하려면 core v0.5.1+ 및 app v2.4.1+로 업데이트하세요. 이전 버전에서는 임시 해결 방법으로 노드의 transport 목록에서 Telemost를 제거하세요.

Question 2

mailru transport에서 'WebSocket dial failed (http 409): websocket: bad handshake' 오류를 수정하는 방법

Accepted Answer

Mail.ru의 nginx는 `Sec-WebSocket-Extensions: permessage-deflate` 헤더를 제공하지 않는 WebSocket 업그레이드 요청을 거부하며 `HTTP 409 Conflict`를 반환합니다. 이 문제는 `transport/mailru/mailru.go`의 gorilla/websocket 다이얼러가 압축 없이 빌드된 OpenFlux core v0.4.2 (node-v1.2.2)에 영향을 미칩니다. 해결 방법: `connectToDoc`에서 `websocket.Dialer`에 `EnableCompression: true`를 설정하세요:

```go
dialer := websocket.Dialer{
    EnableCompression: true, // nginx answers 409 without permessage-deflate offer
    HandshakeTimeout:  15 * time.Second,
    NetDialContext:    netbind.Wrap(&net.Dialer{...}).DialContext,
}
```

gorilla/websocket은 `EnableCompression`이 true일 때만 `Sec-WebSocket-Extensions` 헤더를 전송합니다. 이 한 줄 변경 후 리빌드하면 핸드셰이크가 `101 Switching Protocols`를 반환하고, 캐리어가 연결되며(`[M-DOCS] WebSocket connected`), 트래픽이 흐릅니다. 압축은 WebSocket 수준에서 협상되고 라이브러리에 의해 투명하게 처리되므로 터널 프로토콜에는 영향이 없습니다. User-Agent, Origin, 쿠키는 무관하며 압축 헤더만이 중요합니다.

Question 3

OpenFlux에서 'API returned status 500' 및 WebSocket close 1005 오류로 인해 Mail.ru Docs 트랜스포트가 실패하는 문제를 해결하는 방법

Accepted Answer

Mail.ru가 10월 12일 16:00 UTC경 API(r7/edit 엔드포인트 / WebSocket 동작)를 변경하면서 node-v1.3.1과의 호환성이 깨졌습니다. 증상: `[M-DOCS] cannot open the document: API returned status 500` 및 `websocket: close 1005` 재연결 루프가 약 60초마다 발생하며, 클라이언트가 direct transport에 고정됩니다. 해결 방법: exit node를 최신 릴리스로 업데이트하세요. 개발자가 Mail.ru API 호환성을 패치했으며, 사용자들이 업데이트 후 정상 작동을 확인했습니다. auto-update가 활성화되어 있으면 노드가 자동으로 업그레이드되며, 그렇지 않으면 최신 노드 버전을 수동으로 pull하고 재시작하세요. 설정이나 문서 변경은 필요하지 않습니다. 문서/채널을 다시 생성해도 도움이 되지 않습니다. 이 문제는 문서나 IP 차단이 아니라 서버 측 API 변경이 원인이기 때문입니다.

Question 4

docs.yandex.kz와 같은 .ru가 아닌 도메인에서 Yandex transport 캡차 오류(HTTP 400 또는 'config not found: no client-config script')를 해결하는 방법은?

Accepted Answer

이는 captcha 처리 코드의 버그였으며(commit 38782b2에서 도입됨), 현재는 메인테이너에 의해 해결되었습니다 — main@d13aa5b보다 최신 빌드로 업데이트하세요. 두 가지 근본 원인이 있습니다: (1) `transport/yandex/captcha.go`가 `Origin` 헤더와 form action에 `https://docs.yandex.ru`를 하드코딩하여, 첫 번째 단계 `showcaptchafast` PoW 해결이 리전 도메인(예: `docs.yandex.kz`)에서 HTTP 400을 반환했습니다. 수정 사항은 호스트를 동적으로 도출합니다: `url.Parse(captchaURL).Host`를 파싱하여 `Origin` 헤더와 `formAction` 접두사 모두에 사용하며(한 파일에서 약 10줄짜리 패치), 이후 POST가 302를 반환합니다(해결됨). (2) 두 번째 단계 챌린지 `showcaptcha?cc=1&...`(`window.__SSR_DATA__`/`tmgrdfrend-form` 마커가 없는 약 14KB 페이지)가 처리되지 않아 `fetchDocInfo`가 `config not found: no client-config script` 오류로 실패했습니다. 참고: 이는 IP 평판/레이트 리밋과 관련된 문제가 아니며, 새로운 IP에서의 첫 번째 요청에서도 재현됩니다. 최신 릴리스로 업데이트하면 두 문제가 모두 해결되며, 영향을 받는 빌드에서는 config-flag를 이용한 우회 방법이 없습니다.

Question 5

Yandex 트랜스포트를 사용할 때 OpenFlux VPN 세션 핸드셰이크가 시간 초과되는 이유는 무엇인가요?

Accepted Answer

근본 원인: 네이티브 Yandex transport(`transport/yandex/yandex.go`)와 번들에 포함된 Yandex JS transport는 실제 바이너리 크기와 관계없이 모든 패킷의 커서 페이로드 길이 접두사를 `18`로 하드코딩합니다. Yandex 서버는 선언된 길이가 실제 페이로드와 일치하지 않는 커서 메시지를 릴레이하지 않기 때문에, 핸드셰이크 패킷이 피어에 전혀 도달하지 못하고 WebSocket이 연결된 상태를 유지하더라도 세션이 `handshake FAILED after 20s: handshake timed out` 오류로 실패합니다.

수정: `transport/yandex/yandex.go`(및 JS transport)를 패치하여 커서 접두사가 상수 18 대신 Base64 인코딩 전의 실제 바이너리 패킷 길이와 같도록 합니다(예: 16바이트 패킷의 경우 `16;<base64>`). 통제된 테스트에서 불일치하는 접두사는 0/3 전달을 기록한 반면, 올바른 접두사는 64/512/1500바이트 패킷을 포함하여 양방향 모두 3/3 전달을 기록함이 확인되었습니다.

우회 방법: Direct transport 폴백을 활성화된 상태로 유지하여(예: `--transports=yandex:100,direct:50`) Yandex 릴레이가 패킷을 드롭할 때 세션이 Direct를 통해 완료될 수 있도록 합니다. 정상적으로 작동하는 Direct 경로가 Yandex 실패를 가릴 수 있다는 점에 유의하세요. 따라서 수정 사항을 테스트할 때는 Direct를 비활성화한 상태로 확인하세요.

OpenFlux

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트