2026/02/28

うちのZero TrustはWSL2のGitHubへのsshを通してくれない

前回、CloudflareのZero Trustについてちょっとだけ書いた。
今のうちの環境では、Zero Trustを有効にしたCloudflare WARPをオンにするとGitHubと接続できなくなる。ブラウザで見たりはできるのだが、とりあえず git pull は通らない。通らないと言うか鍵のパスフレーズ入力にもたどり着かない。
ちなみに、Cloudflare WARP アプリの名前は Cloudflare One Client という名前にリブランディングされるようだ。

 

そんなもんかと思っていたがこれは WSL2 環境で行った場合で、Windowsの方で git pull すると成功した。WSL2 のすべての通信がダメなわけではなく apt get などは問題なさそうだ。よくある ssh -T git@github.com が進まない。ローカル環境の Raspberry Pi に SSH するのは問題ない。ping github.com なども通るので DNS は問題ないのだと思う。

ssh -Tv git@github.com で詳細を見てみる。

...略...
debug1: Local version string SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.14
debug1: Remote protocol version 2.0, remote software version b15cbbe
debug1: compat_banner: no match: b15cbbe
debug1: Authenticating to github.com:22 as 'git'
debug1: load_hostkeys: fopen /home/xxx/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

ここで止まっている。 
鍵交換の応答を期待しているが返ってきていない?
-o KexAlgorithms=ecdh-sha2-nistp521 をつけるとうまくいったという人がいたのでまねしたが変わらず。
ログに出てくる sntrup761x25519-sha512 というのが暗号量子対策として変更された方式なのかな。

Post-quantum security for SSH access on GitHub - The GitHub Blog

$ ssh -v git@github.com exit 2>&1 | grep 'kex: algorithm:'
debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
^C 

そういうのはともかく、Zero Trust なのか Cloudflare WARP なのかわからないが、それを有効にすると NGになるし影響があるのは WSL2 での ssh だけというのが気になる。 

 

何もしてないのに。。。

あとは Windows で設定しているファイアウォールが影響しているとか?と思ってゆるい設定にすると通ってしまった!
そして設定を戻したのに通ってしまった!

な、何もしてないのに。。。

 

しかしその後もあまり調子よくない

その後はあまり気にせず使っていたのだが、PCの再起動をしてからまた調子が良くない気がする。SSH などは問題ないのだが winget のサイトと接続できない。Chrome もなんか時間かかったし DNS関係でなんかあるのかねぇ。


2026/02/24追記

よくわからないのだが、メーラーのThunderbirdに設定している Yahooメールのアカウントだけアクセスに失敗する。Gmailや他のアカウントもあるのだが失敗するのはYahooだけだ。「ログイン情報を送信しています...」のあとに失敗したダイアログが出てくる。ファイアウォールでこけているわけでもなさそうだし、パスワードの渡し方の設定を変更すると「対応してない」と出ているので通信自体はしているようだ。海外からのアクセスを許可しないようにしていたので無効にしたのだが関係ない。まあ、もう1台で動かしている Thunderbird の方は問題なく動いているから PC 側の設定だ。

ああ、いまわかった。

Windowsの IPv4 DNSサーバを 1.1.1.1 にしていたのだが、これを宅内のルータに設定すると動くようになった。
Cloudflare WARPをオンにするとダメになるから、DNS周りのなにかなんだろうなぁ。 

 

2026/02/28追記

Windows Firewall Control では WSL上でファイアウォールによるブロックが起きたときに通知が来ない。来たことはあるのかもしれないが記憶にないくらいには通知が出ない。ブロックしたログにも出てこないようだ。

SSHを使うのはほぼ WSL2からだったのだが、最近ブロックされていたのは 22番ポートを開けていなかったからのように思う。だったら「何もしてないのに直った」はおかしいのだが、Windowsファイアウォールの設定をリセットしてやり直している今はそんな状況だ。

Windows Firewall Control の推奨プロファイルは「レベル - 中」なのだが、これは送信を遮断側に倒す。「レベル - 低」がおそらく Windows の標準レベルでこちらは許可側にするようだ。なのでレベル中にしておくと送信失敗になってしまう。 

これで通知が出てくれれば気付くのだが、WSL2 は出てこないし他のアプリでもときどき出てこない。Windows Firewall Control のログにも出てこない。Windows ファイアウォールのログであれば出てきそうなのだが設定の変更ができない。設定を変更しなくても OK できない。注意事項に書いてある件が影響しているのだろうけど、Home版だと標準でグループポリシーオブジェクトを変更するツールは付属していないのでどれかのセキュリティツールが変更しているのだろうか。

 


ログは諦めて WSL2 側、正確には HyperV 側のファイアウォール設定に SSH などの送信許可を与えるようにした。

WSL2のファイアウォール設定 | hiro99ma blog

 

0 件のコメント:

コメントを投稿

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。

注: コメントを投稿できるのは、このブログのメンバーだけです。