mieki256's diary

昨日の段階では、Windows10 x64 22H2 + FFFTP 2.00, FFFTP 5.8, WinSCP 6.1.1 で接続できるようになったのだけど、やっておくべきことを少しまとめておく。

IPv6 は使わないで、IPv4 でアクセスしたほうがいいらしい。FTPクライアントによっては、IPv6 でアクセスしようとして接続に失敗する。

FTPクライアントに設定するホスト名は、「www?.plala.or.jp」ではなくて、IPv4アドレス「xxx.xxx.xxx.xxx」にしておく。「www?.plala.or.jp」にしてしまうと、FTPクライアントによってはIPv6アドレスを取得してしまって接続できなくなる。ただ、ぷらら側で、FTPサーバのIPv4アドレスを変えてしまう可能性もありそうなので、急に接続できなくなった時はそのあたりを疑ってみるのもアリかもしれない。

尚、Windows10なら、ping を使って「www?.plala.or.jp」のIPv4アドレスを知ることができる。「-4」オプションを指定すればIPv4の使用を強制できる。 *2

ping www?.plala.or.jp -4

以下は ping の使用例。「www7.plala.or.jp」が「60.43.63.107」だと分かる。

> ping www7.plala.or.jp -4

www7.plala.or.jp [60.43.63.107]に ping を送信しています 32 バイトのデータ:
60.43.63.107 からの応答: バイト数 =32 時間 =31ms TTL=247
60.43.63.107 からの応答: バイト数 =32 時間 =16ms TTL=247
60.43.63.107 からの応答: バイト数 =32 時間 =19ms TTL=247
60.43.63.107 からの応答: バイト数 =32 時間 =17ms TTL=247

60.43.63.107 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 16ms、最大 = 31ms、平均 = 20ms

FFFTP は、FFFTP 2.00 を使ったほうがいいのかもしれない。FFFTP 2.00 なら、ホスト設定に、「ネットワークの種類」を「TCP/IPv4」に制限する設定項目があるので…。ちなみに FFFTP 2.00 は以下から入手できる。

_FFFTPの詳細情報 : Vector ソフトを探す！

現在の最新版の FFFTP 5.8 には「ネットワークの種類」という設定項目自体が無い。その代わり(?)、色々なバグが修正されているらしいのだけど…。

_Releases - ffftp/ffftp - GitHub


Windows10のファイアウォールは、FTPS接続した際に接続を切断してしまう可能性がある。

_Windows : FTPSで大量のファイルを転送すると接続が切れる | INCOMPLETE++
_FFFTPで大量ファイルを転送すると途中で切断、おかしくなる場合の対応 - ブログ運営のためのブログカスタマイズ

FFFTP の、「ツール」→「WindowsファイアウォールのステートフルFTPフィルタの設定」を使って、ステートフルFTPフィルタを無効にしておいたほうがいいかもしれない。あるいはコマンドを打ち込んで無効にする方法もあるそうで、その方法については上記の記事で紹介されてる。

まあ、なんというか、「オマジナイ」が増えたなと…。

とりあえず、FFFTP 2.00 で、ぷららのFTPサーバにFTPS接続する際のホスト設定をメモしておく。

今の段階ではこの設定で接続できているけれど、今後ぷらら側がサーバ設定を変えたら、また設定を変更することになるのかもしれないし、もしくは FFFTP すら使えなくなるのかもしれない。

• 「基本」→「ホスト名(アドレス)」は IPv4アドレスにしておく。
• 「基本」→「ホストの初期フォルダ」は空欄にしておく。

• 「拡張」→「PASVモードを使う」のチェックを入れておく。
• 「拡張」→「ネットワークの種類」を「TCP/IPv4」にしておく。(FFFTP 5.8 にこの設定項目は無い)

• 「暗号化」→「暗号化なしで接続を許可」のチェックを外す。
• 「暗号化」→「FTPS (Explicit)で接続」のチェックを入れる。
• 「暗号化」→「FTPS (Implicit)で接続」のチェックを外す。
• 「暗号化」→「弱い暗号化方式を使用しない」のチェックを入れる。(FFFTP 5.8 にこの設定項目は無い)

一応、念のため、ホームページビルダー20上でのFTPS接続転送設定もメモしておく。今現在はこの設定で、ぷららのFTPサーバに対して、サイト公開(FTPサーバへのアップロード)処理ができている。

基本設定タブ。

• プロバイダの選択 : その他
• FTPサーバ名 : IPv4アドレスを指定
• 転送先フォルダ : 空欄のままにしておく

詳細設定タブ。

• 接続方法 : FTPES - FTP over TLS/SSL Explicitモード
• ポート番号 : 21
• パッシブモードで接続する : チェックを入れて有効化

「OK」を押すと、その設定でFTPサーバに接続できるか試行して、問題が無ければ設定ダイアログが閉じるし、サーバと繋がらない場合は「サーバが見つかりません」的な警告ダイアログが表示される。

一応、バージョン表示もメモ。



ところで、ホームページビルダー20は、FTPS接続に対応しているけれど。

_[050780]FTPS 対応について

ホームページビルダー16以前のバージョンは、FTPS接続には対応していないらしい。

_FTPの転送設定　ホームページビルダー編｜ヘルプ｜忍者ホームページ

ただ、FTPRangerというソフトを使えば、FTPS接続に非対応なFTPクライアントでもFTPS接続できる、という話も見かけた。実際に試してないので今でも使えるのかどうかは分からないけれど、一応メモしておく。

_FTPRanger : ユーザーズガイド
_FTPRanger - FTPクライアント用暗号通信化ソフトウェア
_ホームページ・ビルダー 14 で FTPS サーバーへアップロードする。

もっとも、もしホームページビルダーがFTPS接続に非対応だとしても、サイト公開(FTPサーバへのアップロード)は、FFFTP で行ってしまってもいいような気もする。FFFTP のミラーリングアップロード機能を使えば、ローカルフォルダ内とFTPサーバ上のファイルのタイムスタンプを見て、追加/更新されたファイルをアップロード、かつ、ローカルには存在しないけれどFTPサーバ上にあるファイルは削除してくれるので、サイト公開を呼び出すのと似た感じで作業することができるのではないかと…。

例えば以下のようなオプションをつけて FFFTP を呼び出せば、FFFTPの起動と同時にミラーリングアップロードを開始して、処理が終わったらウインドウを閉じて終了、ということもできる。

ffftp.exe --set ホストの設定名 --mirror --quit

昨日試した時点では、FileZilla 3.65.0 で、www7.plala.or.jp にFTPS接続できなかった。

そのあたりをググっていたら、以下のやり取りに遭遇。

_FileZilla won't connect to ftp.keepfree.de - GnuTLS error - FileZilla Forums

That server has very bad security, it only supports TLS 1.0, which is insecure. FileZilla requires at least TLS 1.2 support, in its default configuration.
Additionally, that server has been neglected by staff, they didn't renew their TLS certificate that's expired since last year. :(
As a short-time workaround, set the minimum TLS version in the settings of FileZilla to "TLS 1.0 (insecure)". And you should definitely contact them about their server's security issues!

FileZilla won't connect to ftp.keepfree.de - GnuTLS error - FileZilla Forums より

• FileZilla のデフォルト設定では、少なくとも TLS 1.2 のサポートが必要。サーバ側が古いと接続に失敗する。
• ただし、FileZilla の設定を変更して、「許可されるTLSの最小バージョン」を「TLS1.0(安全ではない)」にすることで、一時的に問題を回避できる。
• しかし、本来は、サーバ管理者に連絡してどうにかしてもらうのが正しい解決の仕方。

だそうで。ぷららのFTPサーバもこういう状態なんだろうなと…。

しかし、おそらくこのあたり、FileZilla に特化してFTPサーバ側の設定を変えてしまうと、今度は他のFTPクライアントがFTPS接続できなくなりそうな臭いがする…。いやまあ、全ての問題を解決できる、真っ当なFTPサーバ設定があるのかもしれんけど…。

試しに、FileZilla の設定を変更したところ、ぷららのFTPサーバ(www7.plala.or.jp, 60.43.63.107) にFTPS接続することができた。

• 編集 → 設定 → 接続 → TLSオプション → 許可されるTLSの最小バージョン → 「TLS 1.0 (安全でない)」に変更して「OK」。

一応念のため、ホスト設定(サイトマネージャ)のスクリーンショットも載せておく。

一般タブ。

• プロトコル : FTP - ファイル転送プロトコル
• ホスト : IPv4アドレスを指定
• ポート : 21 (FTPはデフォルトで21番ポートを使うので空欄のままでもいい)
• 暗号化 : 明示的なFTP over TLSが必要

転送設定タブ。

• 転送モード : パッシブ
• 「同時接続数を制限する」にチェックを入れて、最大接続数を1にする

余談。編集 → 設定 → デバッグ → 「メッセージログのデバッグ情報」を「2 - 情報」にしておけば、FTPサーバから送られてきた情報も表示することができるので、もし接続に失敗する場合は、どこで失敗しているのか分かる、かもしれない。

Ubuntu Linux 20.04 LTS + FileZilla 3.58.0 で www7.plala.or.jp (60.43.63.107:21) に接続した際のログは以下。

状態:           60.43.63.107:21 に接続中...
状態:           接続を確立しました。ウェルカム メッセージを待っています...
レスポンス:     220 FTP Server Ready
コマンド:       AUTH TLS
レスポンス:     234 AUTH TLS successful
状態:           TLS を初期化しています...
トレース:       TLS Handshake successful
トレース:       Protocol: TLS1.0, Key exchange: RSA, Cipher: AES-256-CBC, MAC: SHA1, ALPN: 
状態:           TLS 接続が確立されました。
コマンド:       USER xxxxxxx
レスポンス:     331 Password required for xxxxxxx
コマンド:       PASS *********
レスポンス:     230 User xxxxxxx logged in
コマンド:       SYST
レスポンス:     215 UNIX Type: L8
コマンド:       FEAT
レスポンス:     211-Features:
レスポンス:      CCC
レスポンス:      PBSZ
レスポンス:      AUTH TLS
レスポンス:      MFF modify;UNIX.group;UNIX.mode;
レスポンス:      REST STREAM
レスポンス:      MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.mode*;UNIX.owner*;
レスポンス:      EPRT
レスポンス:      EPSV
レスポンス:      MDTM
レスポンス:      SSCN
レスポンス:      TVFS
レスポンス:      MFMT
レスポンス:      SIZE
レスポンス:      PROT
レスポンス:     211 End
状態:           サーバーは non-ASCII の文字をサポートしていません。
コマンド:       PBSZ 0
レスポンス:     200 PBSZ 0 successful
コマンド:       PROT P
レスポンス:     200 Protection set to Private
状態:           ログインしました
トレース:       Measured latency of 227 ms
状態:           ディレクトリ リストを取得中...
コマンド:       PWD
レスポンス:     257 "/" is the current directory
コマンド:       TYPE I
レスポンス:     200 Type set to I
コマンド:       PASV
レスポンス:     227 Entering Passive Mode (60,43,63,107,247,252).
トレース:       Binding data connection source IP to control connection source IP 192.168.1.11
トレース:       Trying to resume existing TLS session.
コマンド:       MLSD
トレース:       TLS Handshake successful
トレース:       TLS Session resumed
トレース:       Protocol: TLS1.0, Key exchange: RSA, Cipher: AES-256-CBC, MAC: SHA1, ALPN: 
レスポンス:     150 Opening BINARY mode data connection for MLSD
レスポンス:     226 Transfer complete
状態:           "/" のディレクトリ リストの表示成功

完全に余談。投票所の係の人達のほとんどがマスクをしてなくて、目にした瞬間ギョッとしてしまった。この中に、コロナに感染してる人が混ざっていたらどうなるのか。投票に来た人達を次々に感染させていくつもりなのか。ニッコリ笑って「おはようございます」なんて言ってる場合じゃねえだろ。コイツラ何考えてんだ。などと一瞬憤慨しそうになったのだけど、直後にいやいや待て待てと考え直した。この気温の高さで一日中マスクをつけっぱなしでは熱中症になりかねないだろう…。それに扉も窓も全開にしてたから換気はできてるほうだろうし、唾を飛ばしながら大声で喋りかける仕事でもない。この時期に優先すべきは、コロナより熱中症対策だろうよ…。と考えたら、マスクをつけないことが妥当な選択のような気もしてきた。と思ったけれど今になって考えたら、アクリル板を置いとけば済む話だよな…。もっとも、全ての投票所にアクリル板を設置するコストを考えたら…。結局、全ての問題は、お金の問題に帰着するのかもしれない。世の中しょせん銭や。みたいな。

そう考えると、本来議員さんを選ぶときも、そういう視点が必要なのかもしれない。世の中しょせん銭や。自治体が使える金額は決まってるわけだから、リソース配分が上手い人、優先順位の付け方が賢い人、そういった能力が議員さんに求められるのではないか。とは言え、そのあたりの能力を測定できるテストの類が存在するのかどうか…。結局、試しにやらせてみてダメだったら変えてみるという、なんだか行き当たりばったりのやり方しかできないあたり、どうなんだろうと思えてきた。このあたり、各立候補者の能力を数値化して比較できたら選挙の結果にも納得感が…。いや、そうなると、そもそも選挙をする必要も無くなってしまうか。テストを受けて合格したら議員になれる、みたいな感じになりそうだけど、それは民主主義と言えるのかどうか。政治というものは、効率を追求していくと民主主義からどんどん乖離してしまうのではないか。

もしかするとマスクをつけるつけないの話も民主主義の一端を示しているのかもしれない。民主主義が、比較的多くの人が納得できる決定がされているか否かを重視しているものとすれば、マスク装着も同様の話で…。でも、投票所に居た人達は、話し合ってマスクをつけないことを選択したのかどうか。実は上からのお達しで、あるいは、メリットとデメリットをリストアップすることなく単にその場の空気でつけるつけないを決めていた可能性はないか。

なんかもうめんどくさくなってきたから全部AIが決めてくれないかな。AIという巫女のお告げに従って行動できたら楽なんだろうなあ。