rss ログイン
dialy - ひねもす…

 

Certificate is installed correctly anchor.png

SSL証明書を申し込んだ。

crt とともに、中間証明書が送られてきた。

メールには

YOUR REQUIRED INTERMEDIATE SSL CERTIFICATES (CA) ARE BELOW

とある。以下の部分をコピーして intermediate-ca.crt とか、server-ca.crt とか、 それなりにわかる名前を付けて保存し、apache の httpd.conf (ssl.conf) で指定する。

-----BEGIN CERTIFICATE-----
~
-----END CERTIFICATE-----

チェックサイトへアクセスする。こんなやつ Check your SSL/TLS certificate installation

INTERMEDIATE が見つからないからダウンロードしろと表示される。

入れ替える。

治る。

Rapid SSL では毎度のことだけれど。 改行位置が違うだけで、同じデータだと思うのだけれどな…

diff しても同じようですね。これは、罠なのかな。


 

tmp ファイルが開けないとの問い合わせ anchor.png

コンソールを使うような事は無い方が、tmp ファイルが開けないと連絡をくれた。 なんの? と聞いたら。メールだという。

「添付ファイル」というオチ。

Windows の再起動で解決 (をぃ


 

RTX1210 が DHCPv6 でアドレス更新できない anchor.png

正直、配線方法にも問題があるので、実際の原因が判らないし、対応方法も一般化できないのだと思うけれど、面白い事象だったのでメモして置こうと思います。

問題点
  • DHCPv6 でアドレス取得する。
  • 約3時間後に接続できなくなる。
環境
  • 東日本 Flets ギガ
  • 光電話契約あり
  • 交換機の導入業者が微妙で、主装置経由にすると IPv6 アドレスを貰えない。
    NTT とも相談して、試しに ONU から HUB を使って、主装置とルーターを接続。
  • DHCPv6 のアドレスが取得できる事を確認 (NGN type を NTT で設定)
  • ipv6 routing on
  • dhcp-prefix@lan2 は /56 なのと、光電話が導入されているので、 dhcp-prefix@lan2::20:0:0:0:1/64 のように lan2 prefix を指定することとした。(参考 noBLOG)
設定 (抜粋)
ipv6 route default gateway dhcp lan2
ipv6 prefix 1 dhcp-prefix@lan2::20:0:0:0:1/64/64
ipv6 prefix 2 dhcp-prefix@lan2::21:0:0:0:1/64/64
ipv6 lan1 address dhcp
ipv6 lan1 prefix dhcp-prefix@lan2::21:0:0:0:1/64
ipv6 lan2 address dhcp-prefix@lan2::20:0:0:0:20/64
ipv6 lan2 prefix dhcp-prefix@lan2::20:0:0:0:1/64
ipv6 lan2 dhcp service client
ngn type lan2 ntt
経過
  • およそ一番発生してるのは、show status ipv6 dhcp で確認すると renewと表示されてまま更新されていない状態です。
  • ここで、prefix 指定の変更を試すと rebind, などと変わりますが、 アドレスを取得することはできまん。
  • ごくまれに、dhcp を情報を取得していると表示はされている事があるのですが、 通信を行うことはできません。
えいや!
  • show ipv6 route で、ルーターのリンクローカルを確認しておきます。
  • gateway をスタティックに書き換えます (fe80::1 だったとして)
    ipv6 route default gateway fe80::1%lan2
  • prefix などの指定が必要かどうかは不明ですが、適宜設定します。
  • ipv6 lan2 address を prefix-dhcp@lan2 の値をもとに、即値で設定します。
  • 通信できる事を確認します。
  • dhcp アドレスを再取得します。以下コマンドを実行すると、init から行ってくれます。
    no ipv6 lan2 dhcp service client
    ipv6 lan2 dhcp service client
  • 接続がきれなければ、スケジュールに、上記コマンドを設定しておきます。
    1時間に一回でも、2時間に一回でも構いませんが、3時間以上空けるのはおススメしません。
  • console に接続すると、メモリに保存されていないため
    There are changed configuration unsaved in nonvolatile memory!
    が表示されると思いますが、スルーしましょう。
捕捉
  • 設定値として dhcp-prefix@lan2 のようにダイナミックに値が変化するマクロ値を使っている場合、
    コマンド (ipv6 lan2 dhcp service client) というか、config の設定を行った時点で書き換わってしまいます。 当たり前というか、それを期待して設定しています。
  • 実行すると、init が実行され、アドレスが取得するまでの間、値がなくなってしまうために通信が切れしまいます。
  • 実際には dhcp-prefix も、ra-prefix も、そうそう変更されることはありません。
  • そこで、実際に設定された値を使って、即値として config に入れることで回避してみようと考えました。
  • なお、DHCPv6 でアドレスを取得をしていない場合、たとえ結果同じ値となるにしても、通信は行えなくなりました。 ですから、アドレスを dhcp で取得すること自体は最低限必要となりました。

本当の解決策を調べている最中ではありますが…ひとまず回避しているような・いないような…


 

CentOS7 の bind が更新されないと思ったら anchor.png

最新版を使うために自分でビルドしなおして Epoch の指定をしていたのでした。

さて、ビルドしますか。


 

Firefox が不正な SSL 証明書ですと表示する (RapidSSL) anchor.png

少し長い期間の SSL 証明書を導入したサーバーにアクセスした際に、 Firefox が不正なSSL 証明書である旨の表示をだしてくれた。

今時だと、不明証明書で、sha1 だったりしたかと思ったが、 昨年再発行して切り替えた覚えがあるし、実際 cert だけみれば問題ないというか、 IE も Chrome も文句を言いません。

なにか間違っているのは確実なので、と言うよりも、中間証明書が間違っている可能性が高いので、 発行したサイトで、Rapid SSL の中間証明書を確認すると、 2つ登録されていた。 片方は現在利用しているものだったので、もう片方の G3 と書かれたものに切り替えてテストしてみるが、Firefox は同意見のようで、解消されません。

ではと GeoTrust のチェッカーを利用して、証明書のインストール状態を確認します。

https://cryptoreport.geotrust.com/checker/

図らずも、中間証明書が登録されてないとのエラーが?! しかも RapidSSL SHA256 CA - G2 が必要とのこと。無かったよそれ(笑)

流石 RapidSSL 用のチェッカー、ダウンロードリンクも表示されたので、 早速入れ替え。

無事?! 解決しました。

 

ということは、いままでは、証明書が未インストール状態となっていて、 たまたま、ブラウザが自分で証明書の確認を追ってくれて、たまたま正しいと判断されていただけという落ちだったということですね。お恥ずかしい限りです。

入れ替え時は確認しているはずなんですが、たくさんやっていると…なのですが、 言い訳にしてはイケない問題ですね。

参考: 各社のSSLサーバー証明書インストールチェッカー リスト


 

いまさら翼といわれても anchor.png

久々の古典部!

「満願」と「王とサーカス」の…的な帯がついていましたが、米澤氏と言えば古典部だと思うのは自分だけでしょうか。インシテミルももちろんですが :-)

忘れてはいけない。小市民にも一票…ですよね。


 

Kiss of Death anchor.png

ntp.nict.jp を利用しています。ntp.nict.jp は複数のサーバーで構成されていて、 今単純にアドレスを確認してみたら、 4つほど提供されていました。

ntp.nict.jp.            80520   IN      A       133.243.238.163
ntp.nict.jp.            80520   IN      A       133.243.238.243
ntp.nict.jp.            80520   IN      A       133.243.238.164
ntp.nict.jp.            80520   IN      A       133.243.238.244

本日、ログをみていたら KoD との表示がありました。

Dec 16 12:03:10 ntpd: receive: KoD packet from 133.243.238.244 has inconsistent xmt/org/rec timestamps.  Ignoring.

KoD ってなんだっけなと、いうことで調べたら Kiss of Death とのこと。 Stray Penguin 様によると、どうも、こちらがレートリミットを超過したらしく、時刻問い合わせの中止を促すメッセージのようでした。 受け取った側は、ひとまずアクセスしないような動作となる…らしいですが、どうみても、 このログは無視していますね。

nict.jp の情報をあたっても、なにも掲示されていないようですし、DNS からも該当サーバーは外れていないので、ひとまず問題なしという事で良いのかな?


 

同じファイル名のファイルが存在する anchor.png

inode 番号でファイルを削除する事が可能とか。

まずは ls -i で調べる

# ls -li
total 0
1958119 -rw-r--r-- 1 root root 0 Dec  9 14:36 p1771pbh7e4j71pr139tdi9b6g3.tmp
1958119 -rw-r--r-- 1 root root 0 Dec  9 14:36 p1771pbh7e4j71pr139tdi9b6g3.tmp

同じだった。

find で検索しても、inode が同じで、ファイル名が同じなのだから、当然同一ファイルとの扱いとなるわけですが、片方しか削除できない。

# find . -inum 1958119
./p1771pbh7e4j71pr139tdi9b6g3.tmp
./p1771pbh7e4j71pr139tdi9b6g3.tmp

片方…という指定ではなけれど、とにかく、削除すると以下のようになる。

# ls -li
ls: cannot access p1771pbh7e4j71pr139tdi9b6g3.tmp: No such file or directory
total 0
      ? ?????????? ? ?    ?    ?            ? p1771pbh7e4j71pr139tdi9b6g3.tmp

どうにもならないような気がしてきた。

なお、この状態で

touch p1771pbh7e4j71pr139tdi9b6g3.tmp

とすると、最初の状態に戻ります。


 

virtual memory exhausted: Cannot allocate memory anchor.png

とりあえず確認するために実行

ulimit -a

結果は

virtual memory          (kbytes, -v) unlimited

となった。無制限かい。

free を実行したら、思いっきり swap している様子。なにが? と思って確認したらZabbix Server だった。 少し古めの Zabbix Server を利用しているのが原因かな? バージョン上げた方がよいかもしれませんね。

Zabbix Server をリスタートしたら解消しました。


 

お名前.com でセカンダリを利用する場合の設定方法が変更された… anchor.png

どうやら、転送のみを行うサーバーを用意した事と、 2nd.dnsv.jp. を IPv4, IPv6 に対応させたということのようです。

多数の方を、このセカンダリサービスを利用するがためにお名前.comを勧め、 DNSの設定を行っているので、全部直さないとですが、簡単なので問題なしと。

実のところ、主題は named.conf の話です。このようなケースで BIND を利用している場合、 平行して許可を行うために、ACL の定義を使って

ACL ONAMAE {
    210.172.129.81;
    163.44.76.202;
};

のように記述、 zone では

               allow-transfer { ONAMAE; };

と記述して置けばよいだけですから、前もって設定することも簡単ですし、 後始末も簡単ですね。

しかし、今回の場合は NS に指定されていない 163.44.76.202 が転送を行い、Nofity も、163.44.76.202 に行う必要があるようなので、個別に

ACL ONAMAE-NOTIFY {
    163.44.76.202;
};

と定義しました。NS 指定されているサーバーには、そもそも通知を行ってくれるので、 片方の IP しか書く必要がなく、別にした方がよいと思ったからです。

               also-notify { ONAMAE-NOTIFY; };

ZONE にも、上記のように定義を行い named-checkconf を実行すると、

unable to find masters list 'ONAMAE-NOTIFY'

だそうです。簡単に言えば、指定が間違っているということ。

also-notify に IP を記述すれば問題ないので、どうも ACL ではなさそうです。 実際、出力されたエラーには masters list とありますね。

もしかして、Type slave の時に記述する masters か? ということで

masters ONAMAE-NOTIFY {
    163.44.76.202;
};

と変更してみました。named-checkconf での問題がなくなったので、リロードして完了です。

以前から、slave の設定するさいに masters と記述する事が疑問でした。 masters は複数かけるのは承知していましたが、 実際に Type master と記述するサーバーは 1台しか用意しないしなと、 いえ、そもそも Type master が複数ってオカシイでしょうから、 なぜ masters は複数記述できる仕様なのかが疑問ということです。

今回のように、NOTIFY を送るサーバーを別に指定したり、 NS に定義しない、サーバーに NOTIFY を送信する事が可能で、 その時、masters 指定を使うのだということ理解していなかったので、 目から鱗が落ちました。

コンタクトレンズだろうって(^^?



トップ   凍結 差分 バックアップ 複製 名前変更 リロード   ページ新規作成 全ページ一覧 単語検索 最新ページの一覧   ヘルプ   最新ページのRSS 1.0 最新ページのRSS 2.0 最新ページのRSS Atom
Last-modified: 2016-09-02 (金) 15:38:26 (JST) (176d)