ZTMS掲示板

JCBookmark のリンク切れ調査を使ったところ、必ず接続失敗になるサイトがあるようです。
ウェブブラウザでは接続できているので生きているサイトなのは確認できています。
具体的には
http://www.amsn-project.net/
https://www.parrotsec.org/
https://www.bitrig.org/
が「接続できません」という結果になります。
また、
https://www.openmandriva.org/
は何度やっても接続タイムアウトになります。

齊藤さん

書き込みありがとうございます。
挙げていただいたサイト４つを私のPCで登録してみましたが、特に問題なさそうで、リンク切れ調査も「200 OK」になりました。

JCBookmarkのリンク切れ調査は（ブラウザではなく）JCBookmarkのアプリがサイトに接続しますので、ブラウザで見える結果と違ってしまうことがあります。
わかりやすい特徴は、「5秒ほど待って応答がないサイトはタイムアウト扱いになる」事があります。
ブラウザよりも諦めるのが早いところがあります。

またPCの設定や負荷状態、インターネット接続状況、相手側サーバーの状況、など外部環境によっても結果が左右されます。

JCBookmarkとしましては、JCBookmarkアプリ（専用サーバー）ウィンドウに出るログがいちばん詳しい記録となります。
https://ztmsdf.appspot.com/jcbookmark/usage.html#c80

例えば http://www.amsn-project.net/ のリンク切れ調査を行った時は、次のような内容が出ます。
────
12:46:34.111 [0]URL0:http://www.amsn-project.net/
12:46:34.358 [852]外部接続:www.amsn-project.net=93.186.176.224:80
12:46:34.358 [852]外部送信:GET / HTTP/1.1 Host: www.amsn-project.net User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Safari/537.36 Accept-Encoding: gzip,deflate Accept-Language: ja,en Accept: */*
12:46:34.637 [852]外部受信10264bytes:HTTP/1.1 200 OK Server: nginx/1.10.3 Date: Thu, 07 Apr 2022 03:46:35 GMT Content-Type: text/html;charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Set-Cookie: lang=ja; expires=Wed, 07-Apr-2021 03:46:35 GMT; Max-Age=0 Set-Cookie: lang=ja; expires=Fri, 07-Apr-2023 03:46:35 GMT; Max-Age=31536000 Content-Encoding: gzip
12:46:34.637 L3525:伸長バッファ確保198522bytes
12:46:34.638 L3533:伸長[1]9909->25900byte(2.6倍)
12:46:34.640 [0]URL0:O,200 OK,
────
齊藤さんのPCではここにエラー情報が記録されていると思います。

もしわかれば抜き出して、こちらに記載していただければ何かわかるかもしれません。
ただ、一回ぶんのログだけではわからない事も多いです。。

IPV4 を使うか IPV6 を使うかという点で差が出ていることがわかりました。
Windows の設定で IPV6 を優先するようになっていたところを IPV4 を優先するように変更して試すと 「200 OK」 という結果でした。 (Windows のデフォルトでは IPV6 優先です。)

私が接続失敗したとして挙げたサイトはドメインから IPV6 の IP アドレスを得るところまでは成功していますが、その先の接続はサーバ側から拒否されています。
DNSルックアップで IPV6 の IP アドレスが得られなかった場合には IPV4 で接続するのは当然の動作として、 IPV6 の IP アドレスが得られた上で接続に失敗した場合に一般的なブラウザでの (デフォルトでの) 動作は IPV4 での接続に切り替えているように見えます。
規格でそこまで要求しているかはよくわからないのですが、実際の利用としてはブラウザから見るわけなのでブラウザで見れるものが接続失敗となるのは使い勝手が悪いですし、可能なようなら修正を期待します。

齊藤さん

詳細な内容と、改善案までありがとうございます！
なるほどIPv6が優先になっていて・・ということは私のPCはIPv4優先になっているのか・・。

たしかにJCBookmarkアプリは「IPv6で失敗したらIPv4を試す」ようにはなっていません。
再現確認などもあわせて、切り替え対応で問題なさそうなら実装対応したいと思います。

ありがとうございました！

齊藤さん

こちらのページの手順で、私のPCはIPv4優先かどうか？確認したのですが、IPv6優先でした。
https://4thsight.xyz/693

また、挙げていただいたURL4つのホスト名前解決で、IPv6アドレスが得られるか？確認しましたが
IPv6アドレスは得られず、どのホストもIPv4アドレス１つだけでした。
93.186.176.224 www.amsn-project.net
192.46.230.37 www.parrotsec.org
104.207.142.221 www.bitrig.org
164.132.66.131 www.openmandriva.org

私の環境ではIPv6アドレスは出てこないため問題の現象確認もできていません。
プロバイダやインターネット接続方式の違いで挙動が変わってしまうのかもしれません。。

ひとまずJCBookmark側では、複数のIPアドレスが得られた場合に、成功するまで順番にアクセスするよう対応予定です。

ただ、それで問題が解消するのかどうか？もよくわかりませんので、
調査用にログを増やしたベータ版相当のJCBookmark.exeを用意しました。
https://ztmsdf.appspot.com/jcbookmark/JCBookmark-v20220410.exe.zip

可能でしたら、このJCBookmark.exeをダウンロードして差し替えていただき、問題が改善するかどうか？ご確認いただけないでしょうか。

ログには外部サイトのホスト名前解決で得られたIPアドレス一覧が記録されます。
例えば www.youtube.com ではIPv4アドレスが16個ほど得られるようで以下のようなログが出ます。
─────────────────────────────────
ホスト www.youtube.com 名前解決
　└ 216.58.220.110
　└ 142.250.196.110
　└ 142.250.196.142
　　：
─────────────────────────────────

齊藤さんのPCでIPv6アドレスが出てくる時はどんなログになりますでしょうか・・？

よろしくお願いいたします。

ありがとうございます。
v20220410 をさっそく使ってみたところ、最初の報告で接続失敗になっていた URL についてはいずれも OK になりました。
youtube についてのログは以下のようになっています。

─────────────────────────────────
13:45:30.908 [0:1120]接続:127.0.0.1
13:45:30.908 [0]受信:POST /:poke HTTP/1.1 Host: localhost:60080 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0 Accept: */* Accept-Language: ja,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate, br Content-Type: application/x-www-form-urlencoded; charset=UTF-8 If-Modified-Since: Thu, 01 Jun 1970 00:00:00 GMT X-Requested-With: XMLHttpRequest Content-Length: 27 Origin: http://localhost:60080 DNT: 1 Connection: keep-alive Referer: http://localhost:60
13:45:30.909 [0]URL0:https://www.youtube.com/
13:45:31.921 ホスト www.youtube.com 名前解決
13:45:31.921 　└ 2404:6800:400a:80e::200e
13:45:31.921 　└ 2404:6800:400a:813::200e
13:45:31.921 　└ 2404:6800:400a:80a::200e
13:45:31.921 　└ 2404:6800:400a:80b::200e
13:45:31.921 　└ 142.250.206.238
13:45:31.921 　└ 142.250.207.110
13:45:31.921 　└ 172.217.25.174
13:45:31.921 　└ 172.217.161.206
13:45:31.921 　└ 142.250.76.142
13:45:31.921 　└ 142.250.206.206
13:45:31.921 　└ 172.217.161.238
13:45:32.321 [1208]外部接続(SSL):www.youtube.com=2404:6800:400a:80e::200e:443
13:45:32.321 [1208]外部送信:GET / HTTP/1.1 Host: www.youtube.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0 Accept-Encoding: gzip,deflate Accept-Language: ja,en Accept: */*
13:45:32.435 [1208]バッファ拡大65536bytes
13:45:32.533 [1208]バッファ拡大131072bytes
13:45:32.537 [1208]外部受信73776bytes:HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 X-Content-Type-Options: nosniff Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: Mon, 01 Jan 1990 00:00:00 GMT Date: Mon, 11 Apr 2022 04:45:33 GMT X-Frame-Options: SAMEORIGIN Strict-Transport-Security: max-age=31536000 Report-To: {"group":"youtube_main","max_age":2592000,"endpoints":[{"url":"https://csp.withgoogle.com/csp/report-to/youtube_main"}]} Cross-Origin-O
13:45:32.538 L3541:伸長バッファ確保1376186bytes
13:45:32.543 L3549:伸長[1]68739->613769byte(8.9倍)
13:45:32.587 [0]URL0:O,200 OK,
13:45:32.587 [0]送信:HTTP/1.0 200 OK Content-Type: application/json; charset=utf-8 Content-Length: 49 Pragma: no-cache Cache-Control: no-cache Connection: close
13:45:32.588 [0]切断
─────────────────────────────────

私が使っているプロバイダは Biglobe です。
プロバイダに特有の事情がないか確認したところ、 Biglobe では本来 IPV4 のみしか割り当てていないドメインに対して特殊な IPV6 アドレスを返すことがある NAT64/DNS64 という技術の説明が見つかりました。
https://support.biglobe.ne.jp/ipv6/nat64.html
YouTube が IPV6 対応になったという記事は 2010 年にあります。
https://blog.youtube/news-and-events/youtube-calls-on-ipv6/
つまり YouTube は NAT64/DNS64 の対象外のはずではあるのですが、勝手に追加することがあるのであればプロバイダによっては勝手に削除 (または最初から伝播されてない) というような状況もあるのだろうと想像は出来ます。
ネットワーク技術に明るいわけではないので正確な背景はよくわかりませんが……。

ところで JCBookmark は Windows 用のソフトなのですから Windows API (Wininet) を使って接続すれば細々とした制御をせずに楽できそうな気がするんですが、 WebBookmark のバックエンドと共通化するなどの事情があるのでしょうか？

齊藤さん

さっそくありがとうございました！
ひとまず問題解消してよかったです。この修正を入れて次バージョンにしたいと思います。

NAT64/DNS64の情報ありがとうございました。
なるほどこのようなプロバイダの仕組みがあるのですね・・。

私の環境ではYouTubeのIPはすべてIPv4アドレスでした。
齊藤さんの環境ではIPv6アドレスでYouTubeに接続できているのですね。

そうすると最初に問題になっていたホストはなぜIPv6アドレスで接続失敗してしまうか・・？
本来IPv4しか持っていないホストでもNAT64/DNS64機能で自動変換されそうですが・・。
ひょっとしたらJCBookmark側の実装もなにか関係があるのか・・。

JCBookmarkはWinsock2を使った原始的なソケット通信プログラム実装になっています。
おっしゃる通りたしかにWinInet/WinHTTPなどを使っていれば今回の問題は発生しなかったのかなと思います。

理由はただ私がLinuxでソケット通信プログラムを学習していたので、WindowsでもWinsock2を使えばほぼ同じかな思っていた点と、
あとは細かい制御、例えば外部サーバーからの応答データを条件に応じて必要な部分まで受信したらあとは捨ててすぐ切断したい、など
細かい最適化は、ソケットプログラムの方が融通が効くんじゃないかなと思った点などがあります。
ただそこまでWinInet/WinHTTPの細かい仕様を調べてないし今回のような不具合も生まれてしまうので判断が正しかったかどうか怪しくもあります。
※WebBookmarkはサーバー側はPHPで特にソース共通化はしていません。

詳しく調べていただきありがとうございました！

ウェブサイトが ipv6 対応になっているかどうかチェックするサービスを見つけました。
https://ready.chair6.net/
これを用いてチェックしたところ IPV6 アドレスの取得には成功するものの IPV6 での接続 (IPv6 Connectivity) には失敗と出ますね。
サーバ側の設定ミスなのか意図的な拒否なのかはわかりませんが、いずれにしてもそこのところはサーバ側の問題のようです。

齊藤さん

ありがとうございます！
なるほどそんなサービスがあるとは・・。
JCBookmark側の問題ではなさそうでよかったです。

これまで私自身がIPv6環境を持っておらず、どこでIPv6が使われてるのか謎めいたままでしたが、
おかげさまで今回IPv6に実際に触れたような実感もできて、よい経験になりました。

ありがとうございました！