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

 

IPv6 Native 接続のせいか? anchor.png

今さっき出先からこのページを開こうとしたら接続できなかった。

VPN接続してローカルから接続したら見えた。

再度開いても見えないが、別の VHOST を指定したら時間がかかったのちに表示された。

ではと、もう一度開いたら表示された。

そういえば、前にもあったような気がする。 ipv6 接続できる環境からの場合に、常には ipv6 が有効ではないためか、 接続性がわるいのだろうか? と思った覚えが。

内部から ping6 で外部のホストをしていすると、最初のパケットが落ちたのちに接続されることもあるので、可能性として、常に経路は確保されていないのだろうなということか。

10分毎に、ランダムに外部の実在するホストに ping6 でパケットを1つだけ投げるとかやってみようかな(こらこら)


 

yum と logwatch と logrotate と … anchor.png

logwatch をメールで送信し、管理しているホストの状態を少しだけ把握している。

そんな中、yum で install/update を実行した結果が入った logwatch のメールが届いた。 そんな覚えはないので、なにか不具合化と思いサーバーにアクセスし、確認したが、 history には何も作業した形跡がない。

ログを確認すると、確かに 4/19 の作業でリストアップされている。 …のだけれど、その下には 5/20 とか、8/10 とか、12/09 などが続いて記録されていた。 yum.log の日付を確認すると、昨日ではない。

結果、ローテートされていない事が判明した。 つまり、yum の結果は過去のもので、logwatch は素直に拾ってくれたものだった。

logrotate の設定をみると以下のように定義されていた。

/var/log/yum.log {
   missingok
   notifempty
   size 30k
   yearly
   create 0600 root root
}

notifempty は指定されていて、丁寧に size 30k も指定されていた。 単位も年単位、ここ1年 yum で更新したものが少なかったんだなと判明しました。

では、size の指定を外せばいいようです。1年も1月に変更して置こう。


 

YAMAHA RTX1210 で IPv6 address に tentative と表示される anchor.png

いままで気にしたことがなかったのでメモ

IPv6 でアクセスする必要がでたので (flets-v6.jp) 、LAN1 をターゲットに以下の設定をしました。

ipv6 prefix 1 ra-prefix@lan2::/64
ipv6 lan1 address ra-prefix@lan2::1/64
ipv6 lan1 rtadv send 1

この設定をした場合、すぐにアドレスが有効になってくれていたと思うのですが、 今回は、振られたアドレスに対して、自身かもも ping6 が通りません。

しかも、表示されたアドレスをみると、みたこともない tentative などと表示が付いています。

global     240x:xxx:xxx:xxxx::1/64 (tentative) (lifetime: 604728/2591928)

「仮」と言われても、それは一時アドレスは違うもの? と思う程度で、解消する方法がわかりません。 この時 scope-id も down と表示があります。

LAN1 scope-id 1 [down]

このままでは問題があるのと、いろいろ試す必要がある可能性がでたため、LAN1 からは設定を削除し、 LAN3 に対して

ipv6 prefix 1 ra-prefix@lan2::/64
ipv6 lan3 address ra-prefix@lan2::1/64
ipv6 lan3 rtadv send 1

のように設定しなおしました。 prefix の設定はそのままです。
当然のように

global     240x:xxx:xxx:xxxx::1/64 (tentative) (lifetime: 604728/2591928)

となりますが、そもそも LAN3 には何も接続していない状態ですし、 気にせず、端末を接続します。

通信できるようになりました。

もしかして、LAN1 に接続している端末に IPv6 の RA を受けて通信をする機器が無かったのかな? と、いまさら思いましたが、とりあえず気にする必要はないようですね。という話。

蛇足的な情報ですが、 今のところ LAN3 から端末を外しても利用可能になっています。 lefetime を超えて変化があれば追記します。

Page Top

その後 anchor.png

使わずに放置していたら以下となりました。 そもそも ping6 で応答したさいに scope-id はの状態が up になったかは確認してませんでしたが、

# show ipv6 address lan3
LAN3 scope-id 3 [down]

 global     240x:xxx:xxx:xxxx::1/64 (lifetime: 604728/2591928)

別のネットワークから ping を実行すると、最初にタイムアウトしましたが、通信はできました。scope-id は down のままでした。

Page Top
では次に anchor.png

実は ipv6 の設定は、以下のようにすることに変更となっています。

ipv6 prefix 1 ra-prefix@lan2::/64
ipv6 lan1 address ra-prefix@lan2::1/64
ipv6 lan1 rtadv send 1 o_flag=on
ipv6 lan1 dhcp service server
ipv6 lan2 dhcp service client ir=on
dns server dhcp lan2

参考

今回足りていないのは、以下でしょうか。DNS は置いといても良いかと思いますが、 client 設定を追加してみます。

ipv6 lan2 dhcp service client ir=on
dns server dhcp lan2

dhcp で貰った情報を確認すると、DNS サーバーもあるので、上記の dns の指定も行います。完了すると

ping6 www.flets-v6.jp
received from 2404:1a8:ff06::1, icmp_seq=0 hlim=57 time=9.414ms

これで完了です。

※追記

ir=on を指定する目的は DNS サーバーの情報を得るためだけのようですね。


 

ip address - searchclient.live.net anchor.png

サーバーが重いとのことで、確認していたら、ものすごい勢いで以下のログが流れていました。

127.0.0.1 - - [16/Mar/2017:14:52:06 +0900] "GET /BingBar/signed/SeaPort.cab HTTP/1.1" 404 26902 "-" "SeaPort/3.1"

BingBar だと? Linux BOX にはそんなの用意した覚えはないけどな、 でも、アクセス元は Localhost だしな…とログを確認していました。 まさか、感染したか! ともよぎりましたが、だとしても攻撃先は自分だし、 調査してみようとも思ったわけです。

いろいろ試してみましたが、あやしそうなファイルは見つからないですし、プロセスは httpd のようにも見えます。

ふと、httpd のように見える可能性として proxy のログをみると、 同じタイミングでとあるホストからリクエストがきています。

対象ホスト名は searchclient.live.net です。 そもそも proxyのログも含めて検索しておけば、最初にみつかった筈でした。 なぜ、このホストのリクエストが 127.0.0.1 からのアクセスに変わってしまうのか?

# dig searchclient.live.net
searchclient.live.net.  3600    IN      CNAME   searchlive.vo.msecnd.net.
searchlive.vo.msecnd.net. 3600  IN      A       127.0.0.2

えーと。なにしてくれる(笑)

proxy.pac を書き換えて 127.0.0.0/8 は、直接アクセスするように変更しました。


 

Sophos UTM9 WAF の動作 anchor.png

何気なく Advance を選択し、外部経由で参照できる事を確認しました。 表示できるので問題なしとしていたのですが、Dialy の日付が表示されなかったり、 表題が本文と同じだったり、そもそも綺麗ではない配置が、 輪をかけて崩れているように見えたり。

ってことで、Basic に戻しました。

XOOPS X を利用しているのですが、CSS の取得時に WAF でドロップする対象となってしまうということなのでしょうね。


 

sakura internet の web mail にログインできない? できた。 anchor.png

「ドメイン名が間違っています」とつれないメッセージを表示しログインできません。

移行が完了し、初期ドメインでログインする事でメールの確認はできるのですが、 あまり良い状態ではありません。メールクライアントからはメールをし受信できるので、 それほど困った状態ではありませんが、外出した時などに利用する人がいる事を考えていたので、 ドメインの指定が自分のドメインでないのはいまひとつです。

とりあえず、メールが届いたことも確認できたし、さくらのサーバーに設置した Web も動作確認がおわったので、もう戻す必要はないとの判断を行い、 DNS の TTL を、切り替え用の 600 から、3600 に変更しました。

さくらのウェブメールにログインできるようになりました。

たしかに、さくらの ns1.dns.ne.jp が提供している TTL も 3600 だけどさ。 ここで判断されているとは思いもよらず。 そういえば、移行用に MX のサブとして、旧サーバーの指定を置いていたのだけれど、それかもー


 

Gateway に設置した Linux Box の動作が遅い、原因は Zabbix Proxy anchor.png

サーバースペックは上がっているけれど、 やる事が決まっている Gateway の必要機能が増えることもない、 それより、Sophos UTM9 を前において管理するほうが都合がよいかもしれない、 などと考えて、Gateway を仮想の ゲストとして作成した。

同じ機能だし、同じメモリ量だし、同じCPU数を割り当てたし、遅いのはなぜだ? となってしまった。遅いと感じるのは、HDD の反応が顕著で、 vdisk だからかと思わなくもないけれど、raw 形式で確保してあるので、 極端に速度が落ちるのはおかしい。と思っていた。

昨日、Zabbix Server の調整を行うために、一旦 Zabbix Proxy を止めたところ、 反応がとても良い。すこぶる良いので、Zabbix Proxy を停止しようと考えた。 しかし、Zabbix Proxy を止めるということは、代わりとなる機能を用意しなければ、 外部に置いた Zabbix Server に NIC を追加して社内に接続するなどの方法が必要なわけで、 外部と内部が接続されている Gateway が可能な機器が増えるのは自分としては嬉しくない。

では、Zabbix Proxy が HDD に書き込む負荷を減らせばよいのかな? と考えた。

データベースには MySQL (mariadb) を使っていたのですが、これを sqlite に変更し、 書き込み先を HDD ではなく、/dev/shm/zabbix-server にしてみた。

早い!

あとは、/dev/shm に作成した zabbix-server のサイズがどの程度まで増えるのかを確認しなければならないのかな。

/dev/shm/ に作成したので、電源を落とすと消えてしまうのですが、 sqlite を利用したデータベースは、自分で Create する必要はないし、 スキーマを流し込みする必要もなく、Zabbix Server が勝手に行ってくれるので、 消えても問題はない。 あまり肥大化するようなら、ハイパーバイザー側の /dev/shm を nfs を公開して利用する 事にすれば、メモリは沢山ある。

ということで、様子見開始。


 

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 で取得すること自体は最低限必要となりました。

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



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