Question 1

Yandex Telemostが参加者名によってOpenFluxを検出・ブロックするのを防ぐ方法

Accepted Answer

OpenFlux は以前、Yandex Telemost のミーティングに「OpenFlux」という固定の参加者名で参加していたため、ユーザー名によってトンネルが容易に検出・ブロックされる状態になっていました。この問題は core v0.5.1 および app v2.4.1 で修正されました。Telemost レーンは現在、ランダム化されたブラウザ風の RTCP CNAME を用いて「Гость」(ゲスト) として参加するため、参加者リストからトンネルが判明しなくなりました。修正を適用するには、core v0.5.1 以降および app v2.4.1 以降にアップデートしてください。旧バージョンでの一時的な回避策としては、ノードのトランスポートリストから Telemost を削除してください。

Question 2

mailru トランスポートで '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はpermessage-deflateの提示がない場合409を返す
    HandshakeTimeout:  15 * time.Second,
    NetDialContext:    netbind.Wrap(&net.Dialer{...}).DialContext,
}
```

gorilla/websocketは、`EnableCompression`がtrueの場合にのみ`Sec-WebSocket-Extensions`ヘッダーを送信します。この1行の変更を加えてリビルドすると、ハンドシェイクは`101 Switching Protocols`を返し、キャリアが接続し（`[M-DOCS] WebSocket connected`）、トラフィックが流れます。圧縮はWebSocketレベルでネゴシエートされ、ライブラリによって透過的に処理されるため、トンネルプロトコルは影響を受けません。User-Agent、Origin、クッキーは無関係です — 重要なのは圧縮ヘッダーのみです。

Question 3

OpenFluxでMail.ru Docsトランスポートが「API returned status 500」およびWebSocket close 1005エラーで失敗する問題を修正する方法

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のままスタックします。修正方法：出口ノードを最新リリースに更新してください。開発者がMail.ru API互換性に対応する修正を行い、更新後に正常に動作することがユーザーによって確認されています。自動更新が有効になっていればノードは自動的にアップグレードされます。そうでない場合は、最新のノードバージョンを手動でpullして再起動してください。設定やドキュメントの変更は不要です。この問題はサーバー側のAPI変更が原因であり、ドキュメントやIPブロックが原因ではないため、ドキュメント/チャネルを再作成しても解決しません。

Question 4

docs.yandex.kzのような.ru以外のドメインで発生するYandex transport captchaエラー(HTTP 400または'config not found: no client-config script')を修正する方法は?

Accepted Answer

これは captcha 処理コードのバグ（commit 38782b2 で導入）で、現在はメンテナーによって解決されています。main@d13aa5b より新しいビルドに更新してください。根本原因は2つあります。(1) transport/yandex/captcha.go が Origin ヘッダーとフォームアクションに https://docs.yandex.ru をハードコードしていたため、第1段階の showcaptchafast PoW 解決がリージョナルドメイン（例：docs.yandex.kz）で HTTP 400 を返していました。修正ではホストを動的に導出しています。url.Parse(captchaURL).Host をパースし、それを Origin ヘッダーと formAction プレフィックスの両方に使用します（1ファイルのみの約10行のパッチ）。これにより POST は 302（解決済み）を返します。(2) 第2段階のチャレンジ showcaptcha?cc=1&...（window.__SSR_DATA__ および tmgrdfrend-form マーカーを含まない約14KBのページ）が処理されていなかったため、fetchDocInfo が config not found: no client-config script というエラーで失敗していました。注意：これは IP レピュテーションやレート制限とは関係ありません。新規 IP からの最初のリクエストで再現します。最新リリースに更新すれば両方の問題が修正されます。影響を受けるビルドには設定フラグによる回避策はありません。

Question 5

Yandexトランスポートを使用すると、OpenFlux VPNセッションのハンドシェイクがタイムアウトするのはなぜですか？

Accepted Answer

根本原因：ネイティブの Yandex トランスポート（`transport/yandex/yandex.go`）およびバンドルされている Yandex JS トランスポートは、実際のバイナリサイズに関係なく、すべてのパケットでカーソルペイロードの長さプレフィックスを `18` にハードコードしています。Yandex のサーバーは、宣言された長さが実際のペイロードと一致しないカーソルメッセージをリレーしないため、WebSocket が接続を維持していても、ハンドシェイクパケットはピアに届かず、セッションは `handshake FAILED after 20s: handshake timed out` で失敗します。

修正：`transport/yandex/yandex.go`（および JS トランスポート）にパッチを適用し、カーソルプレフィックスが定数 18 ではなく、Base64 エンコード前の実際のバイナリパケット長と一致するようにします（例：16 バイトのパケットでは `16;<base64>`）。管理されたテストにより、プレフィックスが一致しない場合の配信は 0/3 で、正しいプレフィックスでは 64/512/1500 バイトのパケットを含め、双方向で 3/3 の配信が確認されました。

回避策：Direct トランスポートのフォールバックを有効にしておき（例：`--transports=yandex:100,direct:50`）、Yandex リレーがパケットをドロップした場合でもセッションを Direct 経由で完了できるようにします。なお、動作する Direct パスが Yandex の障害を隠す可能性があるため、修正をテストする際は Direct を無効にして検証してください。

OpenFlux

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト