2019/01/04(金)FreeBSD 12.0 に更新する際に気づいたこと
2019/01/05 1:38
FreeBSD11 からは、５年間(2021年9月まで)のサポート期間が明言されている状態なので、
急いでメジャーバージョンアップデート対応する必要性は無いのだが、やはり動作検証・安定運用の実績は必要なので、メジャーバージョンアップデートしてみました。
FreeBSD12 は、少なくとも 2023年末までのサポートになるものと思われます。
ＯＳのメジャーバージョンアップデートは普通に出来ますが、Ports 等で導入したアプリケーションソフトウェアは、基本的に再構築をかけたほうが無難。
まず、portversion -v コマンドを実行すると、下記のようになります：
root[~][2]# portversion -v表示されたとおり、pkg-static install -f pkg を実行して対処します。
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
[Reading data from pkg(8) ... pkg: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
－ 245 packages found - done]
Fetching the ports index ... pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
pkg-static: Warning: Major OS version upgrade detected. Running "pkg-static install -f pkg" recommended
これだけでは駄目な場合があり、perl モジュール群の更新で、
encode.c: loadable library and perl binaries are mismatched (got handshake key 0xd480080, needed 0xe180080)のようなエラーが出て更新自体が出来なくなることがあります。
FreeBSD12 アップデート後にこうなった場合は、現状では、
/usr/local/lib/perl5/site_perl 配下を再構築しないと駄目です。
なので、
# cd /var/db/portsのようにして、perl とその依存モジュールを一旦削除し(ports/pakkage 導入の場合)、
# rm -rf *
# pkg delete perl5-5.26.3
# cd /usr/local/lib/perl5/site_perl
# rm -rf *
再度新規インストールし直す手順を踏む必要があります。
ここで、perl を最新バージョンへ更新する場合は、
# vi /etc/make.confとして、以下の行を追記 or 変更します；
DEFAULT_VERSIONS+=perl5=5.28尚、この手順を踏む前に、
# pkg info -r perl5-5.26.3などのようにして、インストールされている依存モジュールをメモしておき、抜けが生じないようにしましょう。
あと、perl を最新バージョンにすることは必ずしも得策とは言い切れません。
perl の最新バージョンに対応していないモジュールがあって、パッチを入れる必要があるモジュールが少なからずありますので、このあたりは自己責任で対応してください。
2019/01/02(水)FreeBSD13 になると、10BASE-T ＬＡＮのサポートは一部終了か
2019/01/02 6:04
リリースノートの「6.3. Deprecated Drivers」（『非推奨デバイスドライバ』という意味）の中でこんな内容がありました。
The following drivers have been deprecated in FreeBSD 12.0, and not present in FreeBSD 13.0: ae(4), de(4), ed(4), ep(4), ex(4), fe(4), pcn(4), sf(4), sn(4), tl(4), tx(4), txp(4), vx(4), wb(4), xe(4)要するに、FreeBSD 12 では「非推奨扱い」とし、 FreeBSD 13 で「削除する」扱いのデバイスドライバが列挙されており、大半が 10BASE-T をサポートするＬＡＮカード等。
弊社だと、ed(4) が１枚だけなので、影響は小さいですが、１～２年後に提供されるであろう FreeBSD 13 にアップデートする際に慌てないようにする上で、今から考慮しておいたほうがよさそう。
あと、FreeBSD でもサポートを打ち切る対象となるような古すぎるＬＡＮカードは捨てるしかなさそう。 いまどきの Windows あたりはとっくにサポート打ち切りとなっているので・・・
2018/08/20(月)IPv6 6to4 接続を常に優先させる
2018/08/20 6:01
ネイティブ IPv6 接続と 6to4 接続、及びローカルＬＡＮを１つのサーバに接続している（つまり、３つの回線を接続している）環境で、IPv6 接続が全く出来ない現象に遭遇しました。
どうも
〈サーバからインターネット側への接続〉→ IPv6 接続出来る場合と出来ない場合がある
〈インターネット側からサーバへの接続〉→ IPv6 接続は全く接続出来ない
〈同一ネットワーク又はＬＡＮの接続〉 → 問題ない
という現象のようです。
最初、pf のフィルタ設定に問題があるのかと思っていましたが、どうやっても現象は解消せず。
なので、インターネット側から ping6 を流し、tcpdump コマンドでチェックしてみます。
※こんな時に役立つ tcpdump コマンド・・・
すると、なんと！ 勝手にＮＧＮ回線へパケットが流れている！
ルーティング状態を見てみます....
上記で re2 と示すのがＮＧＮ回線です。これでは応答を返しても相手に届かないわけです。
何故こうなるのか。。
どうやら FreeBSD では、ＯＳが立ち上がる時、最後に認識したＬＡＮボードで取得したルーティング情報をデフォルトゲートウェイにしてしまうようです。（というか、IPv6的仕様らしい？）
こんな時のために、「ルータアドレスをデフォルトゲートウェイにしない」という指定がネットワークインターフェースに対して出来るようになっています。
具体的には下記のように /etc/rc.conf に指定します（アドレス等は伏せ字にしています）：
ipv6_default_interface="re0"２行目の、2002:c058:6301:: は、6to4 のリレールータＩＰアドレス(6to4 においては特に必要で無い限り固定)、
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"
１行目の re0 は、6to4 で接続するネットワークリンクのＬＡＮボードを示します。
５行目、 re2 の no_radr というキーワードで、「デフォルトゲートウェイにしない」を指定します。
re0 をデフォルトインターフェースに指定することで、デフォルトゲートウェイが re0 のリンクになります。
/etc/rc.conf を修正後に再起動して、再度ルーティングテーブルを確認します：
これで、〈インターネット側からサーバへの接続〉は出来るようになります。
しかし、〈サーバからインターネット側への接続〉で、デフォルトインターフェースに re2 が勝手に選ばれ、ＮＧＮ回線からインターネット接続しようとします。。
IPv6固有のアドレスポリシーテーブルを変更しないといけないようです。
デフォルトでは、このテーブルは以下のようになっています。
::1/128 50 02002::/16 の 6to4 エントリは不要です。
::/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
自ノードが使うアドレスがある場合、大抵は削除するとよいです。筆者の場合は以下のように変更しました：
::1/128 50 0*1
::/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
上記内容を /etc/ip6addrctl.conf に作成し、root ユーザにて
# ip6addrctl flushを実行することで、即座に反映します。
# ip6addrctl install /etc/ip6addrctl.conf
また、サーバ再起動時に /etc/ip6addrctl.conf を読み込むため、設定内容がその場限りで消えてしまうことはありません。
これで、〈サーバからインターネット側への接続〉も常に 6to4 が優先されるようになりました。
2018/06/25(月)6to4 回線の IPv6 逆引きを公開設定
2018/06/25 5:10
これを使うためには、
・当該サーバ等を 6to4(IPv4 回線における IPv6 トンネル接続) にて IPv6 に接続している。
・使用するIPv4アドレスは、固定ＩＰである
・設定したい 6to4 IPv6 逆引きゾーンを登録する権限がある
といった前提条件があります。ネットワーク管理者中級向けといったところでしょうか。
この設定をするには、予め該当の 6to4 で使用する IPv6 アドレスの逆引きゾーンを登録したい権威ＤＮＳに登録しておかなければなりません。
例えば 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 を当該権威ＤＮＳへ登録してから以下の申請作業を行います。
＃例示のIPv4 アドレスは、プライベートＩＰアドレス領域なので、逆引き登録は出来ません。
さて、この逆引きゾーン設定は、該当のホストマシン自身から、申請作業をＷｅｂブラウザでアクセスしなければなりません。
とはいっても、該当のホストマシン自体にＷｅｂブラウザをインストールしていない場合も多いはずです。この申請のために Chrome などわざわざインストールするのも馬鹿げています。
こんなときにさくっと役立つのが、昔から「テキストＷｅｂブラウザ」として存在する Lynx というソフトウェアです。前近代的な故、今どきのエンジニアな方々は知らないかもしれません。画像や動画、音声には対応しませんが、それ以外のコンテンツは何とか表示できます。
FreeBSD においては、 Lynx は Ports で簡単にインストールできます。(Portsツリー /usr/ports/www/lynx)
Lynx をインストールした後は、
lynx http://www.basekernel.co.jp/のようにコマンドラインでＵＲＩを指定します。筆者の環境ではこうなります。。。
何故かメニュー部分は文字化けしていませんで、o キー押下で設定画面が出ることがわかります。
ここで、o キーを押下すると。。。
フォーカス部分は色が変わるようなので、下記の青緑色部分で示す部分を変更します。
＃リターンキーや矢印キーを使います。
lynx http://www.basekernel.co.jp/とすると、今度は、
lynx https://6to4.nro.net/とアクセスします。以下のような感じになるはずです。
幾つかサーバ証明書の警告が出ますが、ｙで強制的に進みます。
どうやら IPv4 でアクセスしているようです。なので、直接IPv6アドレス指定でやってみます。
6to4.nro.net の IPv6 アドレスは、2002:ca0c:1dea::1 のようです。
＃drill コマンドでAAAA レコードを正引きしてみただけです。
一度終了させ、
lynx https://[2002:ca0c:1dea::1]/のようにすると、今度は受付する画面になりました。
Submit させます。
尚、連絡先のメールアドレスと２つの権威ＤＮＳサーバ入力は必須のようです。
受理・逆引き登録が完了すると、
同時に登録完了で以下のような電子メールが apnic より送信されます。
2018/06/11(月)IPv６の基礎(12) -トラブル対処で役立ちそうな知識
2018/06/11 1:04
これはサーバ管理者泣かせな機能なのですが、一定時間ごとにどんどんIPv6ユニキャストアドレスが新しくなっていくのです。
そうです。これは「発信元を特定しにくくする」ためのものです。
＃これも個人的には、セキュリティに過度に煩い層の影響だと思う。。
サーバ攻撃を受けた際に発信元が分かりにくくなり、原因究明に大いに影響ありそうなのです。
これを逆手にとって、ネット犯罪を助長するような一面があり、しかしながらプレフィックス部はどんなに IPv6 アドレスが変わろうが固定なので、どこまで効果があるかは疑問が残ります。
IPv6 ではリンク毎に「リンクローカルユニキャストアドレス」が付与されるという話を何度かしてきました。
早い話、ＬＡＮカード或いはイーサネットデバイスが同じ機器に複数あると、その数だけ同じ機器にリンクローカルユニキャストアドレスは割り当てられるのです。
リンクローカルユニキャストアドレスはプレフィックスが同じですので、実際に通信する際は、%で始まるインタフェース名を補助的に使用して、リンクを区別します。
2018/06/10(日)IPv６の基礎(11) - 機器設定時に必要と思われる知識・トラブル対処に向けて
2018/06/10 22:16
やみくもにＩＤを付与してもトラブルの原因になることがありますので、留意しましょう。
ユニキャストアドレスとしてインタフェースＩＤを指定する場合は、上記提示のＩＤを避けて指定しましょう。
ユニキャストアドレスとして使用できないインタフェースＩＤのうち、fdff ～ で始まるＩＤは、「修正EUI-64」形式を踏襲してインタフェースＩＤを設定する場合を想定しています。
理解の一助として、ICMPv6 などでイーサネット接続環境におけるＩＰアドレスを自動設定する際のインタフェースＩＤ自動生成方法をまとめてみました。知っておくと、トラブル対策の際に案外役立ちます。
尚、アドレス自動生成・手動設定に関係なく、必ず「修正EUI-64」形式で行う必要があるという訳ではありません。あくまでもひとつの方法として推奨されています。
ただ、この「修正EUI-64」も現在は非推奨になっているらしく(RFC7721,2016年3月)、新たにプレフィックスを基にした乱数発生による方式(RFC7217,2014年4月)が推奨されているようです。
＃セキュリティに過度に煩い層がいるものだな・・・と個人的には思ってしまいますが。。
＃この件は、次の記事で示します。
ですが、「修正EUI-64」は一般的に広く用いられており、ある日突然変更しなければならない、という状況ではありませんので、少なくともあと２～３年は定番の手法として使われ続けると見ています。
2018/06/09(土)IPv６の基礎(10) - 機器設定時に必要と思われる知識
2018/06/10 5:35
・リンクローカルユニキャストアドレス
・ユニークローカルユニキャストアドレス
・グローバルユニキャストアドレス
の３つで、単に「IPv6アドレス」と称する場合は、たいてい「グローバルユニキャストアドレス」を指すことは、何度か説明しました。
手動設定する際は、これらのアドレスの詳細構造を知っていないと、トラブルの原因になりますので留意してください。
このうち、リンクローカルユニキャストアドレスはあまり手動設定する機会はないと思いますが、
これを見たら、正しいリンクローカルユニキャストアドレスのプレフィックスは、fe80:0000:0000:0000 固定であることが判ると思います。
ユニークローカルユニキャストアドレスのＬビットは、通常は１にして使用してください。
Ｌビットの０の指定は、現在、用途そのものが規格化されていませんが、将来的に何らかの機能を持たせることになっているようなので、つまらないトラブルの原因を作らないためにも、決められた通りにした方が無難です。
グローバルＩＤの部分とサブネットＩＤの部分はＬＡＮで管理するのであれば、任意の値が利用可能です。また、「プレフィックス長は常に /64」と記載していますが、これは一般的なＬＡＮ環境での話で、仕様としては、/8 ～ /64 の間で使用可能です。
今のところ、一般的なＩＳＰで一般的なユーザが IPv6 の接続を行うと、プレフィックス長 /64 のグローバルユニキャストアドレスなIPv6アドレスが自動的に付与されます。
これは、日本国内のフレッツ接続の場合、「半固定アドレス」でして、常時接続が継続している間はIPv6アドレス変わりませんが、何らかのきっかけで「切断 → 再接続」をしたりして通信が一度途絶えると、そのタイミングで IPv6アドレスが変わる（ことがある）という仕様です。
次の記事で、インタフェースＩＤの決定方法について記述します。
2018/06/07(木)IPv６の基礎(9) - 機器設定時に必要と思われる知識
2018/06/07 1:00
ですが、DHCPv6 単体でデフォルトゲートウェイが設定出来ないのは、ちょっと・・・ という感じです。
DHCPv4 だと、デフォルトゲートウェイも取得できるのですがね。。
恐らく、ICMPv6にその機能があるから、ということなのでしょうが、ICMPv6 で設定できる項目や設定内容の自由度はあまりなく、そこを DHCPv6 でカバーしようとしても、デフォルトゲートウェイの設定がDHCPv6 単体では出来ない仕様のため、結局、DHCPv6 を使う際も ICMPv6 は不可欠。。ということになります。
2018/06/06(水)IPv６の基礎(8) - 機器設定時に必要と思われる知識
2018/06/06 19:10
IPv6機器を設定する際、特にルータを設定する際、ここに挙げた知識が無いと設定項目の意味が理解できない場面があります。
１枚に収まりきまらなかったので、２回に分けて掲載します。
一般的なのが、上記で示すステートレス自動設定で、ICMPv6 を使って設定されます。
IPv6におけるICMPv6は、ネットワークリンクの自律的維持を行うようにある程度の特化がされている部分が、ICMPv4と異なる部分です。
図では明示していませんが、IPv6 においては、同一のＬＡＮインタフェースが、複数のIPv6アドレスを認識・所持します。
これは IPv4 とは大きく異なる部分です。
少なくとも１つのリンクローカルアドレス、１つのマルチキャストアドレス(全ノードマルチキャストアドレス＝ff02::1)、１つのユニークローカルユニキャストアドレスかグローバルユニキャストアドレスの３つを同一ＬＡＮインタフェースにて所持する形になります。
IPv6機器がＩＰアドレスを自動設定する際は、先ずサイト自体で、一定のルールに基づいたインタフェースＩＤを自動生成し、それをプレフィックスと合体させ、IPv6アドレス自体が他ホストと重複していないのを確認する作業が行われ、これを近隣要請(NS)・近隣広告(NA)と呼びます。
ICMPv6 によるIPv6アドレス自動設定は、リンクローカルに接続されているルータによって、接続に必要な情報が与えられることで機能します。これをルータ要請(RS)・ルータ広告(RA)と呼び、特にルータ広告は接続に必要な情報を与えることから、「ＲＡ設定」などと呼ばれています。
また、ルータ広告は定期的(10分毎に行う機器が多い)にルータがマルチキャスト(ff02::1) にて送信する仕様にされているので、ルータの設定変更に自動追従が可能なのも大きな利点です。
2018/06/05(火)IPv６の基礎(7) - 機器設定時に必要と思われる知識
2018/06/06 18:42
・ユニキャストアドレス
・エニーキャストアドレス
・マルチキャストアドレス 全てに共通する内容になります。
上記では、IPv6アドレスを扱う上で必須で知っておくべき内容を記述しています。
特に重要なのは、IPv6アドレスは前半の「プレフィックス」部と、後半の「インタフェースＩＤ」部に分かれるという点です。
「プレフィックス」は IPv4 のネットワークアドレス部に相当するもので、その長さは「プレフィックス長」で、ビット長で示します。
IPv4においても、ネットワークアドレスの長さは、CIDR と呼ばれるビット長で示されます。
これは、サブネットマスクの置き換えであり、IPv4のCIDR で /28 と表現されるときのサブネットマスクは 255.255.255.240 になり、IPv4のCIDR で /24 と表現されるときのサブネットマスクは、255.255.255.0 になります。
IPv6 では、アドレスそのものが長いため、サブネットマスクは一切使わず、CIDR の概念を踏襲した「プレフィックス長」を使うことになっています。
図では明示していませんが、上記のインタフェースＩＤ部がすべてビット０のものは、「サブネットルータエニーキャストアドレス」として認識され、上記のインタフェースＩＤ部で下位７ビット以外がすべてビット１のインタフェースＩＤは、「グローバルエニーキャストアドレス」として認識され(プレフィックス長が /64 の時だけ、エニーキャストアドレスの扱いが異なっている）ることになっていますので、これらのインタフェースＩＤは、ユニキャストアドレスとして使用することができません。