7月 272017
 

ちょっと前のエントリで FreeBSD のポリシールーティングについて書きました。そのときは FreeBSD においては pf で設定しました。そして、他のやり方がないのか検討し、その記事の下のほうには setfib コマンドでルーティングテーブルを操作して正しいルーティングができるのか試しているのですが、結局はダメだったのであります。

Linux 方面では ip route+ip rule でのポリシールーティングの運用となりますが、カーネルのバージョン 4.4 から VRF が利用できる。というので setfib と比較してどれくらい効果的に機能するのか試してみました。
Linux カーネルが 4.4 以上なディストリビューションには何があるのか調べてみると ubuntu-17.04 が対応しているようなので ISO イメージをダウンロードしてインストールし、実際に設定までしてみます。

 
僕自身 ubuntu はあまり使ったことが無いディストリビューションで Raspberry Pi の Volumio に続き二個目のインストール環境です。仕事でもデスクトップでも使ったことがありません;-)。

それにしても ubuntu のネットワーク設定である /etc/network/interfaces の記述方法が相変わらず解らないので、いつものように /etc/rc.local でやってしまえ。などと思っても ubuntu にはこのファイルが無いし、起動時に利用できないのですねぇ。

以下の URL を参照させて頂き /etc/rc.local を動くようにしました;-)。

http://qiita.com/msrks/items/5201ae15d0e1f8de5946

簡単に書いておくと

o. /etc/systemd/system/rc-local.service を作成

[Unit]
Description=/etc/rc.local compatibility

[Service]
Type=oneshot
ExecStart=/etc/rc.local
# disable timeout logic
TimeoutSec=0
#StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target

 
o. enable する

systemctl enable rc-local.service

 
これで /etc/network/interfaces と /etc/rc.local にコマンドを書いて、起動時に実行されるようになりました。

と、いうことで、以降は VRF を利用するネットワークの設定を行います。

 
まず、ネットワーク構成ですが、この前のエントリ「FreeBSD でポリシールーティング。」で書いた CentOS 6.9 を ubuntu-17.04 にリプレイスして ip route+ip rule をやめて VRF を利用してみます。

Server1 が Linux (CentOS 6.9) だったので、これを設定します。以下はネットワークの情報です。

・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.10
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::2:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.10
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::2:1

これを VRF を利用するように設定します。が、その前に注意点を。

NIC が二個あるのでそれぞれの NIC を VRF にしてルーティングテーブルを二つ別々に持たせよう。などと思ってはいけません。
NIC が二個の場合、一個は default のルーティングテーブル(ip [-6] route list で表示されるルーティングテーブル)を参照するようにして、もう一個の NIC は別のルーティングテーブルを持ち、かつ参照する構成が良いです。ここ、ハマリ道というか思い違いの点ですね。
この点については下のほうに詳しく書きます。

 
では、設定を上から順に見ていきます。

0). /etc/network/interfaces にネットワークの設定のみ書く
lo の他にインターフェース二つ分を書き gateway の設定は書かない

auto ens160
iface ens160 inet static
address 192.168.22.10
netmask 255.255.255.0
iface ens160 inet6 static
address 2001:470:fe36:beef::2:1
netmask 64

auto ens32
iface ens32 inet static
address 192.168.1.10
netmask 255.255.255.0
iface ens32 inet6 static
address 3ffe:6580:aa40::2:1
netmask 64

 
多分、/etc/resolv.conf が作られないので、以下のコマンドを /etc/rc.local に書いておくと良いかもしれんです。

cp -pr /etc/resolv.conf.SV /etc/resolv.conf

 
/etc/resolv.conf.SV は好きに書いてください;-)。
しかし、ディストリビューションの正しい設定方法を無視しているなぁ;-P。

 
1). IP アドレスの付加
僕の場合、/etc/network/interfaces に書いた IPv6 アドレスが自動的に付加されなかったので /etc/rc.local に書きました。
以降の設定は全て /etc/rc.local に書くと楽ちんです;-)。

ip addr add dev ens160 2001:470:fe36:beef::2:1/64
ip addr add dev ens32 3ffe:6580:aa40::2:1/64

 

2).ルーティング情報の付加
今回は Server-Zone 側を default のルーティングテーブルとして利用します。

route add default gw 192.168.22.1
route add -A inet6 default gw 2001:470:fe36:beef::1

 

3). VRF の設定
いよいよ、VRF の設定です。VRF は LAN-Zone 側に設定します。
ip [-6] route list コマンドで表示される default gateway は上でコマンドを打っています。 グローバル側の設定ですね。
VRF はマネージメントポート側で利用する。と、いう意味合いを込めて Cisco 風に mgmt という名にします;-)。

ip link add dev mgmt type vrf table 10
ip link set dev mgmt up

 
type は vrf で table 番号は 10 を利用しました。複数個の VRF を生成する場合はこの番号を増やしていけば良いです。

 
4). VRF と NIC の結びつけ
作成した VRF インターフェースと NIC を結びつけます。つまりは、マネージメントポート用の VRF は mgmt として LAN-Zone の NIC と結びつける。と、いうことですね。

ip link set dev ens32  master mgmt up

 
リモートから ssh で作業していて dev で指定する NIC からアクセスしていた場合、このコマンドを投入した段階でネットワークが切れます。なので反対側の NIC からアクセスして作業するか、コンソールからコマンドを叩く必要があります。
起動時の /etc/rc.local 読み込み時には問題はないんですけどね。

 
5). VRF に default gateway を設定
Server-Zone は default のルーティングテーブルを参照しますが、 LAN-Zone は個別の VRF のルーティングテーブルを参照します。なので別途 default gateway を設定します。 VRF の table 10 に対して route add します。

ip route add default via 192.168.1.103 table 10
ip route add default via 2405:6580:aa40::fffe table 10

 

6). 外部からのアクセスを可能にする
最後に sysctl で以下の MIB 値を変更し、外部から VRF 側のネットワークアクセスを可能にします。これをしないと ssh などで接続することができません。

sysctl -w net.ipv4.tcp_l3mdev_accept=1

 
以上で VRF の設定は完了です。

 
確認方法は以下になります。

  • ip route list もしくは ip -6 route list
    default のルーティングテーブルを確認すときに利用
  • ip route list vrf mgmt もしくは ip -6 route list vrf mgmt
    設定した VRF の mgmt のルーティングテーブルを確認

その他、インターフェースの確認として ip link や ip addr を利用します。

 
さて。最初のほうで『二個の NIC に VRF を二個用意してはいけません。』と書いていますが、例えば二個の NIC それぞれで VRF を利用した場合 /etc/resolv.conf を参照しないなど、問題点も多いです。
そりゃそうでしょうなぁ。どっちの NIC から出ていくかわからないですし、リゾルバは正しく動作してくれないんでしょうな。

例えば NIC が ens160 と ens32 の二つがあった場合以下のコマンドを打ったとします。

ip link set dev ens160 master vrf0
ip link set dev ens32  master vrf1

 
この場合、二つの NIC でそれぞれ個別のルーティングテーブルを持つことになるんですが、

  • ping -I vrf0 IP アドレス もしくは ping -I vrf1 IP アドレス

では到達性があります。しかし、以下のように pingすると到達性がありません。

  • ping -I vrf1 FQDN

ルーティングテーブルが VRF のみになると DNS を引きに行ってくれないんですね。なので、 NIC が二個の場合は一個の VRF を設定するのみで、もう一個の NIC は default な ip [-6] route list で表示してくれる経路が必要になります。

二個の NIC で二個の VRF を設定すると netstat -nr や ip route list では何も表示してくれなくなります。

ループバックに IP アドレスとか記載できるのかな? lo:1 とか書けるのかな?そこまで試していませんが。

 
さてと。ここまで来て VPF の環境設定が終わりましたが、実際に利用してみるとやはり中々楽しいですね。
Cisco ルータの場合、 VRF は interface mgmt で動作することが多々あるんですが、今回は L3 ルータを作る。と、いう目的ではなく、サーバのポリシールーティングのかわりに VRF を利用してみた。と、いう感じですね。

ip [-6] route list で表示されるルーティングテーブルは、サービス側で利用し、マネジメントポート (今回はそれを LAN-Zone と呼んでます) で VRF を利用し、サービスセグメントのルーティング情報とは混在させないで通信を行う。こんな時に必要な機能だと思われます。

 
僕はこのあと VRF を利用しつつ、ウェブサーバを起動して CentOS 6.9 を引退させようと考えています;-)。

FreeBSD の setfib もここまで動いてくれると嬉しいのですが、そこまで到達していないのと、そもそも setfib は IPv6 が動かないので、今の所、僕の環境ではまるで使い道が無い・・。orz

7月 222017
 

一台の PC で IPv6 が使えている状況で、他の PC にも IPv6 がほしいなぁ。と、いうことが、最近、多々あります。
NIC やスイッチのポートが限られていて他の PC を同一セグメントに接続できないじゃーん。みたいな・・。

と、いうことで構成図を一枚。

・緑色のルータは FreeBSD のルータで PC1 と gif トンネルで接続しています。

今までは PC1 で IPv6 を使えれば良かったんだけど、PC2 や PC3 でも IPv6 を利用したい。ぱっと思い浮かぶのが PC2 や PC3 でも個別に gif トンネル掘って緑色のルータと接続すれば良いしゃん。と、いう案です。

他にないの?というと、例えば

PC1 の gif0 と em1 を bridge にして PC2 と PC3 を接続して 2001:470:fe36:11::/64 のセグメントを利用できるようにしてあげる。

って案ですね。が、しかし、 FreeBSD では (if_gif を利用すると?) bridge がまともに動かないですなぁ・・。
と、いうか、最近まで知らなかったのですが、bridge するインターフェースは MTU を揃えないとエラーになるんですね。

# ifconfig em0 mtu 1500 up
# ifconfig gif0 mtu 1280 up
# ifconfig bridge0 create
# ifconfig bridge0 addm gif0 addm em0  up
ifconfig: BRDGADD em0: Invalid argument
# ifconfig bridge0 destroy
# ifconfig em0 mtu 1280 up
# ifconfig bridge0 addm gif0 addm em0  up

 
上記のエラーが出たときにどうして Invalid argument なのか /var/log/messages にメッセージが出力されますね。知らんかった・・。

 
とまぁ、仮に無事に bridge0 が生成されたとしても IPv6 の通信ができないので諦めました。 bridge0 に addm gif0 した段階で通信が途絶えます。 ifconfig bridge0 destroy すると復活します。原因はどこにあるのだろう?

 
以前、 VyOS を二台用意して IPv4 の別セグメントに IPv6 を L2 抜けする設定を一回掲載していますが、そんな大げさなネットワークを構築するのはイヤです;-)。

まぁ、今回は PC1 から PC3 までが同一セグメントに入っている必要はなく、とりあえず三台の PC が IPv6 で外部にアクセスできると嬉しいなぁ。と、いう感じなので、何かワザはないのか?と思い、考えたら『あぁ。NAT すりしゃ良いじゃん。』となったのであります。

 
と、いうことで IPv6 で NAT を有効にするにはどうしたら良いのだぁ? 調べてみると NAT66 という技術を利用するようですね。 IPv6 で IPv6 の NAT をするので NAT66。

と、いうことで前回同様、今回も pf を利用します。

今回は上の構成図に合わせると PC1 で pf を利用して NAT66 が動作するようにします。 PC1 の pf で設定は以下のような感じ。

nat on gif0 inet6 from 2001:470:fe36:100::/64 to any -> 2001:470:fe36:11::2

 
一行でできました;-)。これを /etc/pf.conf に書けば完了。

PC2 と PC3 は NAT のアドレスなので fd00::/8 のユニークローカル IPv6 ユニキャストアドレスを /64 で任意のセグメントを定義して利用しても問題は無いです。
僕の場合は 2001:470:fe36::/48 を持っているのでその中から NAT 用に 2001:470:fe36:100::/64 を切り出て利用しました。

NAT で利用する 2001:470:fe36:100::/64 は gif0 に付加されている 2001:470:fe36:11::2/64 を抜けて通信するので pf でその設定をしてあげると上のようになります。

簡単ですね。あとは service pf onestart して sudo pfctl -sa で確認すれば良いと思われます。

PC2 と PC3 はスタティックに IPv6 を ifconfig で設定してあげてください。PC1 で rtadvd の設定するの面倒なのでf(^^;;。

PC2 と PC3 では default gateway を指定する必要があるので、そのために PC1 の em1 に IPv6 アドレスを付加してあげる必要があります。

# ifconfig em1 inet6 2001:470:fe36:100::1 alias

 
PC2 と PC3 はこの IPv6 アドレスを default gateway に指定してあげます。

 
ちなみに 緑色のルータと PC1 の gif トンネルの説明はないですが、大丈夫ですよね? 以前のエントリで「IPv6 Over IPv4 トンネルを dtcp から VyOSへ。」と、いうのを書いているのですが、「2. dtcpclient 側の設定」の設定をサーバ側・クライアント側として逆に打つとトンネルを掘ってくれます。

 
と、いうことで、今回は NAT66 の設定を pf で行い、簡単に IPv6 を利用する方法を書きましたが、IPv6 が欲しい場合には比較的容易に gif トンネル + NAT66 っていうのが良いかもしれないです。

グローバルアドレスが付いている FreeBSD があれば、網内のどこにでもある FreeBSD から gif トンネル掘って、その下で NAT66 すれば良いだけですねぇ。

簡単だぁ;-)。

7月 182017
 

最近 Asahi-Net で PoE じゃなかった。 IPoE で IPv6 が利用可能になった。僕は他にも hi.net で IPv6 を /48 ほど借りているので二つのセグメントが利用可能なのであります。贅沢だぁ;-)。

と、いうことで自宅のネットワーク環境を見直してみました。

IPv4/IPv6 のセグメントをそれぞれ表側・裏側と二つ用意したんですね。

構成図はこんな感じ。 (多少、端折っているf(^^;;)

Server-Zone と LAN-Zone があり、管理用 PC2 は両方のセグメントに到達性があるわけなんですが、実際に運用してみると非常に厄介。

例えば管理用 PC2 には LAN-Zone の 192.168.1.100 が、 Server-Zone には 192.168.22.100 が付加されているとして Server1 の Server-Zone 側の IPv4 に ping を打つと元リは LAN-Zone 側から戻ってきてしまう。ぐるっと回ってしまうんですね。

パケットの流れ的には以下のような感じ。PC2 のソースアドレスは 192.168.1.100 で出て行きます。

管理用PC2 の NIC1 -> Server2 の Server-Zone -> Server2 の LAN-Zone -> 管理用 PC2 の NIC2

ぐるっと一周の旅です。これがグローバルアドレスだと、ISP 側では『自分の管理してないアドレスからバケットが届いた。』ということで破棄されます。

あぁ・・。サーバにポリシールーティングの設定入れないと・・。 orz

FreeBSD の場合、 ipfw の fwd でも pf でも、バケットが届いた NIC から出ていく。って設定ができないんですね。
パケットが届いた NIC のゲートウェイアドレスに返す。って設定はできるようなんですけど、その場合はゲートウェイ経由で届いたパケットは送信元に戻っていくけど、同一セグメント上のコネクテッドな送信元には戻っていかない。まいったなぁ・・。

 
上記の構成図のうち Server1 が Linux (CentOS 6.9) の場合、以下のように /etc/rc.local に書くと良いです。

ip route add 192.168.22.0/24         dev eth0 tab 100
ip route add 2001:470:fe36:beef::/64 dev eth0 tab 110
ip route add 192.168.1.0/24          dev eth1 tab 120
ip route add 3ffe:6580:aa40::/64     dev eth1 tab 130

ip route add default via 192.168.22.1           dev eth0 tab 100
ip route add default via 2001:470:fe36:beef::1  dev eth0 tab 110
ip route add default via 192.168.1.1            dev eth1 tab 120
ip route add default via 3ffe:6580:aa40::ffff:1 dev eth1 tab 130

ip    rule add from 192.168.22.10/32           tab 100 priority 1000
ip -6 rule add from 2001:470:fe36:beef::2:1/64 tab 110 priority 1100
ip    rule add from 192.168.1.10/32            tab 120 priority 1200
ip -6 rule add from 3ffe:6580:aa40::2:1/64     tab 130 priority 1300
ip route flush cache

 
・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.10
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::2:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.10
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::2:1

route add と rule add を利用してポリシールーティングしてあげるとサクっと動作します。

最近の Linux のシステム管理者は default Gateway の設定はせず、ほとんど上記のようなポリシールーティングで設定を行い、セキュリティを強化しているようですねぇ。

 
FreeBSD の場合 ipfw の fwd では無理でした・・。僕にその知識が無いのかもしれないです・・。
なので、ファイアーウォールは ipfw だけど、ポリシールーティングの設定は pf でやるとこにしました。
以下が pf の設定です。 Server2 のは FreeBSD/amd64 10.3-RELEASE です。
/etc/pf.conf に記載します。記載したあとは service pf onestart したあとに pfctl -sa で確認できます。

pass quick on lo0  all
pass quick on vmx0 all
pass quick on em0  all
#
# NIC vmx0 -> vmx0 (IPv4)
pass out quick on vmx0 from 192.168.22.20 to 192.168.22.1/24
pass in quick on vmx0 reply-to (vmx0 192.168.22.1) from any to 192.168.22.20
pass out on vmx0 route-to vmx0 from 192.168.22.20 to any
#pass  out on vmx0 route-to (vmx0 192.168.22.1) from 192.168.22.20 to any
# NIC vmx0 -> vmx0 (IPv6)
pass out quick on vmx0 from 2001:470:fe36:beef::3:1 to 2001:470:fe36:beef::1/64
pass in quick on vmx0 reply-to (vmx0 2001:470:fe36:beef::1) from any to 2001:470:fe36:beef::3:1
#pass out on vmx0 route-to vmx0 from 2001:470:fe36:beef::3:1 to any
pass out on vmx0 route-to (vmx0 2001:470:fe36:beef::1) from 2001:470:fe36:beef::3:1 to any
#
# NIC em0 -> em0 (IPv4)
pass out quick on em0 from 192.168.1.20 to 192.168.1.1/24
pass in quick on em0 reply-to (em0 192.168.1.1) from any to 192.168.1.20
pass out on em0 route-to em0 from 192.168.1.20 to any
#pass out on em0 route-to (em0 192.168.1.1) from 192.168.1.20 to any
# NIC em0 -> em0 (IPv6)
pass out quick on em0 from 3ffe:6580:aa40::3:1 to 3ffe:6580:aa40::ffff:1/64
pass in quick on em0 reply-to (em0 3ffe:6580:aa40::/64) from any to 3ffe:6580:aa40::3:1
pass out on em0 route-to em0 from 3ffe:6580:aa40::3:1 to any
#pass out on em0 route-to (em0 3ffe:6580:aa40::ffff:1) from 3ffe:6580:aa40::3:1 to any

 
・Server-Zone の IPv4 Gateway: 192.168.22.1
・Server-Zone のサーバ IPv4 アドレス: 192.168.22.20
・Server-Zone の IPv6 Gateway: 2001:470:fe36:beef::1
・Server-Zone のサーバ IPv6 アドレス: 2001:470:fe36:beef::3:1
・LAN-Zone の IPv4 Gateway: 192.168.1.1
・LAN-Zone のサーバ IPv4 アドレス: 192.168.1.20
・LAN-Zone の IPv6 Gateway: 3ffe:6580:aa40::ffff:1
・LAN-Zone のサーバ IPv6 アドレス: 3ffe:6580:aa40::3:1

これで FreeBSD の場合は IPv4/IPv6 共にパケットが届いた NIC と出ていく NIC が一緒になるかと思います。グルっと回って反対側の NIC から出ていくことはなくなります。

僕は pf についていまいち解ってないのですが、 pass out on vmx0 route-to のオプションで (NIC Gateway) の設定があるのですが、この場合は vmx0 の 192.168.22.1 なゲートウェイアドレスに転送するよ。って設定ぽいですね。その場合、同一セグメント上の送信元、俗に言う、コネクテッドなホストには届かないんでないの? って気がするので (NIC Gateway) の記述ではなく () をはずして NIC のみを記載しています。

1).コネクテッドなホストと通信ができて、ゲートウェイの先のホストと通信ができない設定

pass out on em0 route-to em0 from 192.168.1.10 to any
pass out on em0 route-to em0 from 2405:6580:aa40::2:1 to any

 

2).ゲートウェイの先のホストと通信ができて、コネクテッドなホストと通信ができない設定

pass out on em0 route-to (em0 192.168.1.1) from 192.168.1.10 to any
pass out on em0 route-to (em0 3ffe:6580:aa40::ffff:1) from 3ffe:6580:aa40::2:1 to any

 
IPv4 の LAN-Zone なアドレスは外と通信することが無いので 1). の設定で十分な気がします。
IPv6 アドレスの場合、LAN-Zone は守りたいので 1). のほうが良いかな。

こーいうのを意識せずに、ゲートウェイの先のホストとコネクテッドなホストの両方と通信できる設定ってできるのかしら? その点 Linux は良い感じに動作していると思うんですけども。

ポリシールーティングの設定の場合、入ってきた NIC の先の Gateway に返す。ってのはウェブでまぁ、ほどほど見かけるのですが、僕から言わせてもらうと『入って来た NIC から出ていってくれてるだけで良いよ。』ってのが素直な感想なのだけど、そーは行かないのかな?

 
設定が完了したら pfctl -sa してみたり tcpdump -i vmx0 で確認してみると、パケットは入って来たポートから出ていくし、コネクテッドなホストとも無事に通信ができています。まぁ、この設定でヨシとしておきましょう。

 
あと、今回の検証のために FreeBSD の VRF の技術でもある setfib を試しましたが IPv6 が使えないのね・・。

そして、fib ごとにルーティングテーブルが個別になると思うんだけど、どうして別の fib のルーティング情報も見えるんだろう? fib はインターフェースとリンクしなくて良いのかな? 不思議だ・・。

$ setfib 0 netstat -nr -f inet
Routing tables
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.1.33       link#3             UHS         lo0
192.168.22.0/24    link#2             U           ue0
192.168.22.33      link#2             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.22.0/24    link#2             U           ue0

 
(fib: 0) 側に 192.168.1.0/24 のルーティング情報が乗っていたら意味ないし、 (fib: 1) に 192.168.22.0/24 の情報があったら、ダメなような気がするんだけど・・。 ue0 から入ってきたパケットは wlan0 に抜けていってしまうと思われる・・。
setfib って、二つ (fib の数だけ) のルーティングテーブルを持つことができる。って機能ではないのかしら?

 
ルーティングテーブルがこんな具合になってくれていると多分 pf によるポリシールーティングは必要ないのではないか。と思われます。

$ setfib 0 netstat -nr -f inet
Routing tables (fib: 0)
Destination        Gateway            Flags     Netif Expire
default            192.168.22.1       UGS         ue0
127.0.0.1          link#1             UH          lo0
192.168.22.0/24    link#2             U           ue0
192.168.22.33      link#3             UHS         lo0

$ setfib 1 netstat -nr -f inet
Routing tables (fib: 1)
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#1             UH          lo0
192.168.1.0/24     link#2             U         wlan0
192.168.1.33       link#3             UHS         lo0

 

7月 132017
 

systemctl ってのは Linux の新しいシステムの systemd 由来のコマンドですね(この辺りの言い回し、正しくないかも;-)。
つい最近になって CentOS7 を利用し始めたので /etc/init.d/hoge restart とかできなくなって驚いていたんですけども。

じゃぁ、/etc/init.d/ の下にあったのはどこに行ったのだ? と思い調べてみると /usr/lib/systemd/system/*.service というのがそのようですね。このファイルを利用して systemctl が start/stop をやってくれる。と、いうことのようです。

Linux のシェルは基本的に bash なので以下のファイルをダウンロードしてきて /etc/bash_completion.d/ の中に入れてあげると TAB キーで補完してくれるので幸せになれるようです。 bash 用の systemctl 補完用スクリプトですね。

https://raw.githubusercontent.com/terralinux/systemd/master/src/systemctl-bash-completion.sh

では、普段から tcsh を利用している人 (それはつまりは Linux が流行る前から UNIX をいじっていた人。と、いうことになるのかや?;-) や Linux でも tcsh をメインで利用している人はどうしたらえーねん? て、ことになるのですが、せっかくなので ~/.tcshrc に以下の設定を書いてみましょう。 (ウェブ上では多分切れているね・・orz。フル HD の全画面で表示してぇ・・。)

complete systemctl 'p/1/(start stop restart status reload enable disable kill ..etc..)/' 'n@*@`/bin/ls /usr/lib/systemd/system | grep service | sed -e "/:/d"`@'

 
tcsh には complete というコマンド(?)があるので、それで TAB の補完の設定ができます。

上記を ~/.tcshrc に書いて systemctl と打ったあと TAB を打つとまず start/stop などの文字列が表示され、その後 *.service をドドドと表示してくれることでしょう。途中の sshd.s で TAB キーを押しても補完してくれます。

これで tcsh をメインのシェルとして利用している人は幸せになれるのではないかと思われます;-)。

 
ところで、 FreeBSD の service も似たように TAB で表示したい。と、いう場合はどうするのか? 以下の設定をやはり ~/.tcshrc もしくは /root/.cshrc に書くと幸せになれます。

complete service 'n@*@`/bin/ls /etc/rc.d /usr/local/etc/rc.d | sed -e "/:/d"`@' 'p/2/(start stop restart onestart onestop onerestart)/'

 
FreeBSD の起動スクリプトは /etc/rc.d/ や /usr/local/etc/rc.d/ の中に入っているのでその中をごっそりと ls している。と、いうことになります。

bash の場合は専用のスクリプトを用意したりしますが tcsh の場合は強引に /bin/ls で実装している。と、いうことですなぁ。

 
tcsh が好きで好きで手放せない。もしくは bash なんて使ってらんねーぜ。けっ。はたまた zsh なんて遅くて使い物にならん。と、いう方は今後も多分ずっと tcsh を使い続けるかと思いますが、その場合 systemctl や service で TAB キーを使いたい方は是非お試しください;-)。
また、他のコマンドでも TAB を利用して補完したい場合には complete コマンド(?)で定義することができます。

 
2017/07/27 加筆
もう 20 年くらい tcsh 使っているけど、 tcsh を利用するときに complete な一覧が書かれているファイルがあるのね。知らなんだぁ。

o. FreeBSD の場合
/usr/share/examples/tcsh/complete.tcsh
/usr/src/contrib/tcsh/complete.tcsh

o. ubuntu の場合
/etc/complete.tcsh

これを ~/.tcshrc の中で source /usr/share/examples/tcsh/complete.tcsh とかすると色々なコマンドで TAB で補完してくれるので幸せになれます。
僕のは場合は mv cp ln など、二個目のパラメータを TAB キーで抽出できなかったので、一部変更して $HOME に置きました。

ubuntu の人が作ってくれたファイルのようです。感謝。 m(_ _)m。
加筆ここまで

7月 112017
 

僕は現在 SoftBank の回線で iPhone6 を使い続けていますが、 R-SIM10+ という SIM ロックのかかった iPhone を SIM フリーにしてくれる。と、いう、以前から評判になっていた SIM ゲタを購入してみました。
バルク品ですが、980yen だったので試してみた。と、いう感じですが;-)。

届いたのはこんな感じです。本当にバルクだぁ。パチモンではないのかな? とは思いつつ、購入したのは APM ショップ というところだったので、多分問題ないだろう。と、言う気持ちはありました;-)。

iPhone6 はまだ Softbank の SIM で動作しているので iPhone5 で試してみました。利用したのは DTI SIM。ちなみに現在 iPhone5 は奥さんが利用しております。

奥さんのネットワーク環境は、以前に僕が購入した(その後、詐取された) ZTE Blade Vec 4G に DTI SIM を入れて Wi-Fi ルータ化し iPhone5 でテザリングしている。と、いう状態です。ちなみに、彼女は Softbank のフィーチャーフォンも持っているので、都合三台持ち。と、いうことですね;-)。まぁ、僕がそのように仕向けている。とも言うんですがf(^^;;。

と、いうこと、でわざわざ iPhone5 に R-SIM10+ を使う必要は全くないんだけど、僕が試したくなってしまった。と、いうのが実情ですf(^^;;。

 
さてと。まずは iPhone5 に DTI SIM のプロファイルをダウンロードしてインストールするところから始めます。そして、早速 R-SIM10+ を試してみました。
上記 APN ショップの URL の手順に従い LTE の電波をオフにしたところで電源を入れつつ SIM カード共々接続します。
[JP SoftBank] -> [TMSI1.2G3G4G] -> [M2(IOS8-IOS9)] と、メニューに沿って進んでいきます。

3G の電波は比較的容易に拾いました。そして、通信も無事にできましたが、遅いですねぇ・・。

でもっていよいよ LTE をオンにするのですが、あたたた。いきなり圏外病の発生です。これが俗に言う圏外病というモノなのね。ということで docomo 謹製の MEDIAS LTE N-04D で復活させようとしたのだけど、ダメ。やり方が間違っていたのかな?
しょーがないので iPhone5 の LTE をオフにして SIM カードのみを抜き差ししていたら、あぁら。無事に復活。単なる偶然か? しかし、調べてみると iPhone 単体でも復活した。と、いう話はウェブ上で見受けられるし。

その後、再度 iPhone5 に DTI SIM && R-SIM10+ を指したら LTE を拾って通信ができるようになったのでヨシとしました。

購入した R-SIM10+ はバルクだったのですが、実際に LTE 接続して動作したので『一応問題なく動作した。』と、いうことになるのでホッとしております;-)。

 
次の日、奥さんに一日持ち歩いてもらいフィールドテストを実施してもらいました。ろくに詳しいことも説明せずに;-)。しかし、 16:00 頃メールが来て『使えないんだけど。圏外になっているんだけど。』と、いうことでシューリョー・・。

家に帰って色々情報を聞くも『使えないと意味がないので、今のまま二台持ちでも全然問題は無い。』と、いう、そっけない意見が出たので、結局 R-SIM10+ を利用したのは一日だけだったのであります・・。 orz
まぁ、確かにそのとおりではある。

 
なお、二回目の圏外病になった DTI SIM ですが iPhone5 単体で試したけど、やっぱりダメで SIM フリースマホである ZTE Blade Vec 4G の LTE をオフにして試してみたらいとも簡単に復活しました。圏外病を復活させるためには docomo のガラケーが必要だ。と、言われているようですが、 docomo の電波を拾う SIM フリーなスマートフォンでも LTE をオフにしていると大丈夫みたいですね。

ZTE Blade Vec 4G が特別なだけかもしれないですが。

 
と、いうことで、まぁ、ほぼ検証のためだけに購入した。と、言っても過言ではない R-SIM10+ ですが、わずか一日の短命に終わったのでありました・・。

圏外病の復活方法がわかっただけでもヨシとすべきか・・。

7月 082017
 

ハイレゾ楽曲を聴くために SONY Xperia Z5 Compact E5823 購入したのですが、こいつは SIM アンロック済みのワールドワイド版です。 SONY は早々と Android7 にバージョンアップする。と、アナウンスがあったのですが、キャリア向けのバージョンアップは確か、随分前にありました。僕の持っているヤツはようやっと Android7 が降ってきました。

ここまでは前回書いた Android7 が降ってきた。のエントリと一緒です。

僕が持っている香港版の Xperia Z5 Compact E5823 に Android7 が降ってきたのは 2017/05/25 頃。 UK 版より三ヶ月ほど遅かったのですが、スルスルっと Android7.1.1 が振ってきました。今回は早かった;-)。

早速バージョンアップしました。特に問題も無く 30 分くらいで完了しました。

前回の Android6 から 7 にバージョンアップしたときよりも見た目の変化が少ないように感じるので、ほぼバグフィックスとかセキュリティーホールすぶしのバージョンアップなのでしょうなぁ。

無事に終わったあとのバージョンはこんな感じ。購入してからそろそろ一年が経つのですが、ズイズイとバージョンアップしてくれる SONY には感謝感謝です。やはりちゃんとしたメーカの Android 端末を買わないとダメだよなぁ。と痛感します;-)。

 
さてと。話はこれで終わったら面白くないし、前回のエントリではわざわざ Bluetooth イヤホンのお話を書いたので、それに関連するお話をちょっと書いてみます。

前のエントリにも書いた通り、僕の Xperia Z5 Compact E5823 には 64GB の MicroSD カードに 55GB 分、曲数にすると 280 曲程度入っています。なのにハイレゾ対応イヤホンではなく Bluetooth イヤホンで楽曲を聞いていたので、その恩恵が全く受けられていませんでした。

そんなこんなで久しぶりに『ケーブルが邪魔だけどね。』などと思いつつ SoftBank SELECTION SE-5000HR でハイレゾ楽曲を聞いたのですが。あれ?! 音がずいぶん良くなってない?

まぁ、今まで三ヶ月くらいほぼ毎日 Bluetooth イヤホンで通勤時に楽曲を聞いていたのを突然ハイレゾ対応イヤホンに変えたら、そりゃー音の違いが解って当然だよなぁ。などと思うのですが、ふつー、10 分程度聞いていると耳が慣れてしまうのに、今回はそんなことはなく、いつまで経っても良い音のまま耳に入って来るのであります。

ドンドン来ていないのに重低音がしっかり響き、高音は『あれ?こんな音してた?』って思えるほど聞こえるし、音の広がりがすごいし。人が聞こえない周波数まで音の広がりがある。と、いうより量子化ビット数分ちゃんと厚みのある(情報量のある)音になっている。ような気がするのであります。

 
何を言いたいのか?というと、 Android のバージョンアップでハイレゾ関連の音質良くなったりしてない? などと思った次第です。

Andoid6 -> 7 にバージョンアップしたときに音が良くなったかな?とも思えるのですが 7 -> 7.11 にバージョンアップしたときには特に変更がないように感じます。

しかし、ウェブで探してみても Xperia が Android7 になってハイレゾの音が良くなった。と、いう改版履歴は特に見当たらない。

もしかしたら、ただ単に気のせいなのか? f(^^;;

7月 072017
 

タイトルの「SoundPEATS Bluetooth 買ってみました。」と言っても、実はずいぶん前に購入したんですね。この次に書くエントリに必要になったので慌てて今更書いている。と、いう状態なんですけども、まぁ、懲りずに読んでやってくださいf(^^;;。

僕にとっては二個目の Bluetooth イヤホンです。一個目は Anker SoundBuds Sport NB10 を購入したのですが、これは主にランニング用で利用する目的でした。まぁ、会社への通勤時に利用しても良かったのですが、デザイン的にはランで利用するみたいなのと、音的に重低音が強い傾向があるので『じゃ、別のをもう一個買ってみっかねぇ。』と、いうことになったのであります。

そして、購入したのが SoundPEATS の Q11 という Bluetooth イヤホンです。まぁ、価格が安かった。と、いうのもあるのですけどね;-)。

このイヤホン日本製です。取扱説明書が日本語だし、電源ボタン長押しで起動すると「電源をオンにします。」 Bluetooth 機器、僕の場合は SONY Xperia Z5 Compact ですが、これに無事に接続すると「接続が完了しました。」と女性の声で喋ってくれます。

ピロロロロォーン。と音ではなく、声が聞こえるのであります。この辺りは『お。日本製だねぇ。』などと思えて来るのであります。
日本製かは分かりませんが、日本の会社が作った製品。ってことですねf(^^;;。

この Q11 を購入してそこはかとなく嬉しいのが、収納ケース付き。ってところですね。よくある巾着袋ではなく、ハードケースが付いてきます。これは大きさも手頃で中々良いです。ケースだけあと 2,3 個欲しい。などと思えるのであります;-)。

Q11 は aptX に対応しているので高音質って言えるのかな? Xperia Z5 Compact も aptX に対応しているので恩恵が受けられます。

 
さてと。音に付いてですが、僕の感覚的センスで書いてみますが、上にも書いた通り Anker SoundBuds Sport NB10 と比べると自然な音がしますね。重低音がドカドカこないので安心して聞いていられる。

あと、 Bluetooth イヤホンなので、ある程度の音質は捨てています。

僕の Xperia Z5 Compact には 64GB の MicroSD カードを利用して約 55GB 分、曲数にすると 280 曲程度のハイレゾ音源を入れていますが、これを Bluetooth イヤホンで聞くのは本末転倒だぁ。などと思って入るのですが、通勤時の電車の中で聞く Bluetooth イヤホンの利便性と音質をトレードオフしたら、どっちがえんじゃい? となってしまうのでありました・・。
僕的は SoftBank SELECTION SE-5000HR を含めて二つのイヤホンと一個のスピーカーを持っていますが・・。

 
このイヤホンは耳にひっかけて、ケーブルを後ろにまわして利用するようなのですが、僕には首の後ろにケーブルを通すという文化が無いので前で垂らしています;-)。

二個目の Bluetooth イヤホンですが、最近はこれを主流に利用しているのでありました。