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

 

IPv6 の接続がおかしい? anchor.png

今月のはじめ頃だろうか、VMware の knowledge Base を開けなくなった。 実は同じ時期からだったのではないかと思うのだけれど、 Windows Update の確認が失敗するようになった。

そういえば、大規模サイバー攻撃云々と言われてた後からのような気がする。 ただし、因果関係はさっぱりわからない。

自分で確認した限りは、VMware も Windows Update も、 サービスを行っているサーバーが IPv6 で接続が可能であることが条件となっているようで、 IPv4 で接続する場合には、問題は発生しなかった。

Page Top
httpd (apache) よ、その設定はなんなんだ? anchor.png

修正方法は IPv4 で接続することで解決ということで、 httpd.conf の設定に ProxySourceAddress を追加すれば解決かと思ったのだけれど、 どうもうまく動作しない、マニュアル類も見つからないので、ソースをみてみる。

やっぱりわからない。

ってことで、IPv6 を削って一時しのぎ中です。


 

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 の再起動で解決 (をぃ



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