このブログを検索

2022/02/10

なぜIT業界のプロジェクトはうまくいかないのか

私はIT業界で30年以上仕事をしてきた。

30年前に「IT」という呼ばれ方はされていず、「情報処理」とか「OA(Office Automation)」などと言われ、もっと柔らかい言い方だと「コンピューター関係」とか「ソフト開発」とかいう風に言ったり言われたりしていた。

「IT」という呼称が一般化したのは2000年ごろだろうか。森総理大臣がそれを「イット」と読んだことがニュースになったのが2000年である。

わたしのキャリアの1/3くらいはまだITとは呼ばれなかった時期ということになるが、ここではその時期を含めて「IT業界」という言葉を使う。

30年ほどこの業界にかかわってきてずっと、この業界のプロジェクトは成功した例があるのだろうか?と感じていた。

あらゆるプロジェクトが計画通りに進まず、仕様が途中で変更あるいは追加され、無謀なスケジュールと不均等な業務分担が当たり前だった。

わたしはこの業界以外を知らないが、たとえば自動車を製造する、ビルを建築する、お菓子の製品を開発して販売するといったプロジェクトでは絶対にこんなひどくはないはずだという確信がある。

IT業界が特殊な理由として私が考えていたのは、まずそれが成熟していない新しい産業であるということだ。コンピューターというもの自体が実用化され始めたのは1950年代ごろだろうか。

私は1990年代初めにこの業界で仕事を始めた。最初に入った会社は「XXシステム開発」という名前で、ソフトウェア開発を主業務としていた。その会社はある企業のシステム部門が独立した会社だった。

私が入社した時(最初は契約社員だった)、机の上にパソコンはなかった。
灰皿があった(と思う)。

私が入社して2年くらいして喫煙室ができたので、それまでは室内で吸っていたはずだ。

プログラミングするときは、コーディング用紙に鉛筆(シャーペン)で書いて、完成してから端末で入力した。

コードを入力できる端末はそのオフィスには確か3台くらいしかないので、交代で使用するのである。

その端末は本当に「端末」だった。

今の人は「タンマツ」といっても通じないか。

タンマツというのは、ホストコンピュータに接続されてディスプレイとキーボードをそなえたものであり、一見現在使用されているデスクトップコンピュータのようだが、実際に処理が行われているのはホストコンピュータであり、「端末」は入出力装置にすぎない。だから「端末(Terminal)」なのである。

私の所属していた部署は「オフコン」を使用するシステム開発をする部署であった。
「オフコン」とはオフィスコンピュータの略であるが、いわゆるメインフレームと言われる大型のコンピュータと同様の機能を持っているが小型でオフィス等におけるくらいの人の腰の高さくらいの大きさのコンピュータである。

ドキュメント類も鉛筆と定規を使って手書きで書いていた。
フローチャートとか、ファイル定義とか。

1992年くらいからか、職場に自分のノートパソコンを持ち込む人が現れ始めた。
そしてオフコンを使ったシステムの需要は急速に減少していき、仕事が暇になった。
そして1995年に私はその会社を辞めた。

Windows95が発売された年である。

5年ほどいたその会社でかかわったプロジェクトでうまくいったと言えるものはほとんどなかった。比較的うまくいったプロジェクトは、要件があいまいなままなんとなくだらだら続けたものか、ガチガチに要件を固めて客に有無を言わせず作ったものかのどちらかだった。

それからはソフトウェア開発からインフラ構築とか検証とか運用のような業務をするようになっていったが常にキーボードをたたいて何かしらのコマンドを実行したりコードを入力することをしていて、自分は「SE(システムエンジニア)」であると自覚していた。

1995年のWindows95の登場をきっかけに家庭や企業でのインターネット利用が本格的に普及しはじめ、職場では一人1台パソコンを使用するようになっていった。

そして私はネットワークを主に担当するネットワークエンジニアとなっていった。

ネットワークはソフトウェア開発とは多少異なるが、やはり要件定義、設計、構築(実装)、試験(検証)、運用というフェーズを経るのは同じだった。

そしてネットワークのプロジェクトもだいたい計画通りにいかず仕様変更(要件変更)や追加は当たり前でやっとの思いでプロジェクトを完遂させるのだった。

なぜ、IT業界のプロジェクトはうまくいかないのだろうか。
今、改めてそれを考えている。

私は最初の会社でシステムエンジニアをしていた時に「人月の神話」という本を読んだ。
これは今では当たり前に言われる「プロジェクトマネジメント」について書かれた本であるが、私がこれを読んだ当時プロジェクトマネジメントなどという言葉はほとんど聞いたことがなく、会社にもそのようなポジションはなかった。

SE(システムエンジニア)とPG(プログラマ)があるだけだった。

今年、人月の神話のことを思い出して改めてざっと読んでみたのだが、
結局30年間、この本に書かれているプロジェクト管理についての問題とそれを解決する特効薬のような手段(銀の弾丸)はないというある意味悲観的な結論が正しいというのは変わらなかったのだと再認識した。

IT業界というのはソフトウェアが非常に重要であり、わたしにとってITとはほとんどソフトウェアとイコールである。

コンピュータや通信機器はソフトウェアを入れる箱のようなものであり、ITエンジニア(システムエンジニア)というのは、その箱を作る人ではなく箱の中に入れるものを作る人であると考えている。

30年前から、ソフトウェアなどというものはコンピュータを動かすためのちょっとしたおまじないのようなものだと考えている人がいたが、それは現在も同様である。

ITのプロジェクトが失敗する根本的な原因はソフトウェア軽視なのではないか?

そしてもう一つ、ソフトウェアやプログラミングというものが数学だと思っている人が多い気がするが、一般の企業で社員が使用するようなシステムにおいては、ソフトウェア開発でもネットワークシステム設計においても数学を使用することはほとんどない。

(四則演算とか不等号とか2進数16進数などは必要だがそれは数学というほどのことではない)


「私は文系だからプログラミングができない」
「私は理系だからプログラミング(コンピュータ)のことがわかる」

これは実際に私が職場で聞いた発言であるがどちらを聞いた時も釈然とせず少し憤りをおぼえさえした。

わたしがコンピュータプログラミングに興味を持ったのはテレビでBASIC言語を知り、

if a>0 then goto 10

という構文を見た時だった。

「もし...なら、...しろ」
コンピュータが人間の言葉で動かせるんだ、という驚きである。

つまり、プログラミングは数学ではなくむしろ英語なのである。

(アセンブラとかはもちろん例外)

「理系だから英語が苦手」
「文系だから数学わからない」

それはいいが、だからといって理系だから「if ... then」がわからないとは言えないだろうし
文系だからって「 a > b  」は理解できるだろう。

そしてIT業界(先ほど言ったように一般企業で社員が使うようなシステム)で必要な英語も数学もその程度でしかない。

出身が理系文系かなど関係ないのである。

あと、「数学とプログラミングは論理的思考が必要な点で似ている」とかいうのもよく聞くのだが、数学でなければ論理的思考は必要ないのだろうか?

文章を読んだり書いたりするときに論理的に考えないのだろうか?

そういうことを言う人は「英語や歴史は考えないで丸暗記するから」程度のことしか考えていないのではないか?


ここまで書いてきて、ITプロジェクトがうまくいかない、炎上する、破綻する、頓挫する、終わらない、理由が分かった気がする。

まず、コンピュータやソフトウェアが魔法のツールであるという過信。
それらも人間がプログラミングしデバッグし検証を繰り返すという地道な作業なしに成立しないことへの不理解。

先ほどの文系理系数学英語というものと結び付けて話すことからわかるように、学問や技術についても学校などで教えてもらえば使えるハサミやトンカチのような便利な道具であるとしかとらえていないこと。

つまり、ほかの業界では当然考えたり確認したりするようなことを、IT業界ではしなくていいという先入観、これが根本原因ではないだろうか。

2022/02/06

CA作り直し

何度やっても忘れる...
#opensslの設定ファイル場所

/etc/pki/tls/openssl.cnf


#抜粋

####################################################################
[ ca ]
default_ca      = CA_default            # The default ca section

####################################################################
[ CA_default ]

dir             = /etc/pki/CA           # Where everything is kept
certs           = $dir/certs            # Where the issued certs are kept
crl_dir         = $dir/crl              # Where the issued crl are kept
database        = $dir/index.txt        # database index file.
#unique_subject = no                    # Set to 'no' to allow creation of
                                        # several certs with same subject.
new_certs_dir   = $dir/newcerts         # default place for new certs.

certificate     = $dir/cacert.pem       # The CA certificate
serial          = $dir/serial           # The current serial number
crlnumber       = $dir/crlnumber        # the current crl number
                                        # must be commented out to leave a V1 CRL
crl             = $dir/crl.pem          # The current CRL
private_key     = $dir/private/cakey.pem# The private key


なるべくデフォルト値を使う
ファイル名は、キーは xxxkey.pem 証明書は xxxcert.pem とする。

コマンドは /etc/pki/CA で実行する。

CAの秘密鍵の場所は /etc/pki/CA/private.cakey.pem
CA証明書は /etc/pki/CA/cacert.pem



#CAの秘密鍵生成

[root@god tls]# openssl genrsa -aes256 -out ./private/cakey.pem
Generating RSA private key, 2048 bit long modulus (2 primes)
..............+++++
..............+++++
e is 65537 (0x010001)
Enter pass phrase for ./private/cakey.pem:
Verifying - Enter pass phrase for ./private/cakey.pem:



#CA秘密鍵の場所

/etc/pki/CA/private/cakey.pem



#CAのcsr作成(openssl.cnfにデフォルト値を設定)

root@god tls]# openssl req -new 
-key ./private/cakey.pem 
-out ./cacert.csr

Enter pass phrase for ./private/cakey.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [JP]:
State or Province Name (full name) [Tokyo]:
Locality Name (eg, city) [Shinjuku]:
Organization Name (eg, company) [example]:
Organizational Unit Name (eg, section) [tech]:
Common Name (eg, your name or your server's hostname) []:myca.example.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:



#CAのcsrに自己署名してCAの証明書を生成(1行で入れる)

openssl x509 -days 365 -in ./cacert.csr 
-req -signkey ./private/cakey.pem 
-out ./cacert.pem

/etc/pki/CA/cacert.pem



#以下、サーバ証明書作成
#今回作成する証明書はpaloaltoのglobal protectで使う

#サーバの秘密鍵作成

[root@god tls]# openssl genrsa -aes256 -out ./gpkey.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
.................................................................+++++
...................+++++
e is 65537 (0x010001)
Enter pass phrase for ./gpkey.pem:
Verifying - Enter pass phrase for ./gpkey.pem:


/etc/pki/CA/gpkey.pem



#サーバのCSR発行(1行で)

[root@god tls]# openssl req 
-new -key ./gpkey.pem 
-out ./gp.csr


Enter pass phrase for ./gpkey.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [JP]:
State or Province Name (full name) [Tokyo]:
Locality Name (eg, city) [Shinjuku]:
Organization Name (eg, company) [example]:
Organizational Unit Name (eg, section) [tech]:
Common Name (eg, your name or your server's hostname) []:hoge.example.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:


/etc/pki/CA/gp.csr


#拡張属性指定

[root@god CA]# cat myext.txt
extendedKeyUsage = 1.3.6.1.5.5.7.3.1
subjectAltName=DNS:hoge.example.com



global protectは下記の情報を参考に設定した。
paloaltoではCA証明書とサーバ証明書を発行できる。(自己署名)
しかし、その証明書を使うとiphone接続時に証明書のエラーになってしまう。
https://hirotanoblog.com/paloalto-globalprotect-local-db/4784/#toc1

iOSやmacosでは、拡張属性が設定されている必要があるらしい。
https://support.apple.com/en-in/HT210176

そのためにわざわざcentosのopensslで証明書を発行した。



CAサイン=証明書発行
#実際は1行で入力
[root@god CA]# openssl ca -in ./gp.csr 
-keyfile ./private/cakey.pem 
-cert ./cacert.pem 
-out ./gp.pem 
-extfile ./myext.txt


Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for ./private/cakey.pem:
Check that the request matches the signature
Signature ok
ERROR:There is already a certificate for /C=JP/ST=Tokyo/O=example/OU=tech/CN=hoge.example.com
The matching entry has the following details
Type          :Valid
Expires on    :320203233742Z
Serial Number :06
File name     :unknown
Subject Name  :/C=JP/ST=Tokyo/O=example/OU=tech/CN=hoge.example.com
[root@god CA]#


#前回発行した証明書が有効なためerrorが出た。
#よくあるケースなのであえて残す
#この場合はrevokeする

[root@god CA]# ls ./newcerts/ -l
合計 32
-rw-r--r--. 1 root root 4002  6月  5  2021 01.pem
-rw-r--r--. 1 root root 4002  6月  6  2021 02.pem
-rw-r--r--. 1 root root 4002  6月  6  2021 03.pem
-rw-r--r--. 1 root root 4002  6月  6  2021 04.pem
-rw-r--r--. 1 root root 4161  2月  6 08:31 05.pem
-rw-r--r--. 1 root root 5631  2月  6 08:37 06.pem
[root@god CA]# openssl ca -revoke ./newcerts/06.pem
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Revoking Certificate 06.
Data Base Update


#再署名

[root@god CA]# openssl ca -in ./gp.csr 
-keyfile ./private/cakey.pem -cert ./cacert.pem 
-out ./gp.pem 
-extfile ./myext.txt

Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for ./private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 7 (0x7)
        Validity
            Not Before: Feb  6 01:15:35 2022 GMT
            Not After : Feb  6 01:15:35 2023 GMT
        Subject:
            countryName               = JP
            stateOrProvinceName       = Tokyo
            organizationName          = example
            organizationalUnitName    = tech
            commonName                = hoge.example.com
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:hoge.example.com
Certificate is to be certified until Feb  6 01:15:35 2023 GMT (365 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated



#作った証明書の中身を確認


[root@god CA]# openssl x509 -in ./gp.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 7 (0x7)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = JP, ST = Tokyo, L = Shinjuku, O = example, OU = tech, CN = myca.example.com
        Validity
            Not Before: Feb  6 01:15:35 2022 GMT
            Not After : Feb  6 01:15:35 2023 GMT
        Subject: C = JP, ST = Tokyo, O = example, OU = tech, CN = hoge.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:b2:de:1f:bb:12:39:56:0f:4b:77:9c:5f:96:d2:
(略)
                    87:27:1a:0f:42:d8:f8:bd:b3:3c:25:dd:be:fa:92:
                    1f:bb
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:hoge.example.com
    Signature Algorithm: sha256WithRSAEncryption
         66:76:ea:36:f8:9d:19:16:6f:3a:6c:1d:c1:b0:a8:f1:89:88:
(略)
         0b:74:e9:7e:f5:a1:ae:e1:a5:aa:b6:6b:62:7a:a8:14:7c:6a:
         b6:53:a5:d8
-----BEGIN CERTIFICATE-----
MIIDczCCAlugAwIBAgIBBzANBgkqhkiG9w0BAQsFADBrMQswCQYDVQQGEwJKUDEO
(略)
dxQmAodMgTX6seEhz5DKzhUMG3Aie3pLVFnzuW27FPwTIxa2wt5lAvoBDGb5pWrb
tAt06X71oa7hpaq2a2J6qBR8arZTpdg=
-----END CERTIFICATE-----
[root@god CA]#


#証明書と秘密鍵を pfx形式にする

[root@god CA]# openssl pkcs12 -export 
-out ./gp.pfx 
-inkey ./gpkey.pem 
-in ./gp.pem

Enter pass phrase for ./gpkey.pem:
Enter Export Password:
Verifying - Enter Export Password:



pfxファイルをダウンロードする

tera termのSSH SCPが簡単

ファイルの属性を 666にしてから(最低必要な権限は何だろう?)

chmod 666 gp.pfx



#2023/11 追記
証明書をインポートするとき、CA証明書とサーバ証明書をインポートする。
CA証明書とサーバ証明書の組織は同じであること。
サーバ証明書は秘密鍵もインポートする。(インポート時に指定する)
CA証明書は「信頼されたルートCA」にする。

2021/10/26

paloaltoでDNATするときの「元のパケット」のゾーン

 paloaltoでDNATするとき、「元のパケット」の宛先ゾーンをNATで変換した後のアドレスのゾーンにしないように注意。


大体外からやってくる通信をLANのアドレスに変換すると思う。

ゾーンは大体、untrust → trust という通信になる。


しかし、NATポリシーを書くときには「どの通信をNAT対象とするか」という設定が必要であり、それはuntrustゾーンに来るuntrustゾーンのセグメントのIPアドレス宛であるから、送信元も宛先も untrust になるのである。


まあ、考えてみれば当然なのだが昔はまったことがあり久しぶりに設定したら同じようにはまった。


2021/10/10

「おうちWifi」はどこでも使えるのか

Softbank Airというサービスを使ったことがある。

家でインターネットを使うための装置であるが、通常は自宅に回線を引いてルーターを設置して使うが、「Air」はルーターが無線接続なのである。

ルーターの内側(LAN側)、ユーザーがルータと接続するところは無線で利用している人が多いと思うが、ルータのWAN側も無線にしてしまおうというサービスである。

「工事不要、置くだけで使えます」

みたいなキャッチコピーで宣伝されていた。


私の場合、ある事情で住まいをすぐに引っ越す予定もあったため、都合がよかったので利用した。


おうちWifiは、いわゆる「モバイルWifiルータ」のようなものだと思ったのだが、実は違う。

装置的には同じなのだが、「おうちWifi」は引っ越す場合手続きが必要になる。

モバイルWifiルータであればどこでも使える。だから「モバイル」なのである。


しかしおうちWifiは無線なのに、引っ越すときに手続きをしなければならない。

これは推測なのだが、おうちWifiについてはユーザがどこにどれだけいるかを管理していて、ユーザ数によって帯域を調整したりしているのではないか。

つまり、「工事不要」といってもSoftbankの網内ではなんらかの「工事」のようなものが施されているはずだ。

そうでなければ引っ越してどこで使おうが届け出る必要はないはずだから。


Softbank Airを使ってみての感想はあまりよくなかった。遅かった。

今はどんどんワイヤレス化が進んでいていつかはほとんどワイヤレスになるのではあろうが、まだ過渡期で、ワイヤレス通信で不満を感じることは多い。

あと、すぐ引っ越して解約する予定だったのにルータを買い取り契約にしてしまっていて、解約した後も使わなくなった機器料金をしばらく払い続けるということになり、買い取りにした覚えはないとか、説明が足りないとか文句を言った挙句ソフトバンクのサービスは二度と使わないと決め、すべて解約した。

paloaltoのconfigを見ていて

paloaltoというFWアプライアンス装置のconfigを見ていた。

paloaltoはブラウザで設定を表示、変更できるのだが、

configをエクスポートするとxml形式になる。

実機があれば、というか実機にアクセスできる権限があればブラウザで直接見ればよいのだが、わけあって実機にアクセスできないためxml形式のconfigファイルを見る必要があったのだ。

この手の装置のconfigをテキストでもらってテキストなりexcelなりで開くのはよくあることなのだが、paloaltoの場合少し苦労した。

xmlファイルというのは、htmlファイルと同じような感じで、<>で囲まれたタグに挟まれてデータが記述されている。

タグは何があるかわからず、階層化されている場合もある。

excelでxmlファイルを開くと一応解析のようなことをしてそれらしき表形式にしてくれるのだが、paloaltoのコンフィグファイルはまともな形にならなかった。

なので、xmlではなく単なるテキストファイルとして読み込んでみた。

<tag>data1</tag> 

のような形式でconfigの設定内容が並んでいる。

ポリシーの部分は以下のようになっている。


<rulebase>

 <security>

 (セキュリティルール)

 </security>

 <nat>

 (NATルール)

 </nat>

</rulebase>


そしてセキュリティルールとNATルールが数百行書かれているわけだが、

その各ルールを見ていくと、設定されている項目とされていない項目がある。

excelでうまく読み込めないので、自分で項目をそろえていった。

例えば<tag>, <to>, <from>, <source>, など。


特に困ったのがNATルールである。

paloaltoはセキュリティルールとNATルールが別になっている。

NATには送信元NAT、宛先NAT、static変換、inteface NATなど様々な方法が組み合わされるので、xmlファイルの項目のバラツキが大きい。

大体いくつかのパターンにはなるのだが、数百行あり順番も意味を持つため慎重に見ていかねばならない。

最初は同じタグの項目がexcelの同じ列になるようにそろえていったのだが、想定外のことが一つあった。

paloaltoのconfigファイルの項目は、一定の順序になっていないのだ。


例えば、

<tag><src><dst><to><from><source-translation><destination-translation>

などの項目があるのだが、送信元のみNATするなら<destination-transloation>はない。

<tag>というのは注釈のようなものだからある行とない行がある。


最初は項目がないところはずらしていけば揃えられると思っていたのだが、

行によって<source-translation>と<destination-translation>の順番が逆だったりする。


fortigateのconfigを見たこともあるのだが、fortigateはxml形式ではないが<>で項目が区切られており、設定により項目があったりなかったりはするのだがその出現順番は同じであった。

だが、paloaltoは一定でないのだ。


本当はpythonなどで読み込んでタグごとの項目をいったん変数に格納して決まった順番で並びなおして出力する、などをしたかったのだが、すべきなのだろうが、結構複雑になりそうなのでそれはしなかった。

そして地道にexcelでセルを移動して項目をそろえていった。


しばらくやっているうちに、気づいた。

そもそもxmlファイルというのはexcelのような表形式を想定しておらず、その項目がなんであるかはタグによって決定されるのであり、また、タグによらずに決定してはならないのである。


それは、今私がしているようにExcelの表形式にするには不便な仕様なのであるが、データを作成し記述することを考えた時に、項目の順番を意識せずに正しいタグさえつければ順番はどうでもかまわない、読み込むときにタグを指定すれば<src><dst><from><to>であっても<to><src><from><dst>であってもかまわないのだ。


私は若いころは固定長フィールドのファイルを使っていて、データの扱いに関する意識が古いところがある。最近はもう固定長フィールドなんかほとんど使わない。

しかし、ドキュメントはだいたいExcelで作られる。ほとんどがExcelである。

パソコンでExcelを使うことが「デジタル化」であるとか「IT」であるとかいうのは間違っている。

Excelの表形式のファイルを皆で共有して更新しあっているなんていうのは、紙に印刷したものにハンコを押すようなやり方とあまり変わらない。



2021/09/26

iPhoneのkindleに購入した本が表示されない場合

 私は電子書籍をあまり読まないのだが、

先日iPhoneを初期化してkindleを開いたら買ったはずの本がライブラリに表示されなくなった。

いったんログアウトしたり、同期ボタンを押したりしても変わらない。

私はiPhoneの言語設定を英語にしているのだが、その場合kindleの配信がうまくいかないことがある、みたいなことが以前あったので、言語設定を日本語にしてみたが変わらない。

ブラウザでkindle端末を表示させるとiPhoneが表示されているがこれはiPhoneを初期化する前に登録されたものである。

いったん登録を解除してみる。

しかし、kindleを再起動してもログアウトログインしなおしても、ライブラリは更新されない。


同じ状況の人がいないか探してみると、「Amazon.comのアカウントを見てしまっている」という人がいた。

私はamazon.comもamazon.co.jpも同じアカウントで登録している。

kindleログイン時は.comか .co.jpかなんて選択はないのでどちらにログインしているかわからない。

そこで、あえてamazon.comの方のパスワードを変えて、.comの方にログインできないようにした。

そして再度iPhoneのkindleアプリでログアウトログインしてみた。


パスワードは保存されているものは使わず手入力する。

すると「パスワードが間違っている」となった。

あれ?


自分のアカウントやパスワードを記録しているメモを見ると、

amazon(.co.jpの方)のパスワードが自分の思っているものと違っていた。


正しいパスワードを入力すると、ライブラリに購入した本が表示された。

やはり、kindleログイン時にamazon「.com」のアカウントでログインしていたようだ。


しかし、これはバグだよね。

もしくは.comと .co.jpでアカウントが統一されてないのがダメだよね。


ちなみにamazonの「コンテンツと端末の管理」でkindle端末の登録解除をした場合、

再度その端末でログインすると再度端末が表示されるようになる。


解除しようとすると「解除するとこの端末でコンテンツを購入できなくなります」などという物騒なメッセージが表示されるが、これはウソである。



2021/09/23

古いASAにASDMでアクセスできないのはTLSバージョンのせい

私はCisco ASA5505を持っている。

ヤフオクで入手した中古品だ。


ASAはASDMというJavaで動く管理用のGUIツールを使って設定する。

CLIでも設定できるが見やすかったり設定しやすかったりするのでだいたいASDMを使う。


久しぶりに引っ張り出してASDMでアクセスしたら、こんなエラーになった。


ログインダイアログ右下にあるJavaコンソール(コーヒーカップのアイコン)を開いてアクセスすると、以下のようなエラーが記録されている。

javax.net.ssl.SSLHandshakeException: The server selected protocol version TLS10 is not accepted by client preferences [TLS12]


Javaのバージョンは 1.8.0_301-b09
ASAは9.2(4)33

コントロールパネルの「プログラム」にあるJavaコントロールパネルを起動し、
詳細タブを見ると、「高度なセキュリティ設定」のところの「TLS1.0を使用する」のチェックがはずれている。


ASAにconsoleかsshでログインしてみると

# show ssl
Accept connections using SSLv2, SSLv3 or TLSv1 and negotiate to SSLv3 or TLSv1
Start connections using TLSv1 and negotiate to TLSv1
Enabled cipher order: dhe-aes256-sha1 dhe-aes128-sha1 aes256-sha1 aes128-sha1
Disabled ciphers: 3des-sha1 des-sha1 rc4-md5 rc4-sha1 null-sha1
SSL trust-points:
  outside VPNLB interface: ASDM_Launcher_Access_TrustPoint_0
  outside interface: ASDM_Launcher_Access_TrustPoint_0
Certificate authentication is not enabled


TLS1しかサポートしていない。

ASAはTLS1、JavaはTLS1.1以上だったため、接続できないのだ。

接続できるようにするには、ASAがTLS1.1以上を使うか、JavaがTLS1.0を使うようにすればよい。

が、結論から言うとどっちもできなかった。
ASAには ssl server-versionというコマンドがあるのだがtlsv1より上を設定できない。

そしてJavaコンソールでTLS1.0をチェックしても、上記のエラーは変わらない。
ここの設定を変えてもTLS1.2で接続しようとするようなのだ。

家にJavaがインストールされていない古いパソコンがあったので、
そこに 1.7.0_80-b15 を入れてみた。

Javaコンソールを開くと「TLS1.0を使用する」がチェックされており、1.1と1.2はチェックされていない。

この状態だとASDMで接続できた。


OSをあげれば、と思ったが、
5505は販売終了製品で、9.2(4)33が2018年にリリースされた後新しいバージョンはリリースされていない。

JavaコンソールでTLS1.0をチェックしてもダメな理由がわからず、
どこか別の設定を変えればいけるのかもしれないが使用が推奨されない古いプロトコルを使うことをあまり深追いするのもアレなので。