2018/09/12(水)北海道胆振東部地震の被災状況orz

・液晶ディスプレイ損傷 1台  → 継続使用困難なので買い替え
・大規模停電によるサービス不能 → 非常用発電機導入(2台必要)

# 発電機については、今までの15年以上も事あるたびに要請続けてきたが、
# なかなか理解得られず、今回も理解を完全に得られていないので、導入実現は不透明。

それ以外の被災は無し。
震度6弱に近い震度5強の揺れだったが、よくもまぁ住宅やモノが壊れなかったものだと。。

近所では、店舗のシャッター損壊と、壁が剥がれた古い建物が1棟でした。

2018/08/20(月)IPv6 6to4 接続を常に優先させる

結構嵌ってしまったので、自分メモ。
ネイティブ IPv6 接続と 6to4 接続、及びローカルLANを1つのサーバに接続している(つまり、3つの回線を接続している)環境で、IPv6 接続が全く出来ない現象に遭遇しました。

どうも
〈サーバからインターネット側への接続〉→ IPv6 接続出来る場合と出来ない場合がある
〈インターネット側からサーバへの接続〉→ IPv6 接続は全く接続出来ない
〈同一ネットワーク又はLANの接続〉 → 問題ない
という現象のようです。

最初、pf のフィルタ設定に問題があるのかと思っていましたが、どうやっても現象は解消せず。
なので、インターネット側から ping6 を流し、tcpdump コマンドでチェックしてみます。
※こんな時に役立つ tcpdump コマンド・・・

すると、なんと! 勝手にNGN回線へパケットが流れている!
ルーティング状態を見てみます....
20180820_1.png


上記で re2 と示すのがNGN回線です。これでは応答を返しても相手に届かないわけです。

何故こうなるのか。。 
どうやら FreeBSD では、OSが立ち上がる時、最後に認識したLANボードで取得したルーティング情報をデフォルトゲートウェイにしてしまうようです。(というか、IPv6的仕様らしい?)
こんな時のために、「ルータアドレスをデフォルトゲートウェイにしない」という指定がネットワークインターフェースに対して出来るようになっています。

具体的には下記のように /etc/rc.conf に指定します(アドレス等は伏せ字にしています):
ipv6_default_interface="re0"
ipv6_defaultrouter="2002:c058:6301::"
ifconfig_re0_ipv6="inet6 2002:xxxx:yyyy:zzzz::qqqq/48 -accept_rtadv"
ifconfig_re1_ipv6="inet6 fdxx:pppp:gggg:hhhh::nnnn/64"
ifconfig_re2_ipv6="inet6 accept_rtadv no_radr"
2行目の、2002:c058:6301:: は、6to4 のリレールータIPアドレス(6to4 においては特に必要で無い限り固定)、
1行目の re0 は、6to4 で接続するネットワークリンクのLANボードを示します。

5行目、 re2 の no_radr というキーワードで、「デフォルトゲートウェイにしない」を指定します。
re0 をデフォルトインターフェースに指定することで、デフォルトゲートウェイが re0 のリンクになります。

/etc/rc.conf を修正後に再起動して、再度ルーティングテーブルを確認します:
20180820_2.png


これで、〈インターネット側からサーバへの接続〉は出来るようになります。
しかし、〈サーバからインターネット側への接続〉で、デフォルトインターフェースに re2 が勝手に選ばれ、NGN回線からインターネット接続しようとします。。

IPv6固有のアドレスポリシーテーブルを変更しないといけないようです。
デフォルトでは、このテーブルは以下のようになっています。
 ::1/128     50   0
 ::/0       40   1
 ::ffff:0:0/96  35   4
 2002::/16    30   2
 2001::/32     5   5
 fc00::/7     3   13
 ::/96       1   3
 fec0::/10     1   11
 3ffe::/16     1   12
2002::/16 の 6to4 エントリは不要です。
自ノードが使うアドレスがある場合、大抵は削除するとよいです。筆者の場合は以下のように変更しました:
 ::1/128     50   0
 ::/0       40   1
 ::ffff:0:0/96  35   4
 2408::/22    10   6
 2001::/32     5   5
 fc00::/7     3   13
 ::/96       1   3
 fec0::/10     1   11
 3ffe::/16     1   12
*1

上記内容を /etc/ip6addrctl.conf に作成し、root ユーザにて
# ip6addrctl flush
# ip6addrctl install /etc/ip6addrctl.conf
を実行することで、即座に反映します。
また、サーバ再起動時に /etc/ip6addrctl.conf を読み込むため、設定内容がその場限りで消えてしまうことはありません。

これで、〈サーバからインターネット側への接続〉も常に 6to4 が優先されるようになりました。

*1 : 2408:://22 の行はたぶん要らないと思う。。(動作は 2018/08/20現在 未確認)

2018/06/25(月)6to4 回線の IPv6 逆引きを公開設定

今は日本人に優しい資料が無い(あってもちょっと古い)ため、いつもの備忘録代わりに作ってみました。
これを使うためには、
・当該サーバ等を 6to4(IPv4 回線における IPv6 トンネル接続) にて IPv6 に接続している。
・使用するIPv4アドレスは、固定IPである
・設定したい 6to4 IPv6 逆引きゾーンを登録する権限がある

といった前提条件があります。ネットワーク管理者中級向けといったところでしょうか。

この設定をするには、予め該当の 6to4 で使用する IPv6 アドレスの逆引きゾーンを登録したい権威DNSに登録しておかなければなりません。
例えば IPv4 アドレスで 192.168.1.50 に対応する 6to4 IPv6 アドレスは、2002:c0a8:0132::/48 となりますので、
逆引きゾーン 2.3.1.0.8.a.0.c.2.0.0.2.ip6.arpa を当該権威DNSへ登録してから以下の申請作業を行います。
#例示のIPv4 アドレスは、プライベートIPアドレス領域なので、逆引き登録は出来ません。

さて、この逆引きゾーン設定は、該当のホストマシン自身から、申請作業をWebブラウザでアクセスしなければなりません。
とはいっても、該当のホストマシン自体にWebブラウザをインストールしていない場合も多いはずです。この申請のために Chrome などわざわざインストールするのも馬鹿げています。

こんなときにさくっと役立つのが、昔から「テキストWebブラウザ」として存在する Lynx というソフトウェアです。前近代的な故、今どきのエンジニアな方々は知らないかもしれません。画像や動画、音声には対応しませんが、それ以外のコンテンツは何とか表示できます。

FreeBSD においては、 Lynx は Ports で簡単にインストールできます。(Portsツリー /usr/ports/www/lynx)
Lynx をインストールした後は、
lynx http://www.basekernel.co.jp/
のようにコマンドラインでURIを指定します。筆者の環境ではこうなります。。。
20180623_1.png
日本語がまともに表示できません。設定変更を行います。
何故かメニュー部分は文字化けしていませんで、o キー押下で設定画面が出ることがわかります。
ここで、o キーを押下すると。。。
20180623_2.png
なんと、設定画面も文字化け。。。
フォーカス部分は色が変わるようなので、下記の青緑色部分で示す部分を変更します。
#リターンキーや矢印キーを使います。
20180623_3.png
ここで、下記のような表示になるように矢印キーを操作し、リターンキー押下で設定が保存されます。
20180623_4.png
一度終了し、再度
lynx http://www.basekernel.co.jp/
とすると、今度は、
20180623_5.png
こんな感じで表示されるはずです。ここからが本題で、再び一度終了させ、
lynx https://6to4.nro.net/
とアクセスします。以下のような感じになるはずです。
幾つかサーバ証明書の警告が出ますが、yで強制的に進みます。
20180623_6.png
ここで、下の方にアクセス元のIPアドレスが表示されます。
どうやら IPv4 でアクセスしているようです。なので、直接IPv6アドレス指定でやってみます。
6to4.nro.net の IPv6 アドレスは、2002:ca0c:1dea::1 のようです。
#drill コマンドでAAAA レコードを正引きしてみただけです。

一度終了させ、
lynx https://[2002:ca0c:1dea::1]/
のようにすると、今度は受付する画面になりました。
20180623_7.png
ここでパスワード(削除の際に必要になる模様)を入力し、
20180623_8.png
更に、連絡先のメールアドレス、ゾーンを登録した権威DNSサーバ名を入力し、
Submit させます。
尚、連絡先のメールアドレスと2つの権威DNSサーバ入力は必須のようです。

受理・逆引き登録が完了すると、
20180623_9.png
のようになります。何らかの問題があると英語でメッセージが表示され、この画面にはなりません。

同時に登録完了で以下のような電子メールが apnic より送信されます。
20180623_a.png
SOAレコードに登録した電子メールアドレスにも同内容の電子メールが行きますので注意してください。

2018/06/11(月)IPv6の基礎(12) -トラブル対処で役立ちそうな知識

今回は、トラブル対処や調査で出くわしてしまうような場面で、知っていれば何のことは無い、という話題です。
20180611_1.png
実は、IPv6には「一時アドレス」という概念があります。(RFC4941 で規定)
これはサーバ管理者泣かせな機能なのですが、一定時間ごとにどんどんIPv6ユニキャストアドレスが新しくなっていくのです。
そうです。これは「発信元を特定しにくくする」ためのものです。
#これも個人的には、セキュリティに過度に煩い層の影響だと思う。。

サーバ攻撃を受けた際に発信元が分かりにくくなり、原因究明に大いに影響ありそうなのです。
これを逆手にとって、ネット犯罪を助長するような一面があり、しかしながらプレフィックス部はどんなに IPv6 アドレスが変わろうが固定なので、どこまで効果があるかは疑問が残ります。

IPv6 ではリンク毎に「リンクローカルユニキャストアドレス」が付与されるという話を何度かしてきました。
早い話、LANカード或いはイーサネットデバイスが同じ機器に複数あると、その数だけ同じ機器にリンクローカルユニキャストアドレスは割り当てられるのです。
リンクローカルユニキャストアドレスはプレフィックスが同じですので、実際に通信する際は、%で始まるインタフェース名を補助的に使用して、リンクを区別します。

2018/06/10(日)IPv6の基礎(11) - 機器設定時に必要と思われる知識・トラブル対処に向けて

ここでは、インタフェースIDの決定方法について簡単にまとめてみました。
やみくもにIDを付与してもトラブルの原因になることがありますので、留意しましょう。
20180610_1.png
基本的にどのような値でも構わないのですが、IPv6 ではユニキャストアドレスの一部がエニーキャストアドレスと定義されているので、エニーキャストアドレスと区別する必要があります。

ユニキャストアドレスとしてインタフェースIDを指定する場合は、上記提示のIDを避けて指定しましょう。
ユニキャストアドレスとして使用できないインタフェースIDのうち、fdff ~ で始まるIDは、「修正EUI-64」形式を踏襲してインタフェースIDを設定する場合を想定しています。

理解の一助として、ICMPv6 などでイーサネット接続環境におけるIPアドレスを自動設定する際のインタフェースID自動生成方法をまとめてみました。知っておくと、トラブル対策の際に案外役立ちます。
尚、アドレス自動生成・手動設定に関係なく、必ず「修正EUI-64」形式で行う必要があるという訳ではありません。あくまでもひとつの方法として推奨されています。

ただ、この「修正EUI-64」も現在は非推奨になっているらしく(RFC7721,2016年3月)、新たにプレフィックスを基にした乱数発生による方式(RFC7217,2014年4月)が推奨されているようです。
#セキュリティに過度に煩い層がいるものだな・・・と個人的には思ってしまいますが。。
#この件は、次の記事で示します。

ですが、「修正EUI-64」は一般的に広く用いられており、ある日突然変更しなければならない、という状況ではありませんので、少なくともあと2~3年は定番の手法として使われ続けると見ています。

2018/06/09(土)IPv6の基礎(10) - 機器設定時に必要と思われる知識

最後に、IPv6アドレスを手動設定する場合に必要となる知識を簡単にまとめておきます。
20180606_3.png
実際にIPv6アドレスの設定をする際、お目にかかるのは、
 ・リンクローカルユニキャストアドレス
 ・ユニークローカルユニキャストアドレス
 ・グローバルユニキャストアドレス
の3つで、単に「IPv6アドレス」と称する場合は、たいてい「グローバルユニキャストアドレス」を指すことは、何度か説明しました。

手動設定する際は、これらのアドレスの詳細構造を知っていないと、トラブルの原因になりますので留意してください。

このうち、リンクローカルユニキャストアドレスはあまり手動設定する機会はないと思いますが、
これを見たら、正しいリンクローカルユニキャストアドレスのプレフィックスは、fe80:0000:0000:0000 固定であることが判ると思います。

ユニークローカルユニキャストアドレスのLビットは、通常は1にして使用してください。
Lビットの0の指定は、現在、用途そのものが規格化されていませんが、将来的に何らかの機能を持たせることになっているようなので、つまらないトラブルの原因を作らないためにも、決められた通りにした方が無難です。

グローバルIDの部分とサブネットIDの部分はLANで管理するのであれば、任意の値が利用可能です。また、「プレフィックス長は常に /64」と記載していますが、これは一般的なLAN環境での話で、仕様としては、/8 ~ /64 の間で使用可能です。

今のところ、一般的なISPで一般的なユーザが IPv6 の接続を行うと、プレフィックス長 /64 のグローバルユニキャストアドレスなIPv6アドレスが自動的に付与されます。
これは、日本国内のフレッツ接続の場合、「半固定アドレス」でして、常時接続が継続している間はIPv6アドレス変わりませんが、何らかのきっかけで「切断 → 再接続」をしたりして通信が一度途絶えると、そのタイミングで IPv6アドレスが変わる(ことがある)という仕様です。

次の記事で、インタフェースIDの決定方法について記述します。

2018/06/07(木)IPv6の基礎(9) - 機器設定時に必要と思われる知識

前回の続き・・・
20180606_2.png
DHCPv6 によるIPアドレス取得の内部処理自体は、DHCPv4 とあまり変わりません。
ですが、DHCPv6 単体でデフォルトゲートウェイが設定出来ないのは、ちょっと・・・ という感じです。
DHCPv4 だと、デフォルトゲートウェイも取得できるのですがね。。

恐らく、ICMPv6にその機能があるから、ということなのでしょうが、ICMPv6 で設定できる項目や設定内容の自由度はあまりなく、そこを DHCPv6 でカバーしようとしても、デフォルトゲートウェイの設定がDHCPv6 単体では出来ない仕様のため、結局、DHCPv6 を使う際も ICMPv6 は不可欠。。ということになります。

2018/06/06(水)IPv6の基礎(8) - 機器設定時に必要と思われる知識

今度は、IPv6アドレスをどのように自動設定するかの仕組みの話です。
IPv6機器を設定する際、特にルータを設定する際、ここに挙げた知識が無いと設定項目の意味が理解できない場面があります。
1枚に収まりきまらなかったので、2回に分けて掲載します。
20180606_1.png


一般的なのが、上記で示すステートレス自動設定で、ICMPv6 を使って設定されます。
IPv6におけるICMPv6は、ネットワークリンクの自律的維持を行うようにある程度の特化がされている部分が、ICMPv4と異なる部分です。

図では明示していませんが、IPv6 においては、同一のLANインタフェースが、複数のIPv6アドレスを認識・所持します。
これは IPv4 とは大きく異なる部分です。

少なくとも1つのリンクローカルアドレス、1つのマルチキャストアドレス(全ノードマルチキャストアドレス=ff02::1)、1つのユニークローカルユニキャストアドレスかグローバルユニキャストアドレスの3つを同一LANインタフェースにて所持する形になります。

IPv6機器がIPアドレスを自動設定する際は、先ずサイト自体で、一定のルールに基づいたインタフェースIDを自動生成し、それをプレフィックスと合体させ、IPv6アドレス自体が他ホストと重複していないのを確認する作業が行われ、これを近隣要請(NS)・近隣広告(NA)と呼びます。

ICMPv6 によるIPv6アドレス自動設定は、リンクローカルに接続されているルータによって、接続に必要な情報が与えられることで機能します。これをルータ要請(RS)・ルータ広告(RA)と呼び、特にルータ広告は接続に必要な情報を与えることから、「RA設定」などと呼ばれています。

また、ルータ広告は定期的(10分毎に行う機器が多い)にルータがマルチキャスト(ff02::1) にて送信する仕様にされているので、ルータの設定変更に自動追従が可能なのも大きな利点です。

2018/06/05(火)IPv6の基礎(7) - 機器設定時に必要と思われる知識

いよいよ、IPv6アドレスの具体的な中身の話に入っていきます。
・ユニキャストアドレス
・エニーキャストアドレス
・マルチキャストアドレス        全てに共通する内容になります。
20180605_3.png


上記では、IPv6アドレスを扱う上で必須で知っておくべき内容を記述しています。
特に重要なのは、IPv6アドレスは前半の「プレフィックス」部と、後半の「インタフェースID」部に分かれるという点です。

「プレフィックス」は IPv4 のネットワークアドレス部に相当するもので、その長さは「プレフィックス長」で、ビット長で示します。

IPv4においても、ネットワークアドレスの長さは、CIDR と呼ばれるビット長で示されます。
これは、サブネットマスクの置き換えであり、IPv4のCIDR で /28 と表現されるときのサブネットマスクは 255.255.255.240 になり、IPv4のCIDR で /24 と表現されるときのサブネットマスクは、255.255.255.0 になります。

IPv6 では、アドレスそのものが長いため、サブネットマスクは一切使わず、CIDR の概念を踏襲した「プレフィックス長」を使うことになっています。

図では明示していませんが、上記のインタフェースID部がすべてビット0のものは、「サブネットルータエニーキャストアドレス」として認識され、上記のインタフェースID部で下位7ビット以外がすべてビット1のインタフェースIDは、「グローバルエニーキャストアドレス」として認識され(プレフィックス長が /64 の時だけ、エニーキャストアドレスの扱いが異なっている)ることになっていますので、これらのインタフェースIDは、ユニキャストアドレスとして使用することができません。

2018/06/04(月)IPv6の基礎(6) - 機器設定時に必要と思われる知識

このあたりから徐々に佳境になっていきます。
この後、IPv6を理解するために、2進数や16進数の知識が必要になってきます。
といっても、この知識がある方にとってこの項目は冗長なので、ここは読み飛ばしても差し支えありません。
20180605_2.png


今までさり気なく、IPv6アドレスを例示してきましたが、アルファベットが混じっていることにお気づきかと思います。
これは、「16進数」という情報処理系分野でごく普通に使われている数理方式で、普段我々が使う10進数の0~9の10個の数字に加えて、a ~ f のアルファベット6文字を加えて16進数としているのです。
つまり、16進数において、a ~ f は数字なのです。尚、a ~ f のアルファベットは、大文字でも構わないのですが、現在では、一般的に小文字の使用が強く推奨されています。

16進数が多用される理由は、コンピュータ(情報処理機器)との相性が良いからです。
10進数と2進数・16進数との相互変換を使う場面は、IPv6設定においては多くありません。(たまに必要になる場合があるが。。)

コンピュータは、2進数で内部処理の一切を行いますが、0と1の2つの数字しか使わない(だから2進数)ため、大きな数字を表現しようとすると、必然的に桁数が多くなります。

IPv6 アドレスを2進数で表現すると、128桁(128bit)にもなります。2進数4桁をひとまとめにすると、16進数1桁に上手く収まるので、4分の1になる上に、相互変換もやりやすくなります。

尚、一般的に「1バイト」といえば、16進数2桁,8ビットですが、そうでない場合もあるらしく、通信関係では代わりに「オクテット」がよく用いられます。
同じく、16進数2桁,8ビットが「1オクテット」です。
OK キャンセル 確認 その他