とつぜんマインスイーパーがやりたくなって、Microsoft Store を起動したら「接続を確認してください」と言われた。コード: 0x80072EFD。

Chromeでは問題なくインターネット接続できるよ、これなんでしょ？

結論からすると、Windows10 October 2018 Update (1809) を適用した場合、IPv6を有効にしていないと Microsoft Store、Edge、ストアアプリのMahjongやMinesweeperが起動しない。対策のアップデートなし。※2018/10/14現在(ろっひー調べ)

Windows10 October 2018 Update (1809) に早々にアップデート。ファイルが消える問題は発生しなかったので良かったーと思っていたけど、これはその影響なの？

さらに、Edge も起動すると「このページを表示できません」と言われる。「INET_E_RESOURCE_NOT_FOUND」と表示されることも。これって？

Edgeのエラーは少なくとも October する前には発生していなかったから、どうやらこの２つの問題は October の影響ではないかと思われた。

検索すると、Microsoft Store にアクセスできない問題はちょこちょこ起きるらしい。

なーんだ、と、対策を試したが改善しない・・・これは深刻なのかも。

対策にヒントはこちらに。

https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11182916056

もともと、IPv6は使っていないので無効化していた。そこで、有効にしてみたら接続ができるようになった。

当面、Microsoft Store 等を利用するときだけ IPv6 を有効にすることで運用していくしかなさそう。

Ubuntuがアップをはじめました。

家族のアカウントを作って、音楽が聞けるようにして・・・気持ちよく動くねぇ。

VMware Playerがどうにも動かせないけど、他のに移行していきゃいいか。

本当に移行するとなったら家族の抵抗は大きいだろうけれども、ぶっちゃけ、俺以外はみんなネット利用の殆どをスマホで済ませてるんだよな～、それにちょっとしたネット検索くらいならUbuntuでもChromeを使えば問題なくできるし。

Officeだけが問題になるかな、表示の互換性が完全ではないから。なーんて考えてみると、昔あった国産の素晴らしいワードプロセッサを駆逐したのは大きな罪だよな～、選択肢が狭くなってるもん。

少しずつ移行を考えていこう。真面目にこんなことを考えるときが来るとは…

前回の記事でUbuntuがアップを始めた…と書いたものの、v6アクセスすると夜のゴールデンタイムのネットワーク速度低下が解消できることがわかり、やってみようかなと考えて申し込み。



光回線ナビ / IPv6対応で速くなる？「IPv6 IPoE + IPv4 over IPv6 接続サービス」って何者？

コムサス / Nifty-V6プラス変更について(IPv6接続オプションではないです)

紆余曲折あったが、関係先のみなさんが親切にしてくれたおかげで開通！だが、v6プラス契約の場合、IPv6のアドレスで公開できるポートが限られる。いわゆるウェルノウンポートは使用できないのだが、ルーターつないじゃったよ速度が早くなっちゃったよ後戻りはできないよ、どーすんの俺？と、長く暗いトンネルの入り口に立ったのだった…

結論から。

• v6プラス契約でゴールデンタイムでも90Mbpsを超える通信が可能になった(Googleのスピードテスト)。


• PPPoE接続でIPv4のアドレスが得られたことで、従来通り各種サービスをインターネットに向けて公開できた。
  
  ゴールデンタイムの場合でも、「インターネット側からの要求」は5～20Mbps程度であるものの、「インターネットへの応答」は90Mbps程度あるかもしれない。※

※かもしれないと書いたのは、相手がv6プラスみたいなサービスでアクセスしてくれば早そうだという予測から。計測してみると、IPv4のPPPoEは下りは遅くなるけれど、上りは高速。

ネットワーク構成は以下の通り。物理と論理がちょっと違っている。実はウチはClass Bのアドレス体系でネットワークを運用している。

     [ Internet ] 物理構成図
          │
      ┌─┴─┐
      │ ONU  │
      └─┬─┘
┌────┴────┐
│Router(1)         │
│IP: 172.16.1.1/16 │
└────┬────┘
      ┌─┴─┐                                                ┌──────┐
      │ HUB  ├──────────────────────┬─┤ WiFi Bridge├─┬─── ・・・
      └─┬─┘                                            │  └──────┘  │
┌────┼──────────────────┐┌────┴────┐┌────┴────┐
│        │                         VMware ESXi││Main PC           ││Android Phone     │
│     (Bridge)                                 ││IP: 172.16.1.2/16 ││IP: 172.16.1.3/16 │
│        ├───────────┐            ││GW: 172.16.1.1    │└─────────┘
│┌───┴─────┐┌────┴─────┐││NS: 172.16.1.100  │
││Router(2)         ││Server              ││└─────────┘
││IP: 172.16.2.1/16 ││IP: 172.16.1.100/16 ││
││GW: 172.16.2.1    ││GW: 172.16.2.1      ││
││PPPoE Connection  ││NS: 172.16.2.1      ││
│└─────────┘└──────────┘│
└───────────────────────┘

論理的には、サーバーはRouter(2)の下に入って別ネットワークを構成する形になる。

論理的には別ネットワークだが、物理的に1つのネットワーク上にあるとMain PCからServerに問題なくアクセスができる。同じ172.16.0.0/16のセグメントにいることがポイントである(もちろん、192.168.nnn.0/24のネットワーク体系でも同じセグメントならOK)。

このことをとある有力な技術者から教えてもらったことで、今回の結論を導き出すことができた。超感謝。

もしも別のセグメントにしていたら、サーバー側にかなりの変更が必要にり、ひょっとすると未だにサービス復旧できていなかったかもしれない。

ネットワークの経路は、

• MainPCやAndroid Phoneは、Router(1)を通ってIPv4 over IPv6、ないしは、IPv6 IPoEでインターネットに接続。[高速]


• ServerはRouter(2)のPPPoE接続を通ってインターネットに接続する。[低速]

となる。[低速]とは書いたものの、昼間はv6プラスと同じとは言わないがかなりの速度が出る。あくまでもゴールデンタイムについてのイメージ記述。

このネットワーク構成にすることにより以下のメリットがある。

• Serverの設定はゲートウェイの変更のみ。これだけでPPPoE接続を通ったインターネットアクセス(従来通り)ができる上に、ネットワーク上の他の端末からも問題なくアクセスができる。


• LAN内の他の端末は設定を変更する必要がない。

得られた結果に満足！

■貸与されたルーターの設定変更

図で言うところの Router(1) の設定変更。

PPPoEブリッジをONにする。

→ 今回NTTから貸与されたルーターはデフォルトでONだったと思う。

これにより、Router(1) 配下に設置予定の Router(2) が PPPoE 接続できるようになる。

■ルーターの構築

図で言うところの Router(2) の構築。

結果からすると、ブロードバンドルータを1つ追加で購入するのが一番簡単な気がする。しかし、Ubuntuでルーターを組んじゃえばいいんじゃね？と思ってしまったがために、ちょっと大変なことになった。

ルーターにするOSとして Ubuntu 18.04 Server を選定。理由は使い慣れているから、ということだけなので新しいものならなんでも大丈夫なんじゃないかと思う。メモリは最低要件の512MBとしたが、設定完了後もメモリが余りまくっているので問題なさそう。

■IPv6無効化

インストールは過去記事ベースで行う。このルーターは従来のIPv4によるサービス公開のために構築するのだから、IPv6は無効化する。IPv6接続はRouter(1)に任せておけば良い。

ついでに、起動時の待ち時間が発生しないようにタイムアウト時間も1秒に変更。

/etc/default/grub

#GRUB_TIMEOUT=10
GRUB_TIMEOUT=1
#GRUB_CMDLINE_LINUX=""
GRUB_CMDLINE_LINUX="ipv6.disable=1"

反映。

$ sudo update-grub

インストール後にアップデートやパッケージのインストールをするので、インターネットに接続できなきゃならない。よって、セットアップ時にIPアドレスは設定せずServerが提供するDHCPサービスを利用し、ルーター化する準備ができてからIPアドレスを変えていく。

■PPPoE接続ができるようにする

具体的なコマンドは以下。

$ sudo apt update; sudo apt dist-upgrade; sudo apt autoremove
$ sudo apt install pppoeconf

ここで、pppoeconfを使ってPPPoE接続の設定情報を作る。

$ sudo pppoeconf ← これでインストール画面になる

pppoeconfの設定は以下の回答で進めた。

• POPULAR OPTIONS
  
  → Yes


• ENTER USERNAME
  
  → 以前使っていたブロードバンドルーターに設定していたユーザー名。


• ENTER PASSWORD
  
  → 同パスワード


• USE PEER DNS
  
  → Yes


• LIMITED MSS PROBLEM
  
  → Yes


• DONE(ブート時に接続を開始するかどうか聞かれている)
  
  → Yes


• ESTABLISH A CONNECTION
  
  → Yes


• CONNECTION INITIATED
  
  → Ok

結果を確かめてみる。

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.nnn/16 brd 172.16.255.255 scope global ens160
       valid_lft forever preferred_lft forever
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1454 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp
    inet nnn.nnn.nnn.nnn peer nnn.nnn.nnn.nnn/32 scope global ppp0
       valid_lft forever preferred_lft forever

pppoeconfによりPPPoE接続ができるようになったから、LANのインターフェースになっているens160の設定を変える。

/etc/netplan/50-cloud-init.yaml

# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        ens160:
            addresses:
            - 172.16.2.1/16 ← Router(2)の計画に合わせて変更
            dhcp4: false
            gateway4: 172.16.2.1 ← Router(2)はGWでもある
            nameservers:
                addresses:
                - 8.8.8.8 ← 実際にはPPPoE開始時にresolv.confが書き換えられるので何でも良いように思われる
                search: []
    version: 2

変更を反映して確認する。

$ sudo netplan apply
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 172.16.2.1/16 brd 172.16.255.255 scope global ens160
       valid_lft forever preferred_lft forever
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1454 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp
    inet nnn.nnn.nnn.nnn peer nnn.nnn.nnn.nnn/32 scope global ppp0
       valid_lft forever preferred_lft forever

ここまでで、Router(2)はインターネットに接続できて、172.16.0.0/16とも接続できるようになった。

■ルーティング設定

ここからルーターとして動作するように設定していく。

まず、カーネルパラメーターを変更し、パケット転送をオンにする。

/etc/sysctl.conf

net.ipv4.ip_forward = 1

--- 攻撃回避メモ(以下は最初から1になっているので設定不要だった)
net.ipv4.tcp_syncookies=1
net.ipv4.icmp_echo_ignore_broadcasts=1

反映。

$ sudo sysctl -p

次に、転送の仕方を書く。今まで ufw を使うなどしてどうにか避け続けてきた iptables だ…。ファイルはどこに作ってもいいと思うんだけど、今回はここに作って実行して直して実行して…を繰り返した。

※危険な設定があれば教えてください…

/root/iptable-settings

#!/bin/sh ← テストを繰り返すにはスクリプトにしたほうが楽チンだった

readonly   thishost='172.16.2.1'
readonly  localarea='172.16.0.0/16'

readonly  myserver1='172.16.1.100'
readonly  myserver2='172.16.1.101' ← 別IPアドレスで公開しているサーバーがあるので書いている

readonly        any='0.0.0.0/0'

readonly  local_nic='ens160'
readonly global_nic='ppp0'


#-------------------------------------------------------------------------------
# Initialize
#-------------------------------------------------------------------------------

# Initialize
iptables -F        ← デフォルトテーブルのチェインを初期化
iptables -t nat -F ← natテーブルのチェインを初期化
iptables -X        ← デフォルトテーブルの組み込み以外のチェインを削除
iptables -Z        ← 全てのチェインのパケットカウンタとバイトカウンタをゼロに
iptables -P INPUT   ACCEPT
iptables -P OUTPUT  ACCEPT
iptables -P FORWARD ACCEPT

iptables -N LOGGING_I ← ログ用のチェーンを先に作っておく
iptables -N LOGGING_F
iptables -N LOGGING_O

# Policy
iptables -P INPUT DROP ← 基本、入力を拒否。ただし、接続済み、あるいはそれに関連するものは許可。
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -P OUTPUT ACCEPT ← 基本、出力を許可。ただし、ローカルパケットが外に出ようとしたら拒否。
iptables -A OUTPUT -o $global_nic -d 10.0.0.0/8     -j LOGGING_O ← LOGGING_Oチェーンに遷移させてDROP。
iptables -A OUTPUT -o $global_nic -d 176.16.0.0/12  -j LOGGING_O
iptables -A OUTPUT -o $global_nic -d 192.168.0.0/16 -j LOGGING_O
iptables -A OUTPUT -o $global_nic -d 127.0.0.0/8    -j LOGGING_O

iptables -P FORWARD DROP ← 基本、転送を拒否。ただし、ローカルから外に出るものはポート135,137:139,445を除いて許可。接続済み、あるいはそれに関連するものは許可。
iptables -A FORWARD -p tcp -i $local_nic -o $global_nic -m multiport --dports 135,137:139,445 -j DROP
iptables -A FORWARD -p udp -i $local_nic -o $global_nic -m multiport --dports 135,137:139,445 -j DROP
iptables -A FORWARD -i $local_nic -o $global_nic -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Loopback
iptables -A INPUT  -i lo -j ACCEPT ← ループバックはすべて許可。
iptables -A OUTPUT -o lo -j ACCEPT


#-------------------------------------------------------------------------------
# Router setting
#-------------------------------------------------------------------------------
iptables -t nat -A POSTROUTING -s $localarea -o $global_nic -j MASQUERADE ← ローカルから外に出るものはマスカレード。


#-------------------------------------------------------------------------------
# Local area network setting
#-------------------------------------------------------------------------------

### DNS
iptables -A INPUT -p udp -i $local_nic -d $thishost --dport 53 -j ACCEPT ← 主にServer(内向きDNSとして稼働)からの問い合わせを受け付ける。

### ICMP
iptables  -A INPUT  -p icmp --icmp-type echo-request -i $global_nic -j ACCEPT -m comment --comment 'ICMP(grobal)'
iptables  -A INPUT  -p icmp --icmp-type echo-reply   -i $global_nic -j ACCEPT -m comment --comment 'ICMP(grobal)'
#iptables -A OUTPUT -p icmp --icmp-type echo-reply   -o $global_nic -j ACCEPT -m comment --comment 'ICMP(grobal)' ← 書き方を忘れないためのメモ
#iptables -A OUTPUT -p icmp --icmp-type echo-request -o $global_nic -j ACCEPT -m comment --comment 'ICMP(grobal)' ← 書き方を忘れないためのメモ
iptables  -A INPUT  -p icmp -i $local_nic -j ACCEPT -m comment --comment 'ICMP(all-ok, local)'
#iptables -A OUTPUT -p icmp -o $local_nic -j ACCEPT -m comment --comment 'ICMP(all-ok, local)' ← 書き方を忘れないためのメモ

### IGMP(この経路でこの接続をするのか微妙なところ)
#iptables -A INPUT  -p igmp -j ACCEPT
#iptables -A OUTPUT -p igmp -j ACCEPT

### SSH
iptables -A INPUT -p tcp -i $local_nic -d $thishost --dport 22 -j ACCEPT


#-------------------------------------------------------------------------------
# Listen on wide area network setting
#-------------------------------------------------------------------------------

### HTTPS
iptables -t nat -A PREROUTING -p tcp -i $global_nic -d $any       --dport 443   -j DNAT --to-destination $myserver1:443
iptables        -A FORWARD    -p tcp -i $global_nic -d $myserver1 --dport 443   -j ACCEPT

### HTTP
iptables -t nat -A PREROUTING -p tcp -i $global_nic -d $any       --dport 80    -j DNAT --to-destination $myserver1
iptables        -A FORWARD    -p tcp -i $global_nic -d $myserver1 --dport 80    -j ACCEPT

### SMTP
iptables -t nat -A PREROUTING -p tcp -i $global_nic -d $any       --dport 25    -j DNAT --to-destination $myserver1
iptables        -A FORWARD    -p tcp -i $global_nic -d $myserver1 --dport 25    -j ACCEPT

### HTTP(Server2)
iptables -t nat -A PREROUTING -p tcp -i $global_nic -d $any       --dport 18080 -j DNAT --to-destination $myserver2
iptables        -A FORWARD    -p tcp -i $global_nic -d $myserver2 --dport 18080 -j ACCEPT

### RTMP(Adobe Systems Flash Time Messaging Protocol)
iptables -t nat -A PREROUTING -p tcp -i $global_nic -d $any       --dport 1935  -j DNAT --to-destination $myserver1
iptables        -A FORWARD    -p tcp -i $global_nic -d $myserver1 --dport 1935  -j ACCEPT

### L2TP
iptables -t nat -A PREROUTING -p udp -i $global_nic -d $any       --dport 1701  -j DNAT --to-destination $myserver1
iptables        -A FORWARD    -p udp -i $global_nic -d $myserver1 --dport 1701  -j ACCEPT

### ISAKMP
iptables -t nat -A PREROUTING -p udp -i $global_nic -d $any       --dport 500   -j DNAT --to-destination $myserver1
iptables        -A FORWARD    -p udp -i $global_nic -d $myserver1 --dport 500   -j ACCEPT

### IPSec NAT Traversal
iptables -t nat -A PREROUTING -p udp -i $global_nic -d $any       --dport 4500  -j DNAT --to-destination $myserver1
iptables        -A FORWARD    -p udp -i $global_nic -d $myserver1 --dport 4500  -j ACCEPT


#-------------------------------------------------------------------------------
# Diffender
#------------------------------------------------------------------------------- 
# 攻撃に対する対策を入れるならここ


#-------------------------------------------------------------------------------
# Logging
#-------------------------------------------------------------------------------

iptables -A LOGGING_I -j LOG --log-level warning --log-prefix "[IPT BLOCK I] " -m limit ← 本番
#iptables -A LOGGING_I -j LOG --log-level warning --log-prefix "[IPT BLOCK I] " ← デバッグ中はこちらの方がチェックしやすい
iptables -A LOGGING_I -j DROP
iptables -A INPUT -j LOGGING_I

iptables -A LOGGING_F -j LOG --log-level warning --log-prefix "[IPT BLOCK F] " -m limit
#iptables -A LOGGING_F -j LOG --log-level warning --log-prefix "[IPT BLOCK F] "
iptables -A LOGGING_F -j DROP
iptables -A FORWARD -j LOGGING_F

iptables -A LOGGING_O -j LOG --log-level warning --log-prefix "[IPT BLOCK O] " -m limit
#iptables -A LOGGING_O -j LOG --log-level warning --log-prefix "[IPT BLOCK O] "
iptables -A LOGGING_O -j DROP
#iptables -A OUTPUT -j LOGGING_O ← ここまできたものはデフォルトポリシーで通過

作成にあたっては、以下で勉強をさせていただいた。

@IT / 習うより慣れろ！ iptablesテンプレート集

Qiita / Ubuntu 16.04 でルータつくる

Nibelungen Code / iptablesでログを取る

ディーネット / iptablesにコメントを加えてみよう

この設定に加えて、以下で晒されている(！)攻撃に対する対策を組み込む。

対策部分はほとんどコピー＆ペーストで追加できると思う。矛盾はない。実際に攻撃してみていないが、それはまた余裕が出てきたらやってみよう。

Qiita / 俺史上最強のiptablesをさらす

このスクリプトを実行し、/var/log/syslogに出力されるログで動作を確認。

プロトコル番号の一覧はこちら。

Wikipedia / プロトコル番号一覧

パケットがどこまで飛んだか確認するのはこちら。

Qiita / 超絶初心者むけtcpdumpの使い方

■設定を恒久化

スクリプトで作った設定は再起動すると消えてしまう。

できあがった設定を恒久化させる必要がある。

Qiita / Ubuntu 16.04 iptables設定（基礎知識）

/etc/network/if-pre-up.d/にスクリプトを保存しておくと、ネットワーク接続が確立する寸前に実行してくれるので、そこでiptablesの設定を復元する、ということの模様。

/etc/network/if-pre-up.d/iptables-settings を新規作成。

#!/bin/sh
/sbin/iptables-restore < /etc/network/iptables.rules
exit 0

※パーミッションは755に。

iptables.rules を作成。

$ sudo iptables-save | sudo tee /etc/network/iptables.rules

再起動して確かめる。

■DynamicDNSサービスへの通知

起動時、PPPoEのセッションが確立したらDynamicDNSサービスに通知がしたい。

使わせていただいているDynamicDNSはメールサーバーにアクセスすることでIPアドレスを通知できるようになっている。通知にはbiffpopが便利なので使わせていただいている。

従来は、Router(1)が何らかの理由で再起動するとIPアドレスが変わってしまうが、それを検知する方法もない…ということで、20分毎に通知をしていた(スミマセン)。

今後はPPPoEのセッションが確立したときに通知が送られるようにすれば良い。

/etc/ppp/ip-up.d/9ddns

#!/bin/sh
/etc/ppp/biffpop -s -c /etc/ppp/.biffpoprc
exit 0

※パーミッションは755に。

また、cronによる通知はDynamicDNSサービスのルールから考えて、日に1回で十分なので修正しておく。

■ログの出力先を変える

こんなにサクッとできるものなのね…知識があるって大事だなぁ。

HACKnOTE / iptablesでdropしたパケットのログの出力先を変える

into the void / syslogの使い方をあらためて整理してみた

ログをiptables.logというところにだけ出すようにする。

/etc/rsyslog.d/30-iptables.conf を新規作成(UFWのをそのまま利用)。

# Log kernel generated UFW log messages to file
:msg,contains,"[IPT " /var/log/iptables.log

# Uncomment the following to stop logging anything that matches the last rule.
# Doing this will stop logging kernel generated UFW log messages to the file
# normally containing kern.* messages (eg, /var/log/kern.log)
& stop ← これにより、syslogにログが出力されなくなる。とても助かる。

反映。

$ sudo systemctl restart rsyslog.service

ついでに、ログローテーションができるようにしておこう。

/etc/logrotate.d/iptables を新規作成(UFWのをそのまま利用)。

/var/log/iptables.log
{
    rotate 54 ← 1年くらい前まで遡ることができれば大丈夫だろうと安易に設定
    weekly
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        invoke-rc.d rsyslog rotate >/dev/null 2>&1 || true
    endscript
}

こちらは、ファイルを作っておけば良く、cron → /etc/cron.daily で日々呼び出される模様。

こんなに簡単に切り分けできるのね…びっくり。

■サーバーの起動順序を変える

ESXi の設定を見直し、Router(2) → Server の順で起動するように変える。

停電→起動！ってなときに、Router(2)が先に起動してPPPoE接続を確立して待ち受け、Serverが起動してウチのネットワークが動き始める…というシナリオだ。

以上で2つ目のルーターが稼働し、従来通りにサービスを提供することができるようになった。

契約変更に伴ってルーターが金曜日の夜に届き、土曜日の午前中に設置…その時点から提供していたサービスが停止し、水曜深夜まで再開することができなかった。ここまでサービス停止が長引いたのは初めてではなかったか。準備不足であった感は否めない。

ん？じゃあ、準備していればできたの？といえば、それがそうでもなくて、まず、iptablesは避けて通ってきたし、IPv6もかじったけど理解できる前に終わってる。そう、困らなきゃ本気にならないし、本気にならないと覚えないという性格なだけに、困った状況を作り出して一気にそれを解決する必要があったのだ。

今にして思えば、古いルーターにもPPPoEブリッジ機能はあったんだから、契約を申し込む前にUbuntuルーターを構築することもできたし、ルーターが届いたからと言ってIPv6接続にこだわらずIPv4接続だけに切り替えてサービスを提供しながらUbuntuルーターを構築することもできた。自信がなければルーターを買ってくるという手もあった。でも、それは今だから思えることであって、暗中模索であってもできるまで突っ走っる性格なんだぜ～。

ということで、やっぱ必然で、避けられなくて、やるしかなかったのですよ。

結果として、iptablesが少しわかり、Ethernetってものが少しわかり、IPv6もわかってきた。

そして、あの有力な技術者の知識は半端じゃねぇということが良くわかった。ネットワークに関する様々な問題に対応しようとするとき、彼が頼りになる仲間であることを再認識できたことは最高だった。

いいことあるじゃん！あるじゃん！すごくあったじゃん！

さぁ、明日からも頑張っていこう！

■起こったこと(1)

新しく貸与されたルータを繋いでIPv4の「静的マスカレード設定」を進めていく…で、テストするとうまく行かなくて、もう一度ルーターの設定画面を見に行くと「静的マスカレード設定」の項目がなくなっている。

おかしいな…出荷時状態に戻してもう一回、もう一回と繰り返したが、「静的マスカレード設定」の項目が途中でなくなっちゃう。URLを覚えておいてアクセスしても怒られる。何だこれ？

Qiita / IPv6プラス環境におけるIPv4ポート公開設定

NORIのブログ / v6プラスを使ってみよう　その１

これを見たら…うーん、なるほど、設定項目は消えるようになっているのね、ウェルノウンポートでサービス公開ができないのね、と理解。同時に[本当に]目の前が暗くなった。

でも、解決策はあって、ルーターがもう1つ必要なのね、とわかった。

疲労コンパイル / v6プラスとIPv4(PPPoE)を併用する（その1）

ルーターは実はあるのだけれど、Wifiルーターなので設置場所が結構重要で動かせない。

じゃあ、線を増やす方法は？と考えたけれども配線工事が必要で大掛かりすぎる。

じゃあ、Linuxで作るか、あぁ、ルーティングか、iptablesか…と茨の道が見えてきたのだった。

■起こったこと(2)

sudoでコマンド実行時にエラーメッセージが表示された。

$ sudo ls
sudo: unable to resolve host router2

/etc/hosts にホスト名を追記して解決。

127.0.0.1       localhost.localdomain   localhost
::1             localhost6.localdomain6 localhost6
127.0.0.1       router2

# The following lines are desirable for IPv6 capable hosts
::1             localhost ip6-localhost ip6-loopback
fe00::0         ip6-localnet
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters
ff02::3         ip6-allhosts

■起こったこと(3) ※未解決

そうだ、IPv6でサービス提供できればいいんじゃね？と一瞬考えた。

利用させていただいている Dynamic DNS サービスはPOP3アクセスでIPを通知するようになっているので、IPv6のアドレスを通知すりゃいいんじゃないの？と。

サーバーはUbuntu 12からアップグレードし続けて運用中。IPv6のIPアドレスは以下で追加・削除ができた。

Quitta / 初歩のipコマンドの使い方（Link、IPアドレス）

/etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 172.16.1.100
netmask 255.255.0.0
gateway 172.16.1.1
dns-domain hogeserver.hogeddns.jp
dns-nameservers 172.16.1.1
iface eth0 inet6 manual
 up   ip -6 addr add xxxx:xxxx:xxxx:xxxx::100/64 dev $IFACE
 down ip -6 addr del xxxx:xxxx:xxxx:xxxx::100/64 dev $IFACE

auto eth0:1
iface eth0:1 inet static
address 172.16.1.101
netmask 255.255.0.0
gateway 172.16.1.1
dns-nameservers 127.0.0.1

反映。

$ sudo systemctl restart networking

※たまに、何度やってもどうにも変更ができなくなることがあった。この場合は再起動…

で、通知にはbiffpopを利用させていただいているのだが、何度やってもIPv4でアクセスしている。なんでだろと調べ直してみたら…

ナカタの Digital Wonder Land / POP3/APOP によるメイルチェッカー IPv6 対応

以前、コンパイルする際にはIPv6を無効化していたので、それでもコンパイルできる方法で作っていた模様。結果、IPv6アクセス部分が含まれていなかった。

改めてコンパイルしたら、IPv6でアドレスを通知するようになった！

※しかし、今度はサーバーのIPv6アドレスを思い通りにコントロールできず、この方向の検討は中断。別途。

■起こったこと(4) ※未解決

Router(2)に別セグメントのIPアドレスを振った。具体的には192.168.1.1を。さらに、Serverに192.168.1.100のアドレスを振った。

ルーティングやIPテーブルに関して調べて調べて試して試して…どうにかローカルにおいた192.168.1.2のテストマシンからApache→Wordpressにアクセスしたらエラーが出た。

設定が自ホストのIPじゃないよ、と。

これはきっとServerに192.168.1.100のアドレスを振るんじゃなくてルーティングすりゃ良さそうだとは思ったものの、iptables の暗中模索が続き、サーバーが停止し続けていたで断念。

■起こったこと(5) ※未解決

なんだか不思議なログが…

Nov 11 05:59:46 router2 kernel: [55808.580792] [IPT BLOCK I] IN=ens160 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=172.16.1.100 DST=<ppp0のIPアドレス> LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=21957 DF PROTO=TCP SPT=44988 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0

※最初はなぜFORWARDしないの？と思ったのだが、宛先がppp0のアドレスなのでINPUTだった。

送ってきているのはサーバーなので、誰が？とこのログが出るタイミングを見計らって以下を実行。

$ sudo lsof -i

結果、以下の表示が…

apache2   4561  www-data   28u  IPv4  39998      0t0  TCP 172.16.1.100:44988-><Router2のpppのホスト名>:https (SYN_SENT)
apache2   4564  www-data   26u  IPv6  35273      0t0  TCP 172.16.1.100:https->172.16.1.nnn:51851 (ESTABLISHED)

そもそも、宅内ネットワークはIPv4とIPv6のデュアルスタックになったので内向きDNSはIPv6対応させたいが、ApacheはIPv6で動いて欲しくない。

Qiita / Apache httpd IPv4のみで通信

これに従って、現在有効なサイト設定のVirtual Hostをすべて書き換えた。

#<VirtualHost *:443>
<VirtualHost 0.0.0.0:443>

だけど、IPv6なのは変わらず。これはApacheの仕様の模様。

そしてHTTPSに対してこんな要求が飛ぶのはなぜ？ということでモジュールを見てみたら、なんだかウチでは使っていないはずのものが動いてるぞ…

$ sudo a2dismod proxy_balancer
$ sudo a2dismod proxy_ftp
$ sudo systemctl restart apache2.service

使ってなさそうなモジュールを止めてみたものの、それでも止まらなかった。

ただ、特段問題が起きているようにも見えないので放っておくことにした。

■起こったこと(6)

なんだか知らないがOUTPUTのパケットがドロップする。おかしいな…

元々は、こんなのを /root/iptable-settings に書いていた。

iptables -P INPUT   DROP
iptables -P OUTPUT  ACCEPT
iptables -P FORWARD DROP
・・・
iptables -N LOGGING
iptables -A LOGGING -j LOG --log-level warning --log-prefix "DROP:" -m limit
iptables -A LOGGING -j DROP
iptables -A INPUT   -j LOGGING
iptables -A OUTPUT  -j LOGGING
iptables -A FORWARD -j LOGGING

デフォルトポリシーがACCEPTなんだから、OUTPUTは基本許されるんだろうと思っていた。

ところが…実際には、設定した色々な評価をすり抜けてここに到達したとき、

iptables -A OUTPUT -j LOGGING

の記述によって出力パケットはLOGGINGチェーンに遷移し、そこでログを出力した後にDROPされてしまうのだった。

これ、参照元のテンプレートでは適切に処理したり、赤文字行を含まない形のテンプレートにしたりして問題がないように整理されていたのだが、その事に気づいたのは学習から7日後のことだった(5日後にサービスをとりあえず復旧したときにはOUTPUTを書いてどうにか動かしていた)。

デフォルトチェーンを通過

　→ 最後に赤文字行で無条件にLOGGINGチェーンに遷移

　　→ 無条件ドロップ

結局、このiptablesの設定はデフォルトポリシーがどんなものであれ、ACCEPTされなかったパケットは結果的にLOGGINGチェーンに遷移し、必ずドロップするのだ。

本編で書いた設定は、「ACCEPTとFORWARDはそもそもデフォルトポリシーがDROPなんだから、LOGGINGチェーンに落ちてドロップしても構わない」訳なので、最後まできたところでLOGGINGチェーンに落として無条件DROPさせることにした。

一方で、OUTPUTはデフォルトポリシーがACCEPTなので問題のあるパケットをLOGGINGチェーンに落としてDROPさせ、問題のないパケットはスルーすることでデフォルトポリシーのACCEPTと判断される設定にした。

これで、DROPしたパケットはすべてログに出力される理想的な状態になった。

そもそも、v6プラスを契約すればIPv4とIPv6のデュアルスタックになる、というのが前提。一般には安心して契約できてとても利便性が高まるサービスである。ちょっと変わったことをやろうとすると大変なだけ。

前々回の記事で Windows10 October 2018 Update (1809) を適用したところ、IPv6のチェックを入れておかないと Edge や Microsoft Store 等が使えなくなる問題が発生したこと、そして、IPv6を有効にするとChromeで自宅のサービスにアクセスできないことを書いた。

なんでかなと思って調べてみたら、IPv6をオンにした場合とオフにした場合で、DNSへの問い合わせ結果が異なることがわかった。

IPv6をオン(有効)にするとグローバルなIPv4アドレスが返ってくる。

IPv6をオフ(無効)にするとローカルなIPv4アドレスが返ってくる。

オフの場合にローカルなIPv4アドレスが返ってくるのは、宅内で内向きDNSサービスを実行しているからなので正しい動作。オンの場合にグローバルIPv4アドレスが返ってくるのはなぜ？どこに問い合わせに行っているのか？

※この記事はv6プラス契約前に書き始めている。

■IPv6接続オプションの巻

契約に際し色々と確認してみると、IPv6接続オプションの契約が有効になっていることがわかった。

プロバイダーに聞いてみると、「契約内容確認ページではIPv6接続オプションが「解除済み」になっているけれども、実態としてはIPv6接続オプションが使える状態になっていた」ということだった。

当時のネットワーク構成は以下。

     [ Internet ] 物理構成図
          │
      ┌─┴─┐
      │ ONU  │
      └─┬─┘
┌────┴────┐
│Router(1)旧機種   │
│IP: 172.16.1.1/16 │
└────┬────┘
      ┌─┴─┐                                                ┌──────┐
      │ HUB  ├──────────────────────┬─┤ WiFi Bridge├─┬─── ・・・
      └─┬─┘                                            │  └──────┘  │
┌────┼──────────────────┐┌────┴────┐┌────┴────┐
│        │                         VMware ESXi││Main PC           ││Android Phone     │
│     (Bridge)                                 ││IP: 172.16.1.2/16 ││IP: 172.16.1.3/16 │
│        ├───────────┐            ││GW: 172.16.1.1    ││GW: 172.16.1.1    │
│┌───┴─────┐┌────┴─────┐││NS: 172.16.1.100  ││NS: 172.16.1.100  │
││Router(2)         ││Server              ││└─────────┘└─────────┘
││IP: 172.16.2.1/16 ││IP: 172.16.1.100/16 ││
││GW: 172.16.2.1    ││GW: 172.16.1.1      ││
││PPPoE Connection  ││NS: 172.16.1.1      ││
│└─────────┘└──────────┘│
└───────────────────────┘

Router(1)は旧機種でv6接続オプションには対応していたが、v6プラスには対応していなかった。

また、Router(2)構築前だったからServerのデフォルトゲートウェイはRouter(1)になっている。

Router(1)はv6接続オプションが有効になっていたから、DHCP機能はないもののRA(Router Advertisement)はブリッジしてくれていて、SLAAC(Stateless Address Auto Configuration)はできてインターネットアクセスができるIPv6のIPアドレスを自動構成していた。

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether nn:nn:nn:nn:nn:nn brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.100/16 brd 172.16.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 172.16.1.101/16 brd 172.16.255.255 scope global secondary eth0:1
       valid_lft forever preferred_lft forever
    inet6 24xx:xx:xxxx:xxx:xxx:xxxx:xxxx:xxxx/64 scope global mngtmpaddr dynamic
       valid_lft 2591644sec preferred_lft 604444sec

と、こんな感じ。なので、IPv6接続オプションでもIPv6アドレスが生成されている。

ping6で google.co.jp との疎通確認をしてみたら、IPv4より早いような気はしていた。

$ ping6 google.co.jp
PING google.co.jp(aaaaaaaaaaa.net) 56 data bytes
64 bytes from aaaaaaaaaaa.net: icmp_seq=1 ttl=54 time=7.86 ms
64 bytes from aaaaaaaaaaa.net: icmp_seq=2 ttl=54 time=9.19 ms
・・・
$ ping google.co.jp
PING google.co.jp (nnn.nnn.nn.nn) 56(84) bytes of data.
64 bytes from aaaaaaaaaaa.net (nnn.nnn.nn.nn): icmp_seq=1 ttl=56 time=13.1 ms
64 bytes from aaaaaaaaaaa.net (nnn.nnn.nn.nn): icmp_seq=2 ttl=56 time=13.4 ms

ただ、実際にネットワークを使っていて「早い」という感じはなかった。

光回線ナビ / v6プラスと「IPv6接続オプション」や「フレッツ光 IPv6接続」の違い

ここに書かれていることと体感は一致。だけどpingだけを見ていると違うような気も…読み間違いかな。

どんなRAを受け取っているのかは以下で確認。

$ sudo apt install radvdump
$ sudo radvdump
このときの記録はとっておかなかった～

このとき、Windows10でipconfig -all してみると、DNSとしてNTT東日本の用意したものも表示されていた。Windows10は、IPv6を有効にしているとIPv4よりもIPv6が優先されるため、問い合わせするとNTT東日本の用意したDNSを先に参照することになる。故に、ローカルにいるのにグローバルなIPv4アドレスが戻ってきていたのだった。

IPv6をオフにしても、覚えたIPアドレスを忘れない場合も。WindowsでDNSキャッシュをクリアするコマンドは以下。

>ipconfig /flushdns

■v6プラスの巻

このあたりまで調べたところでv6プラス対応のRouter(1)が送られてきて設置したため、IPv6接続オプションの検証はやめてv6プラスの設定を始めた。前回記事のRouter(2)構築がそれ。

先に結論。※詳しい方、ぜひ、改善方法を教えてください。

• Ubuntuが提供しているisc-dhcp-serverはデュアルスタック非対応。
  
  ソースからインストールして4.4.xにする必要がある。


• v6プラス環境ではULAのみ自由に振り出してLAN内のアクセスに利用し、GUAとLLAはRAに従って自動構成させてインターネットアクセスする。


• Windows10ではGUA,ULA,LLAの全てが即時に正しく振り出されて動作する。


• UbuntuではGUA,LLAは正しく振り出されるが、ULAは時間が経たないと正しく振り出されず、DNSへの反映もされない問題あり。

やったことは以下。

• ServerのIPv6を有効化。


• ServerのIPv6アドレスを構成。


• ServerのIPv6ポートを開放。


• ServerのDNSでIPv6アドレスを返す。


• ServerのDHCPをIPv6対応させる。


• ServerでRAを返す。


• 使ってみる。

さて…ここまで調べてみたところで、IPv6を各クライアントで使えるようにしたほうが、インターネットを利用する上で有利かもしれないと思い始めた。

IPv6はいずれやらなきゃ、という思いを持っていたので、学習。

MURA's HomePage : IPv6実践導入ガイド

1234:5678:9012:3456:7890:1234:5678:9012

前半16桁(緑)がサブネットプレフィックス、後半16桁(赤)がインターフェイスID。

前半16桁のうち、最初の12桁(緑太字)がグローバールルーティングプレフィックス、残りの4桁(緑普通)がサブネットID。

この形式で必要なだけIPv6のアドレスを作って持たせる＝複数持たせる。

で、今回の設定。

• GUA(Global Unicast Address / 2000::/3)
  
  RAに従ってServerを含む全てのホストが自動構成する。
  
  加えて、プレフィックスはv6プラス契約では固定になるので、Serverのみ固定のIPアドレスを手で振ってみる(＝インターネット上の唯一のGUAになりそう)。


• ULA(Unique Local Address / fc00::/7 ～ 計算ツールを使ってプレフィックスを生成)
  
  Ubuntu Server を fdxx:xxxx:xxxx:xxxx::100/64 として、他の機器にはfdxx:xxxx:xxxx:xxxx::1:1～fdxx:xxxx:xxxx:xxxx::1:ffffをDHCPで振り出す。
  
  LAN内はULAでやり取りする。


• LLA(Link-local Address / fe80::/10)
  
  全てのホストが自動構成する。狙っていないのだができてしまうのが実態。

ULAのプレフィックスは以下のツールを使わせていただき計算した。

MAKCRAFT / Ipv6UniqueLocal

図にするとこんな感じ。

     [ Internet ] 
          │
      ┌─┴─┐
      │ ONU  │
      └─┬─┘
┌────┴────┐
│Router(1)新機種   │
│IPv6: 自動構成    │
└────┬────┘
      ┌─┴─┐                                                ┌──────┐
      │ HUB  ├──────────────────────┬─┤ WiFi Bridge├─┬─── ・・・
      └─┬─┘                                            │  └──────┘  │
┌────┼──────────────────┐┌────┴────┐┌────┴────┐
│        │                         VMware ESXi││Main PC ※2       ││Android Phone ※2 │
│     (Bridge)                                 ││IP: 自動構成      ││IP: 自動構成      │
│        ├───────────┐            ││GW: 自動構成      ││GW: 自動構成      │
│┌───┴─────┐┌────┴─────┐││NS: fdxx::100     ││NS: fdxx::100     │
││Router(2)         ││Server              │││IP: 24xx～::xxx※1││IP: 24xx～::xxx※1│
││IP: 172.16.2.1/16 ││IP: 172.16.1.100/16 │││IP: fdxx～::1:2   ││IP: fdxx～::1:3   │
││GW: 172.16.2.1    ││GW: 172.16.2.1      │││IP: fe80～::xxx※3││IP: fe80～::xxx※3│
││PPPoE Connection  ││NS: 172.16.2.1      ││└─────────┘└─────────┘
││                  ││IP: 24xx～::xxx     ││ 
││                  ││IP: 24xx～::100 ※1 ││
││                  ││IP: fdxx～::100     ││
││                  ││IP: fe80::xxx ※3   ││ ※1: 24xx～::はRoute(1)が通知するプレフィックス
│└─────────┘└──────────┘│ ※2: Main PC や Android Phone は IPv4も構成
└───────────────────────┘ ※3: インターネットに向けたルーティングで必要

今回は宅内を完全なデュアルスタックにすることを目指す。

■ServerのIPv6を有効化

宅内でサービスを提供しているServerは IPv6 を無効化している。Ubuntu 12.04 の時代から。アップグレードを重ね現在は Ubuntu 16.04 になっているがそのままだった。

そこで、IPv6を有効にするために以下を行った。

/etc/sysctl.conf

#net.ipv6.conf.all.disable_ipv6 = 1
#net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.all.forwarding = 1

設定を有効化させる。

$ sudo sysctl -p

ファイアウォールもIPv6を無効化していた・・・

/etc/default/ufw

IPV6=yes ← 有効化
#IPV6=no ← コメント化

一旦、ufwを止めて再開

$ sudo ufw disable
$ sudo ufw enable

■ServerのIPv6アドレスを構成

IPv6のアドレスを設定しなきゃと探してみると…自動構成されるIPv6アドレスの他に、計画のIPv6アドレスを追加する方法はここにあった。Ubuntuのバージョンとかで違うところはテストして吸収。

How do I add an additional IPv6 address to /etc/network/interfaces?

/etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 172.16.1.100
netmask 255.255.0.0
gateway 172.16.2.1
dns-domain hogeserver.hogeddns.jp
dns-nameservers 127.0.0.1

iface eth0 inet6 auto
 post-up  ip -6 addr add 24xx:xxxx:xxxx:xxxx::100/64 dev $IFACE ← delは書くとエラーがでる(実害なし)
 post-up  ip -6 addr add fdxx:xxxx:xxxx:xxxx::100/64 dev $IFACE
#iface eth0 inet6 static ← この書き方もできるけど、遅いし、エラーがでる(実害なし)
# address 24xx:xxxx:xxxx:xxxx::100/64
#iface eth0 inet6 static
# address fdxx:xxxx:xxxx:xxxx::100/64

# 2つ目
auto eth0:1
iface eth0:1 inet static
address 172.16.1.101
netmask 255.255.0.0
#gateway 172.16.2.1        ← これらも書くとエラーがでる。flushが必要になる。
#dns-nameservers 127.0.0.1

設定を反映させる。通常は1行目ので反映できるが、面倒なエラーが出たときとかには2行目でエラーの根源を整理しつつ反映させる。

$ sudo systemctl restart networking
$ sudo ifdown eth0 && sudo ip addr flush eth0 && sudo ifup eth0

IPv6アドレスと、ルーティング、DNSについて結果を確認。

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.100/16 brd 172.16.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 172.16.1.101/16 brd 172.16.255.255 scope global secondary eth0:1
       valid_lft forever preferred_lft forever
    inet6 24xx:xxxx:xxxx:xxxx:nnnn:nnnn:nnnn:nnnn/64 scope global mngtmpaddr dynamic ※自動構成
       valid_lft 13851sec preferred_lft 12051sec
    inet6 fdxx:xxxx:xxxx:xxxx::100/64 scope global ※手動設定
       valid_lft forever preferred_lft forever
    inet6 24xx:xxxx:xxxx:xxxx::100/64 scope global ※手動設定
       valid_lft forever preferred_lft forever
    inet6 fe80::nnnn:nnnn:nnnn:nnnn/64 scope link  ※自動構成
       valid_lft forever preferred_lft forever

$ ip -6 route
24xx:xxxx:xxxx:xxxx::/64 dev eth0  proto kernel  metric 256  pref medium
fdxx:xxxx:xxxx:xxxx::/64 dev eth0  proto kernel  metric 256  pref medium
fe80::/64 dev eth0  proto kernel  metric 256  pref medium
default via fe80::rout:er1x:rout:er1x dev eth0  proto ra  metric 1024  expires 8494sec hoplimit 64 pref medium

$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
・・・
nameserver 127.0.0.53
search hogeserver.hogeddns.jp

※自動構成のアドレス部分はxxxxとnnnn、router1xでマスクしている。プレフィックスは固定なので隠したかったから。

SLAACによって？LLAが構成され、デフォルトルートとしてそれが設定されている。ルーターの設定画面では明示されていないが、ルーターのインターフェースアドレスと同一だった。

テスト。Ubuntuから外へ。

$ ping6 google.co.jp -I 24xx:xxxx:xxxx:xxxx::100
PING google.co.jp(aaaaaaaa.net) from 24xx:xxxx:xxxx:xxxx::100 : 56 data bytes
64 bytes from aaaaaaaa.net: icmp_seq=1 ttl=52 time=7.13 ms
…

Main PC(Windows10)からUbuntuへ。

>ping -6 24xx:xxxx:xxxx:xxxx::100

24xx:xxxx:xxxx:xxxx::100 に ping を送信しています 32 バイトのデータ:
24xx:xxxx:xxxx:xxxx::100 からの応答: 時間 <1ms
24xx:xxxx:xxxx:xxxx::100 からの応答: 時間 <1ms
24xx:xxxx:xxxx:xxxx::100 からの応答: 時間 =1ms
24xx:xxxx:xxxx:xxxx::100 からの応答: 時間 <1ms

24xx:xxxx:xxxx:xxxx::100 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 0ms、最大 = 1ms、平均 = 0ms

設定完了。

■ServerのIPv6ポートを開放

TeraTermを利用してIPv6で接続してみる。ufwでポート開放。

ufwはここに使い方が詳しく書かれている。今回はIPv6関連でヒットしたけど、行選択して削除する方法が具体的に書かれていたりしてとっても良かった。

DigitalOcean / How To Set Up a Firewall with UFW on Ubuntu 18.04

$ sudo ufw allow from any to 24xx:xxxx:xxxx:xxxx::100 port 22 proto tcp
$ sudo ufw status
状態: アクティブ

To                         Action      From
--                         ------      ----
…
24xx:xxxx:xxxx:xxxx::100 22/tcp ALLOW       Anywhere (v6)

以下を見ながら、接続先として [24xx:xxxx:xxxx:xxxx::100] を入力して接続する。大括弧で囲むのが味噌。OK！

OSDN / Tera Term チケット #16003

気を良くしてWebサービスを開放してみる。

$ sudo ufw allow from any to 24xx:xxxx:xxxx:xxxx::100 port 443 proto tcp

以下を見ながら、接続先として https://[24xx:xxxx:xxxx:xxxx::100] を入力して接続する。どうやら、大括弧で囲むのがベーシックなやり方なんだなと理解。

iPentec / URLで IPv6 のIPアドレスを指定して接続する (Windows Tips)

まず、アクセスはできた。できたがWordpressでエラーが発生…でも、これはIPv4アドレスでアクセスしても同じ。ホスト名の設定ファイルしか作っていないのだ。

Neither /etc/wordpress/config-24xx.php nor /etc/wordpress/config-24xx.php could be found. 
Ensure one of them exists, is readable by the webserver and contains the right password/username.

一時的に /etc/wordpress/config-hogeserver.hogeddns.jp.php のシンボリックリンクとして /etc/wordpress/config-24xx.php を作ってアクセスしてみたらWordpressは動作するようになった。

根本解決には、DNSサーバーでIPv6な名前解決ができればOKと見た。

■ServerのDNSでIPv6アドレスを返す

いままで、Serverで稼働している BIND9 はIPv6を気にしていなかった。実際にゾーンファイルを見ても、IPv6のエントリーはない。

BIND9のファイル構成はこんな感じ。

named.conf
  ├ named.conf.options
  ├ named.conf.default-zones ※基本設定で触る必要なしと見た。
  │  ├ db.root          ← zone "." root name server。ココの情報そのまま。ftp://ftp.rs.internic.net/domain/named.root
  │  ├ db.local         ← zone "localhost"        ローカルゾーン。
  │  ├ db.127           ← zone "127.in-addr.arpa" ループバックゾーン。
  │  ├ db.0             ← zone "0.in-addr.arpa"   ループバックゾーン。
  │  └ db.255           ← zone "255.in-addr.arpa" ループバックゾーン。
  └ named.conf.local
      ├ zones.hogeserver ← ゾーンファイルを設定
      └ zones.rfc1918    ← named.conf.localでinclude文がコメント化されている

このあたりの情報を参考にしながら再学習。

@IT / 名前解決の仕組みとゾーンファイルの設定

/etc/bind/named.conf.options に以下を追記。これでIPv6の要求を受け付ける。

options {
    directory "/var/cache/bind";

    // あなたと話したいネームサーバーの間にファイアウォールがある場合は、
    // 複数のポートが通信できるようにファイアウォールを修正する必要があります。
    // http://www.kb.cert.org/vuls/id/800113 を参照してください。

    // あなたのISPが安定したネームサーバのために1つ以上のIPアドレスを提供しているなら、
    // あなたはおそらくそれらをフォワーダとして使いたいと思うでしょう。
    // 次のブロックのコメントを外し、all-0のプレースホルダーを置き換えるアドレスを挿入します。

    forwarders {
        172.16.1.1;   # to Router
    };

    //========================================================================
    // BINDが期限切れのルート・キーに関するエラー・メッセージを記録した場合、
    // 鍵を更新する必要があります。 https://www.isc.org/bind-keysを参照してください。
    //========================================================================
    dnssec-validation auto;

    listen-on {
        127.0.0.1;
        172.16.1.100;
    };

    listen-on-v6 {
        ::1;
        fdxx:xxxx:xxxx:xxxx::100;
    };

    auth-nxdomain no;    # conform to RFC1035
};

逆引きゾーンを設定。

/etc/bind/zones.hogeserver に以下を追記。

//DynamicDNS対応
include "/etc/bind/rndc.key";

//正引き
zone "hogeserver.hogeddns.jp" {
    type master;
    file "/var/cache/bind/db.hogeserver.zone";
    allow-update {
        key "rndc-key";
    };
};

//逆引き
zone "16.172.in-addr.arpa" {
    type master;
    file "/var/cache/bind/db.hogeserver.revz";
    allow-update {
        key "rndc-key";
    };
};

//逆引きIPv6
zone "x.x.x.x.x.x.x.x.x.x.x.x.x.x.d.f.ip6.arpa" {
    type master;
    file "/var/cache/bind/db.hogeserver.revz.v6";
    allow-update {
        key "rndc-key";
    };
};

※名前の付け方は以下を参照。

@it / IPv6対応DNSサーバの実現 (1/2)

作業日記 / jail マシンを IPv4 と IPv6 のデュアルスタックにする

UnixPower on Networking / https://www.unix-power.net/networking/centos6-bind-ipv6

/var/cache/bind/db.hogeserver.zone に以下を追記。

$ORIGIN .
$TTL 86400  ; 1 day
hogeserver.hogeddns.jp  IN SOA  dns.hogeserver.hogeddns.jp. (
                 2013183788 ; serial
                 3600       ; refresh (1 hour)
                 600        ; retry (10 minutes)
                 259200     ; expire (3 days)
                 86400      ; minimum (1 day)
                 )
            NS   172.16.1.1.
            NS   172.16.1.100.
            A    172.16.1.100
            AAAA 24xx:xxxx:xxxx:xxxx::100
            MX   10 smtp.hogeserver.hogeddns.jp.
$ORIGIN hogeserver.hogeddns.jp.
hogeserver  A    172.16.1.100
            AAAA 24xx:xxxx:xxxx:xxxx::100
・・・

/var/cache/bind/db.hogeserver.revz.v6 を新規作成。

$TTL 86400  ; 1 day
@           IN SOA  dns.hogeserver.hogeddns.jp. (
                2018111111 ; serial
                3600       ; refresh (1 hour)
                600        ; retry (10 minutes)
                259200     ; expire (3 days)
                86400      ; minimum (1 day)
                )
)

            IN NS   router.hogeserver.hogeddns.jp.
0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0 IN  PTR     hogeserver.hogeddns.jp.
0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0 IN  PTR     hogeserver.hogeserver.hogeddns.jp.

パーミッションを変更。

$ sudo chown bind:bind /var/cache/bind/db.hogeserver.revz.v6

設定を反映させる。

$ sudo systemctl reload bind9

Serverの53ポートを開ける。これで各ホストやRouter(1)からの名前解決の問い合わせに答えられる。

$ sudo ufw allow to any port 53 from any

正引きの確認。

$ dig -6 hogeserver.hogeddns.jp aaaa

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -6 hogeserver.hogeddns.jp aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7047
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hogeserver.hogeddns.jp.            IN      AAAA

;; ANSWER SECTION:
hogeserver.hogeddns.jp.     86400   IN      AAAA    xxxx:xxxx:xxxx:xxxx::100

;; AUTHORITY SECTION:
hogeserver.hogeddns.jp.     86400   IN      NS      172.16.1.100.

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Sun Nov 18 22:40:47 JST 2018
;; MSG SIZE  rcvd: 124

逆引きは以下で確認。

$ dig -x 24xx:xxxx:xxxx:xxxx::100

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -x 24xx:xxxx:xxxx:xxxx::100
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18436
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.x.x.x.x.x.x.x.x.x.x.x.x.x.x.4.2.ip6.arpa. IN PTR

;; ANSWER SECTION:
0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.x.x.x.x.x.x.x.x.x.x.x.x.x.x.4.2.ip6.arpa. 86400 IN PTR hogeserver.hogeddns.jp.

;; AUTHORITY SECTION:
x.x.x.x.x.x.x.x.x.x.x.x.x.x.4.2.ip6.arpa. 86400 IN NS router.hogeserver.hogeddns.jp.

;; ADDITIONAL SECTION:
router.hogeserver.hogeddns.jp.   86400   IN      A       172.16.1.100

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Nov 18 22:26:40 JST 2018
;; MSG SIZE  rcvd: 165

ここまで設定ができると、他のホストでIPv6を優先するものは、Serverにアクセスする際にIPv6を利用するようになる。名前解決させるとIPv6のアドレスが返ってくるようになったから。Windows10からpingするだけでも結果がわかる。

ただし、これが成立するのはIPv6アドレスよりもIPv4アドレスのほうが先にLink upした場合だけだった。稀に逆になる場合もあって、この場合には外にあるDNSへ問い合わせに行ってしまう。※再起動してみたら、そんな事になったからわかった。

対策は、Router(1)の設定。

RT-500KI → 詳細設定 → DNS設定 → ローカルドメイン問合せテーブル に以下の情報を入力。

ドメイン名: hogeserver.hogeddns.jp
プライマリDNSサーバアドレス: 24xx:xxxx:xxxx:xxxx::100
セカンダリDNSサーバアドレス: 無指定

これでIPv6のDNSが優先されても、IPv6しかない端末からでもRouter(1)がServerにアドレスを聞いてくれるようになり、内向きDNSで名前解決ができるようになった。

4万文字を超えたため次の記事に続く…

4万文字を超えたため…前回からの続き

■ServerのDHCPをIPv6対応させる

ここまでの作業でだいぶデュアルスタック感はあるものの、Server以外のホストはDNSにIPv6アドレス登録されていないから、名前解決してもIPv4アドレスしか返ってこない。

逆になぜIPv4のアドレスが返ってくるかというと、ServerがDynamicDNSサービスを提供しているから。DHCPv4がアドレスを振り出すと、それをDNSに登録してくれている。

これと同じことをIPv6についても行えばいい…と思ったが、これが大ごとだった。

まず、現在Ubuntu16.04でインストールされる DHCP Server は4.3.3。このバージョンはデュアルスタックにおけるDDNSの動作に対応していない。4.4からこの機能が実装されている。

そこで、このバージョンをアンインストールして、最新バージョンをソースからコンパイルしてインストールする。こんなところからやるのか…。

念の為 /etc/dhcp のディレクトリまるごと、及び、/etc/init.d/isc-dhcp-server 、/etc/default/isc-dhcp-server をバックアップする。

※実際には使わずに済んだ。

その上で、以下を実行。

$ wget https://www.isc.org/downloads/file/dhcp-4-4-1/ ← この日のバージョンは4.4.1。ダウンロード。ファイル名がindex.htmlになるからリネームする。
$ sudo apt remove isc-dhcp-server
$ sudo apt autoremove ← 付随するライブラリが不要扱いに…
・・・
以下のパッケージは「削除」されます:
  libirs-export141 libisccfg-export140
・・・

インストールは以下を参考に実行。

FreeBSD - System Administration / ISC DHCP IPv4 & IPv6 Server on a Dual-Stack Network

$ mv index.html dhcp-4.4.1.tar.gz
$ tar zxvf dhcp-4.4.1.tar.gz
$ cd dhcp-4.4.1/
$ ./configure
$ make
$ sudo make install

/etc/default/isc-dhcp-server のパラメータ変更。OPTIONSの設定値が-6になっていて動作しなかったため。

OPTIONS="-4"
INTERFACES="eth0"

DHCPv4動作にちょっと変更を加える。ざっくり全部を載せた上で、ポイントになりそうなところだけコメント。結果から見れば変更点は3行だけ。

/etc/dhcp/dhcpd.conf

ddns-update-style interim;
ddns-domainname "hogeserver.hogeddns.jp.";
ddns-rev-domainname "ip6.arpa.";
ddns-dual-stack-mixed-mode true; ← これがデュアルスタック利用フラグ。trueで。
update-conflict-detection false; ← IPv6との競合が必ず発生するからfalseで。
update-static-leases on;
option domain-name "hogeserver.hogeddns.jp";
option domain-name-servers 172.16.1.100;

default-lease-time 86400;
max-lease-time 604800;

lease-file-name "/var/lib/dhcp/dhcpd.leases"; ← ソースからコンパイルしたらデフォルトのディレクトリがない。既存ディレクトリを明示した。

authoritative;

log-facility local7;

#-----------------------------------------
# This is a my network subnet declaration.
#-----------------------------------------
subnet 172.16.0.0 netmask 255.255.0.0 {

    # --- default gateway
    option routers 172.16.1.1;

    # --- WINS server
    option netbios-name-servers 172.16.1.100;

    # --- NTP server
    option ntp-servers 172.16.1.100;

    # --- Lease range setting
    range 172.16.1.40 172.16.1.80;
}

#-----------------------------------------
# Fixed address
#-----------------------------------------
host MainPC {
    hardware ethernet nn:nn:nn:nn:nn:nn;
    fixed-address 172.16.1.2;
}

#-----------------------------------------
# Dynamic DNS settings.
#-----------------------------------------
include "/etc/dhcp/ddns-keys/rndc.key";

zone hogeserver.hogeddns.jp. { ← 最後のドットを忘れない。
    primary localhost;
    key "rndc-key";
}

zone 16.172.in-addr.arpa. {
    primary localhost;
    key "rndc-key";
}

DHCPv4サービスを実行。

$ sudo systemctl start isc-dhcp-server
Failed to start isc-dhcp-server.service: Unit isc-dhcp-server.service is masked. ← おっと、マスク…
$ sudo systemctl unmask isc-dhcp-server
$ sudo systemctl start isc-dhcp-server　← 改めて実行
・・・
$ sudo ln -s /usr/local/sbin/dhcpd /usr/sbin/dhcpd ← シンボリックリンクを作成

DHCPv6のためにサービス実行のためのファイルを作成。

$ sudo cp /etc/init.d/isc-dhcp-server /etc/init.d/isc-dhcp-server6
$ sudo cp /etc/default/isc-dhcp-server /etc/default/isc-dhcp-server6

編集。/etc/init.d/isc-dhcp-server6 は以下の3行に赤文字を追加。

DHCPD_DEFAULT="${DHCPD_DEFAULT:-/etc/default/isc-dhcp-server6}"
DHCPD_CONF=${DHCPD_CONF:-/etc/dhcp/dhcpd6.conf}
DHCPD_PID="${DHCPD_PID:-/var/run/dhcpdi6.pid}"

/etc/default/isc-dhcp-server6 は以下を4から6に変更。

OPTIONS="-6"

動作設定。

/etc/dhcp/dhcpd6.conf

ddns-update-style interim;
ddns-domainname "hogeserver.hogeddns.jp.";
ddns-rev-domainname "ip6.arpa.";
ddns-dual-stack-mixed-mode true; ← これがデュアルスタック利用フラグ。trueで。
update-conflict-detection false; ← IPv4との競合が必ず発生するからfalseで。 
update-static-leases on; 
allow client-updates;    ← 意味ないかも。色々いじった最後に残ってた…
do-forward-updates true; ← 同上

option domain-name "hogeserver.hogeddns.jp"; 
option dhcp6.name-servers fdxx:xxxx:xxxx:xxxx::100;

default-lease-time 86400;
max-lease-time 604800;

lease-file-name "/var/lib/dhcp/dhcpd6.leases"; ← ソースからコンパイルしたらデフォルトのディレクトリがない。既存ディレクトリを明示した。 

authoritative;
log-facility local6; ← 動作確認のために分けた。困っていない人は7のままでも大丈夫。

#-----------------------------------------
# This is a my network subnet declaration.
#-----------------------------------------
subnet6 fdxx:xxxx:xxxx:xxxx::/64 {
    range6 fdxx:xxxx:xxxx:xxxx::1:1 fdxx:xxxx:xxxx:xxxx::1:1000;

    option dhcp6.domain-search "hogeserver.hogeddns.jp";
}

#-----------------------------------------
# Fixed address
#-----------------------------------------
host MainPC {
    hardware ethernet xx:xx:xx:xx:xx:xx;
    fixed-address6 fdxx:xxxx:xxxx:xxxx::2;
}

#-----------------------------------------
# Dynamic DNS Settings.
#-----------------------------------------
include "/etc/dhcp/ddns-keys/rndc.key";

zone hogeserver.hogeddns.jp. {
    primary6 ::1;
    key "rndc-key";
}

zone 0.e.7.0.0.6.d.f.c.4.f.c.7.4.d.f.ip6.arpa. { ← 名前の付け方はDNSのところで書いた
    primary6 ::1;
    key "rndc-key";
}

v4とv6でログの出力先を分け、ちゃんと動作するまで見守りたい。

/etc/rsyslog.d/isc-dhcp-server.conf をGithub / DHCP Server Configuration を参考にして作成。

# Logging for DHCP server
local7.*       /var/log/dhcpdv4.log
local6.*       /var/log/dhcpdv6.log ← こなれてくるまで…とログを分けた。

rsyslogサービスを再起動。

$ sudo systemctl restart rsyslog

DHCPv6サービスを登録し、leasesファイルを作ってサービスを開始。

$ sudo systemctl daemon-reload
$ sudo touch dhcpd6.leases
$ sudo systemctl start isc-dhcp-server6

さて、DHCPv6はポート547で動作する。そこで、以下の通りポートを開放する。

$ sudo ufw allow to any proto udp port 547 from any
ルールを追加しました
ルールを追加しました (v6)

見ての通り、v6だけでなくv4も開放してしまったので、v4部分を削除する。

$ sudo ufw status    ← 一覧を表示させる
$ sudo ufw delete 18 ← v4部分が何番目か…でその数字を入れる。今回は18だった。

ufwでv6だけを操作するためには、proto ipv6 と書くか、from または to にIPv6のアドレスを書けばよいのだけれど、このルールはどのアドレスに対しても実行していいと思ったので、上記の通り足してからIPv4だけを削除することにした。

ということで完了。あれ？こうやって書いて整理してみると全然大ごとじゃなくてサクサク感があるな…。

■ServerでRAを返す

現在、Serverを含めたLAN内のIPv6を有効にしたホストは、RAの情報に基づいてIPv6アドレスを自動構成している。しかし、RouterのDHCPv4を無効にしているからか(？)、RouterはDHCPv6アドレスを振り出していない。

このIPv6アドレスを自動構成するもととなったRAが何なのかを確認するため、テスト用にUbuntu18.04デスクトップ版をVMware Playerで立ち上げてみた。

付けたコメントは以下のサイトから転載している。

ITmedia エンタープライズ / SolarisからIPv6ルーターのようにRAを配信する

UnixPower on Networking / CentOS6 ISC-DHCP ( DHCPv6 )

ネットワークエンジニアとして / IPv6 addressing - Stateless / Statefull / DHCPv6

$ sudo apt install radvd
$ sudo radvdump ens33
#
# radvd configuration generated by radvdump 2.16
# based on Router Advertisement from fe80::rout:er1x:rout:er1x ← Router(1)のLLAから送出
# received by interface ens33
#

interface ens33
{
AdvSendAdvert on;            ← 周期的にルーター広告を送信し、ルーター要請にも応じる
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag off;          ← Mフラグ: RAを受信したホストが、RA以外の方法(DHCPv6など)によって自動的にアドレスを設定されることを許可するかどうか。許可しない。
AdvOtherConfigFlag on;       ← Oフラグ: RAを受信したホストが、RA以外の方法によってアドレス以外の情報を自動的に設定されることを許可するかどうか。許可する。
AdvReachableTime 0;          ← RAを受信したホストが持つ、隣接するIPv6ノードへの到達性の有効期間(ミリ秒)。無指定。
AdvRetransTimer 0;           ← RAを受信したホストがリンク層アドレス(MACアドレス)の問い合わせを行うメッセージを送信する時間。未指定。
AdvCurHopLimit 64;           ← RAを受信したホストのHop Limit値を指定する設定値。64。
AdvDefaultLifetime 9000;     ← RAを受信したホストがRAの送信元をデフォルトゲートウェイとして使用可能な有効期間。2時間半。
AdvHomeAgentFlag off;        ← RAを送信するルーターがIPv6ホームエージェントかどうか示す。機能しない。
AdvDefaultPreference medium; ← RAを送信するルーターの優先度。中。
AdvSourceLLAddress on;       ← RAを送信するときにローカルリンクアドレスを含める

prefix 24xx:xxxx:xxxx:xxxx::/64     ← サブネットプレフィックス(先頭64ビット)を表しているらしい
{
AdvValidLifetime 14400;     ← RAを受信したホストが、配信されたプレフィックスをIPv6アドレスの自動生成に使用できる期間。4時間。
AdvPreferredLifetime 12600; ← RAを受信したホストが、配信されたプレフィックスをIPv6アドレスの自動生成に使用することが推奨される期間。3時間半。
AdvOnLink on;               ← RAで配信されるプレフィックスが同一リンク上に存在するかどうか。存在する。
AdvAutonomous on;           ← RAを受信したホストが、IPv6アドレスを自動生成するために配信されたプレフィックス情報を使用できるかどうか。使用できる。
AdvRouterAddr off;          ← プレフィックスの代わりにインターフェースアドレスを送る指示(モバイルIPv6で利用)。しない。
}; # End of prefix definition

}; # End of interface definition
^C

※テスト用のUbuntu18.04で実行。

このRAだと、IPv6アドレスとゲートウェイはRAに基づいて自動構成し、DNS等の他の情報はDHCPv6から受け取る事になっている。

これを参考にしつつ Server で DHCPv6 を参照するようなRAを返すようにする。

いますぐ実践! Linux システム管理 / Vol.194

$ sudo apt install radvd

このサービスを動かすために設定ファイルを作成。インストール時に作られないため、自分で作る。

/etc/radvd.conf

#
# myhome settings
#

interface eth0
{
    AdvSendAdvert           on;

    AdvManagedFlag          on;
    AdvOtherConfigFlag      on;

    AdvDefaultPreference    low;

    prefix prefix fdxx:xxxx:xxxx:xxxx::/64
    {
        AdvAutonomous       off;
    };

};

RS(Router Solicitation/ルーター要請)とRA(Router Advertisement/ルーター広告)はICMPv6で送受信される。

ネットワークエンジニアとして / IPv6 - ICMPv6

ufwでポート開放の設定しなきゃ…と思ったけど、pingが飛んでるし、RSも受け取っている風に見えた。後からenableにしたりdisableにしたりして試したけど、動作に変わりなし。よって、ブロックはしていないと判断(これでいいのか？)。閉じている場合は、以下を参考にしながら開ける感じかな。

ubuntu forums / syslog full of UFW BLOCK PROTO=ICMPv6

ということで、サービス開始。

$ sudo systemctl start radvd ← 動いていないなら start 。動いていたら restart で。

テスト環境から配布内容を確認。

配布する情報の内容はこれで確認できる。

配布されているパケットを解析するらしく、表示されるまで時間がかかることも。

$ sudo radvdump ens33
#
# radvd configuration generated by radvdump 2.11
# based on Router Advertisement from fe80::serv:erse:rver:serv
# received by interface ens33
#

interface eth0
{
        AdvSendAdvert on;
        # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
        AdvManagedFlag on;     ← Mフラグ : アドレスを管理プロトコルで構成
        AdvOtherConfigFlag on; ← Oフラグ : 他の情報を管理プロトコルで構成
        AdvReachableTime 0;    ← 隣接ノードに可能な時間(ms)
        AdvRetransTimer 0;     ← 再送されたルーター要請が到達する時間(ms)
        AdvCurHopLimit 64;
        AdvDefaultLifetime 1800;
        AdvHomeAgentFlag off;
        AdvDefaultPreference medium;
        AdvSourceLLAddress on;

        prefix fdxx:xxxx:xxxx:xxxx::/64
        {
                AdvValidLifetime 86400;
                AdvPreferredLifetime 14400;
                AdvOnLink on;
                AdvAutonomous off; ← このプレフィックスは自動構成に利用できない
                AdvRouterAddr off;
        }; # End of prefix definition

}; # End of interface definition

狙い通りのRAが飛んでる。

■使ってみる

Windows、UbuntuからネットワークをON/OFFしたりなんかしてリース状況を確認しようと思ったが、isc-dhcp-serverがDNSを更新に行くタイミングがわからない。端末を再起動しても全然更新に行かない。変だなーと思ったら、renewの仕方が違った。

WIndowsでは以下。

VAIO / [Windows 10] IPアドレスを解放／再取得する方法

> ipconfig /renew  ← IPv4のアドレス再取得
> ipconfig /renew6 ← IPv6のアドレス再取得
> ipconfig /all
イーサネット アダプター ローカル エリア接続:

   接続固有の DNS サフィックス . . . . .: hogeserver.hogeddns.jp
   説明. . . . . . . . . . . . . . . . .: Realtek PCIe GbE Family Controller
   物理アドレス. . . . . . . . . . . . .: xx-xx-xx-xx-xx-xx
   DHCP 有効 . . . . . . . . . . . . . .: はい
   自動構成有効. . . . . . . . . . . . .: はい
   IPv6 アドレス . . . . . . . . . . . .: 24xx:xxxx:xxxx:xxxx:nnnn:nnnn:nnnn:nnnn(優先)
   IPv6 アドレス . . . . . . . . . . . .: fdxx:xxxx:xxxx:xxxx::2(優先)
・・・
   DNS サーバー. . . . . . . . . . . . .: fdxx:xxxx:xxxx:xxxx::100
                                          172.16.1.100
・・・ 

Ubuntuでは以下。

LinuxQuestions.org / commands to request and release of an IPv6 address from a dhcp server

Linux Fan / Ubuntuで「ネームサーバー」の設定を確認する方法

$ sudo dhclient -4 -r ens33 ; sudo dhclient -4 ens33
$ sudo dhclient -6 -r ens33 ; sudo dhclient -6 ens33
$ systemd-resolve --status
Global
          DNSSEC NTA: 10.in-addr.arpa
・・・
Link 2 (ens33)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 172.16.1.100
                      fdxx:xxxx:xxxx:xxxx::100
          DNS Domain: hogeserver.hogeddns.jp

※表示順序にかかわらず、先にリンクアップした方のDNSを先に参照する模様。

※いつの間にかDNS「flets-east.jp / iptvf.jp」が出なくなった。コンパイル後のインストールでなにか失敗しているのかもしれない。

リース状況を確認。

/var/lib/dhcp/dhcpd6.leases

・・・
ia-na "\xxxxx\xxx\xxx\xxx\xxx\xxx\xxx\xxx\xxx\xxxxx\xxx\xxx\xxx\xxx" {
  cltt 0 2018/11/25 03:14:57;
  iaaddr fdxx:xxxx:xxxx:xxxx::1:d00 {
    binding state active;
    preferred-life 54000;
    max-life 86400;
    ends 1 2018/11/26 03:14:57;
    set ddns-fwd-name = "MainPC.hogeserver.hogeddns.jp.";
    set ddns-txt = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
    set ddns-rev-name = "0.0.d.0.1.0.0.0.0.0.0.0.0.0.0.0.x.x.x.x.x.x.x.x.x.x.x.x.x.x.d.f.ip6.arpa.";
  }
}

ia-na "\xxx\xxx\xxxx\xxx\xxx\xxx\xxxx\xxx\xxx\xxx\xxx\xxxx\xxx\xxx\xxx" {
  cltt 0 2018/11/25 03:24:02;
  iaaddr fdxx:xxxx:xxxx:xxxx::1:947 {
    binding state active;
    preferred-life 7200;
    max-life 86400;
    ends 1 2018/11/26 03:24:02;
  }
}
・・・

ちゃんとホスト名が書き出されているのがWindows10の方で、ホスト名が書き出されていないのがUbuntuの方。

で、DNSへの反映状況を確認。

$ sudo rndc sync

/var/cache/bind/db.hogeserver.zone

・・・
MainPC                  A       172.16.1.2
                        TXT     "02b5xxxxxxxxxxxxxxxxxxxxxxxxxxxx07"
                        AAAA    fdxx:xxxx:xxxx:xxxx::2
temp                    A       172.16.1.11
                        TXT     "02e7xxxxxxxxxxxxxxxxxxxxxxxxxxxx47"
                        AAAA    fdxx:xxxx:xxxx:xxxx::1:947
・・・

しっかりと反映してる。

ただ、テストの最中、Ubuntuの側は何度やってもDNSに反映されなかった。

時間をおいてから再起動してIPアドレスを取ってみたら反映されているという…

ただね、もう調査に疲れたよパトラッシュ。もう動いてるからカンベンしてちょ！

若干気になる部分はあるものの、完成。

■いろいろ調べたこと(1)

IPv6のルーティングテーブル確認方法。

いつか、そのとき、あの場所で。 / [Linux][IPv6] IPv6でのルーティングテーブルの確認コマンド。

Linux IPv6 HOWTO (en) / 7.1. Displaying existing IPv6 routes

$ route -n6
$ ip -6 route

■いろいろ調べたこと(2)

/etc/network/interface のファイルをいじってIPアドレスを変えたりしたとき以下のエラーが発生する。

11月 17 17:40:03 hogeserver ifup[6796]: RTNETLINK answers: File exists
11月 17 17:40:03 hogeserver ifup[6796]: Failed to bring up eth0:1.

こちらの情報で対策。

R42日記 / "RTNETLINK answers: File exists"を解消する

$ sudo ip addr flush dev eth0

で、根本原因はこれ。コメント化して解消。まぁ、いらない設定ではあった。

/etc/network/interface

auto eth0:1
iface eth0:1 inet static
address 172.16.1.100
netmask 255.255.0.0
#gateway 172.16.2.1
#dns-nameservers 127.0.0.1

■いろいろ調べたこと(3)

/etc/network/interface をいじってもうまく反映されないことがあって、(2)から継続して検索してみたところ、以下を発見した。

SERVER FAULT / “RTNETLINK answers: File exists” /etc/network/interfaces Does'nt contain 2 gateways, so what's wrong?

$ sudo ifdown eth0 && sudo ifup eth0

IPアドレスがうまく変わらないといった問題はこれで回避できた。

■いろいろ調べたこと(4)

IPv6でインターネットに向けてサービスを提供するに当たり、IPv6の固定IPアドレスを振る必要があった。だけど、手動でIPアドレスを振ってもインターネット側にpingが通らない。

$ ping6 google.co.jp
connect: Network is unreachable

で、ルーティングテーブルを調べてみた。IPv6アドレスを自動構成させると以下の通りとなる。

完全手動で設定したときには黄色の行がない。

$ ip -6 route
24xx:xxxx:xxxx:xxxx::100 dev eth0  proto kernel  metric 256  pref medium
24xx:xxxx:xxxx:xxxx::/64 dev eth0  proto kernel  metric 256  expires 14328sec pref medium
fc00::/64 dev eth0  proto kernel  metric 256  pref medium
fe80::/64 dev eth0  proto kernel  metric 256  pref medium
default via fe80::xxxx:xxxx:xxxx:xxxx dev eth0  proto ra  metric 1024  expires 8928sec hoplimit 64 pref medium

fe80::xxxx:xxxx:xxxx:xxxx は、Router(1)に払い出されているIPv6アドレスの下64ビットが書かれている。Router(1)を再起動したら変わってしまうかもしれない番号だ(と思われる)。

ということから、IPv6アドレスは自動構成のものも作ることとした。

そもそもIPv6は1つのNICが複数のIPアドレスを持つ前提(グローバルアドレスとローカルリンクアドレスとか)だから、大した問題にはならない想定。

実際に手動設定したIPv6アドレスからpingが飛ぶのか確認した。

$ ping6 google.co.jp -I 24xx:xxxx:xxxx:xxxx::100
PING google.co.jp(aaaaaaaa.net) from 24xx:xxxx:xxxx:xxxx::100 : 56 data bytes
64 bytes from aaaaaaaa.net: icmp_seq=1 ttl=52 time=7.13 ms
…

よし、飛んでる、大丈夫！

ちなみにルートを追加する場合は以下。サーバーのmetricは256が基本になっているようだったから、ルートを追加するときにも256を指定してみた(未指定だと1000になる)。ま、これだけじゃインターネットには出られないが、将来完全にmanualな設定をする場合に備えてメモメモ。

$ sudo ip -6 route add 24xx:xxxx:xxxx:xxxx::/64 dev eth0 metric 256

■いろいろ調べたこと(5)

/etc/network/interface に以下のように固定IPを入れたところ、ifdownコマンドで怒られる。

auto eth0
・・・
iface eth0 inet6 auto
 post-up  ip -6 addr add 24xx:xxxx:xxxx:xxxx::100/128 dev $IFACE
 pre-down ip -6 addr del 24xx:xxxx:xxxx:xxxx::100/128 dev $IFACE
 post-up  ip -6 addr add fc00::100/64 dev $IFACE
 pre-down ip -6 addr del fc00::100/64 dev $IFACE
 post-up  ip -6 addr add fe80::100/64 dev $IFACE
 pre-down ip -6 addr del fe80::100/64 dev $IFACE

実行結果はこれ。

$ sudo ifdown eth0 && sudo ifup eth0
RTNETLINK answers: Cannot assign requested address
RTNETLINK answers: Cannot assign requested address
RTNETLINK answers: Cannot assign requested address

ifdown時にIPv6アドレスを削除しなきゃいけないと思っていたが、削除しなくても結果は同じだったので消しちゃった。

auto eth0
・・・
iface eth0 inet6 auto
 post-up  ip -6 addr add 24xx:xxxx:xxxx:xxxx::100/128 dev $IFACE
#pre-down ip -6 addr del 24xx:xxxx:xxxx:xxxx::100/128 dev $IFACE
 post-up  ip -6 addr add fc00::100/64 dev $IFACE
#pre-down ip -6 addr del fc00::100/64 dev $IFACE
 post-up  ip -6 addr add fe80::100/64 dev $IFACE
#pre-down ip -6 addr del fe80::100/64 dev $IFACE

■いろいろ調べたこと(6)

テスト用にVMware PlayerでUbuntu18.04デスクトップを構築した。で、ちょっと放って置くとすぐに画面がロックされてしまう。

設定は2箇所。

設定 → プライバシー → 画面ロック でロックしないようにする。

設定 → 電源 → 省電力 → ブランクスクリーン で「しない」を選択。New!

どこに行っても1つ目は書かれているんだけど、2つ目もやっておかないと画面が暗くなってしまう。復帰時には画面を上にスライドする必要があり(エンターキーでも行けるけど)、いちいち面倒くさいので設定した。

■いろいろ調べたこと(7)

記事を書いている上で、radvdumpコマンドがどのパッケージに含まれているのかを確認したくなった。既にインストールされちゃってたりするので、インストール済みのパッケージから調べたかった。

それマグで！ / あるコマンドが含まれるパッケージを探す。apt-file/dpkg

$ dpkg -S $(which radvdump)
radvd: /usr/sbin/radvdump

apt-fileをよく見かけるが、既にインストールされているパッケージを探すならこの方がいいように思った。apt-fileパッケージを入れなくて済むし。

■いろいろ調べたこと(8)

良い機会なので、ゾーンファイルを整理した。

基本的にはDHCPでIPアドレスを振り出しているのだから、固定なIPのものだけを書き出しておけば、いずれ(具体的には1日)で整理されるはずだ。

チェック方法はココで教えてくれた。

お便利サーバー.com / 設定ファイルの書式チェックコマンドについて

$ named-checkzone hogeserver.hogeddns.jp /var/cache/bind/db.hogeserver.zone

※ゾーン名とゾーンファイルを指定して実行。

そして、DDNS環境において、直接ゾーンファイルを編集するためにはBINDを止めなければならない。止めないで作業するにはコマンドを用いる(DHCPがやっていることと同じようにkeyを使って更新)。

Qoosky / BIND 9 ゾーンファイル Dynamic Update の設定方法

人力検索はてな / bindのjnlファイル(Journalファイル)をゾーンファイルに反映させて、クリア(削除)する方法を探しています。

$ nsupdate -k /etc/dhcp/ddns-keys/rndc.key
> update add temp.hogeserver.hogeddns.jp 3600 A 172.16.1.11
> ← これで更新がかかる(sendの省略形？)
> update delete temp.hogeserver.hogeddns.jp A
>
> update delete temp.hogeserver.hogeddns.jp AAAA
>
> update delete temp.hogeserver.hogeddns.jp txt
>

※keyファイルにアクセスできる権限が必要。

だが、利用者も少ない中、コマンドによる更新は手間がかかるばっかりで面倒と思った。

色々とやっている中で更新時に発生するエラーがあって、それを検索したら自分の過去記事が出てきた。

Ubuntu 14.04 ログに出ているエラーへの対処メモ

$ sudo rndc sync; sudo rndc freeze ← キャッシュをファイルに吐き出して更新を止める
この間にファイルを更新。

$ sudo rndc thaw ← 更新を再開

■いろいろ調べたこと(9)

Windows10で ipconfig /renew6 をすると、ものずごく時間がかかる。

しかし、サーバーで見ているとWindows10へのアドレスの振り出しはさっさと終わっていて、DNSにも反映されてる…。

>ipconfig /renew6

Windows IP 構成

インターフェイス VMware Network Adapter VMnet1 の更新中にエラーが発生しました:  セマフォがタイムアウトしました。

インターフェイス VMware Network Adapter VMnet8 の更新中にエラーが発生しました:  セマフォがタイムアウトしました。

サーバーを見たらこんなログが出ていた。

Nov 25 15:48:41 hogeserver kernel: [14539.006818] [UFW BLOCK] IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx DST=ff02:0000:0000:0000:0000:0000:0001:0003 LEN=81 TC=0 HOPLIMIT=1 FLOWLBL=1017758 PROTO=UDP SPT=60594 DPT=5355 LEN=41

これは、LLMNR(Link-Local Multicast Name Resolution)という名前解決の方法らしい。

＠IT / 第6回　LLMNRを使ったローカル・セグメント上での名前解決

ウチの中にはこんなIPアドレスの解決方法は用意していない。DNSがあるからいらないっしょ。VMware Player をバージョンアップしないで使い続けているからこんなことになるのかな、と調べることも諦めた。

■いろいろ調べたこと(10)

設定で試行錯誤しているとき、DHCPv6からどうしてもIPアドレスが振り出されずに困った。

いつか、そのとき、あの場所で。 / [Windows10][ #ipv6 ][ #ipv6study] やっぱりDHCPv6ステートレスモードでDNSサーバ情報が受け取れなくなったけど解決した

もう、この問題発生から1週間以上が経過…これで問題が解決したのか、設定を修正したら解決したのかが思い出せないけれど、転ばぬ先の杖としてメモ。

長かった～。UbuntuでもまだデュアルスタックでDDNSな環境を作るのにはこんなに時間がかかるのね。知識が足りないのは否定しないが、問題にぶち当たってからしか情報が得られないのはもしかしたら自宅サーバー運営開始以来はじめてのことだったかもしれない。

で、IPv6について色々と調べて思ったことは、IPv6でアクセスできるサイトはまだまだ少ないんだなーということ。ほとんどIPv6対応していないといっても過言ではない感じ。

実は当初、インターネットに向けてIPv6でサービス公開することを目指していた。しかし、いざ、テストしてみようと思ったら「IPv6でインターネットから自宅に向けてアクセスする」方法がなかったのて諦めるしかなかった。

こう書きながら思ったことは「IPv6化はなかなか進まないだろうな」ということ。苦労しても実りが少なすぎる…。その点でv6プラスサービスはIPv4でのアクセスが飛躍的に早くなる上に、意識しなくてもIPv6対応機器を持っていればIPv6アクセスもできるから、IPv6の普及を促進するんだろうなと思った。

前回の記事でIPv4とIPv6のデュアルスタックにしてみた。どうやらシステムはうまく動き出したぞ！ということでpingしてみる。

>ping hogeserver

hogeserver.hogeserver.hogedns.jp [172.16.1.100]に ping を送信しています 32 バイトのデータ:
172.16.1.100 からの応答: バイト数 =32 時間 <1ms TTL=64
172.16.1.100 からの応答: バイト数 =32 時間 <1ms TTL=64
172.16.1.100 からの応答: バイト数 =32 時間 <1ms TTL=64
172.16.1.100 からの応答: バイト数 =32 時間 =1ms TTL=64

172.16.1.100 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 0ms、最大 = 1ms、平均 = 0ms

おっとっと…

Windows10のIPv4/IPv6の優先度については完全な答えがココにある。

パソコンたすかるHowTo / IPv6の優先度の変更

コマンドはともかく、その表示結果について書かれていることに加えてもう少し調べてみた。

>netsh interface ipv6 show prefixpolicies
アクティブ状態を照会しています...

優先順位   ラベル  プレフィックス
----------  -----  --------------------------------
        50      0  ::1/128
        40      1  ::/0
        35      4  ::ffff:0:0/96
        30      2  2002::/16
         5      5  2001::/32
         3     13  fc00::/7
         1     11  fec0::/10
         1     12  3ffe::/16
         1      3  ::/96

さて…今になるとようやくこのページの意味がわかり始めた…

Wikipedia / IPv6アドレス 2018/12/1現在。

この上、接続にはより小さいスコープが優先されるため、ローカルリンクアドレスの優先度が高いとのこと。

ここまで学習してきたところで考えてみると、なぜユニークローカルアドレスの優先度が3に設定されているのかがうまく理解できない。IPv6優先ならばIPv4よりもULAが優先されるべきと思われるが、探してみたけれども理由が見つからなかった。ローカルの話なんだから、グローバールユニークアドレスよりも優先されていいんじゃないかとすら思う。

試しにコマンドプロンプトを「管理者として実行」し、プライオリティを変えてみると…

>netsh interface ipv6 set prefixpolicy fc00::/7 41 13
OK                                     ↑プレフィックス 優先順位 ラベル

>netsh interface ipv6 show prefixpolicies
アクティブ状態を照会しています...

優先順位   ラベル  プレフィックス
----------  -----  --------------------------------
        50      0  ::1/128
        41     13  fc00::/7 ← ココに持ってきてみた
        40      1  ::/0
        35      4  ::ffff:0:0/96
        30      2  2002::/16
         5      5  2001::/32
         1     11  fec0::/10
         1     12  3ffe::/16
         1      3  ::/96

>ping hogeserver

hogeserver.hogeserver.hogeddns.jp [fdxx:xxxx:xxxx:xxxx::100]に ping を送信しています 32 バイトのデータ:
fdxx:xxxx:xxxx:xxxx::100 からの応答: 時間 <1ms
fdxx:xxxx:xxxx:xxxx::100 からの応答: 時間 =1ms
fdxx:xxxx:xxxx:xxxx::100 からの応答: 時間 <1ms
fdxx:xxxx:xxxx:xxxx::100 からの応答: 時間 <1ms

fdxx:xxxx:xxxx:xxxx::100 の ping 統計:
    パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
    最小 = 0ms、最大 = 1ms、平均 = 0ms

ULAでアクセスができた。

もちろん、インターネットにもIPv6で出ていくことが確認できた。

ここからは単なるメモ。未解決。

Ubuntuでも完全な答えがココにある。

パソコンたすかるHowTo / IPv6の優先度の変更

だが、私が試してみたところでは、実際に優先度が変わることはなかった。

とりあえず設定方法を理解したつもりになったところで、こたつでPC(Ubuntu14.04ベースのBean)してみたらIPv4はDHCPv4から取得するしDDNSも機能するのだが、IPv6はDHCPv6から取得できず、ルーター発信のRAに基づくアドレスの自動構成のみ行っていた。

そのため、まず、バージョンによる差異はないのか試してみた。

Ubuntu18.04-desktop-amd64をミニマムインストール。インストール直後は IPv6 で通信。

ubuntu-mate-16.04.4-desktop-amd64をインストール。インストール直後はIPv4で通信。ping6は通る。/etc/gai.confをいじって再起動しても変化なし。

ubuntu-ja-14.04-desktop-amd64をインストール。IPv6はDHCPv6から取得できなかった。IPv6の設定をDHCPのみにするとようやくアドレスが取得できるが、ping6もできない状態。

いやいやおかしいよね、そんなはずないよね…とNetworkManagerの扉を開くことに。

NetPlanはとっても言うことを聞いてくれる感じがあって良いのだけれど、NetworkManagerとはうまく付き合ってこられなかったので、ここで色々と確認してみようと思った。

そもそもNetworkManagerというのは何なのか…

Wikipedia / NetworkManager

当時利用するのをやめようと思ったのは仕方がなかった、ちょっとわからない。

以下に書かれているのが概要を表しているように思う。

redhat / 第8章 NETWORKMANAGER

NetworkManager (ネットワークマネージャ) は、ネットワークデバイスと接続が利用可能な時にそれらをアクティブに維持するよう試行する動的ネットワーク制御及び設定システムです。NetworkManager は、コアデーモン、ネットワークステータス情報を提供する GNOME 通知スペースアプレット、及び接続とインターフェースの作成、編集、削除が可能なグラフィカル設定ツールで構成されています。NetworkManager を使用すると、イーサネット、ワイヤレス、モバイルブロードバンド (携帯 3G など)、DSL や PPPoE (Point-to-Point over Ethernet イーサネット経由のポイントツーポイントプロトコル) のようなタイプの接続を設定できます。さらに、 NetworkManager により、ネットワークエイリアス、静的ルート、DNS 情報、VPN 接続の他、多くの接続固有のパラメータの設定が可能になります。そして、NetworkManager は D-Bus により効果的な API を提供するため、アプリケーションはネットワークの設定と状態をクエリ、制御することができます。

NetworkManagerとGUI、コマンドラインツール、コマンドラインGUIツールからなっている。

@It / CentOS 7のネットワーク管理「NetworkManager」を極める (1/5)

Ubuntu14.04で動作しているのは0.9.8.8。

$ NetworkManager --version
0.9.8.8

DHCPv6のみを受け取るようにしたところ、配布されたアドレスを使うようになる。

で、もとに戻したらDHCPv6と自動構成が行われるようになる。

で、2日後に起動してみたらこんな事になった。

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.101/16 brd 172.16.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/128 scope global ← これは今日取得したIPv6のアドレス
       valid_lft forever preferred_lft forever
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/128 scope global ← これは最初に取得したIPv6のアドレス
       valid_lft forever preferred_lft forever
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global temporary dynamic 
       valid_lft 14040sec preferred_lft 12240sec
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic 
       valid_lft 14040sec preferred_lft 12240sec
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

で、宅内へのpingを試してみた。pingはIPv4で動作し、ping6するとIPv6で動作した。

しかし、ココで気づく。なんで、DHCPからもらったアドレスがforeverなのよ？全然理解できないよこれ。

よくわからないから、アップデートを全部適用してみた。で、再起動してみた。しかし結果は、古いIPv6アドレスがなくなっただけで、ほかは何も変わらなかった。foreverだよ、なんでだよ。

NetworkManagerはDHCPクライアントを取り込もうとしているらしく、リースファイルは/var/lib/NetworkManagerにあった。dhclientの設定ファイルから自分で必要な物を取り出して設定ファイルなんかも作っていた。

有線接続を無効にすると、IPv4のDHCPクライアント設定は消えるが、IPv6のDHCPクライアント設定は消えなかった。確認してみたら、IPv6のローカルスコープのアドレスは残っていた。

ネットワークを無効にすると、IPv4とIPv6のDHCPクライアント設定が消えた。

さらに、/var/lib/NetworkManagerの中にleasesファイルが6つあった。

ファイル名は以下な感じ。

dhclient-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-eth0.lease
dhclient-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-eth0.lease
dhclient-fxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx4-eth0.lease
dhclient6-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-eth0.lease
dhclient6-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-eth0.lease
dhclient6-fxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx4-eth0.lease

dhclient-ああああ-eth0.lease のところの「ああああ」は、UUIDとのことで、これは/etc/NetworkManager/system-connections の中にあるファイルに書かれているんだそうな。

UUIDが3回も変わってたのか…あー、もう、本当にわからないわ。

Linuxの缶詰 / Network ManagerとUUIDについて

調べて教えてくれている人がいました。何かの理由でネットワークインターフェースをコントロールできないと、UUIDを作って割り当てコントロール配下においているみたい。思い当たる操作といえば、アップデートを掛けたことくらいかなぁ。

試しに、NetworkManagerのinternalなDHCPクライアントを利用してみたところで、DHCPv6のアドレスが作れないときにはV6のleaseファイルが更新されていないことに気づいた。

GUIでネットワークを無効にして…

/etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifupdown,keyfile,ofono
dns=dnsmasq

no-auto-default=xx:xx:xx:xx:xx:xx,

dhcp=internal

[ifupdown]
managed=false

GUIからネットワークを有効に。

$ ll /var/lib/NetworkManager
-rw-r--r--  1 root root   86 12月  9 08:17 NetworkManager.state
-rw-r--r--  1 root root 2291 12月  9 08:17 dhclient-eth0.conf
-rw-r--r--  1 root root  994 12月  9 08:17 dhclient-fxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx4-eth0.lease
-rw-r--r--  1 root root  304 12月  9 08:17 dhclient6-eth0.conf
-rw-r--r--  1 root root 1001 12月  8 21:22 dhclient6-fxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx4-eth0.lease
-rw-r--r--  1 root root  157 12月  9 08:17 timestamps

あぁ、RAが2種類飛んできたときの動作をちゃんと定義できていない可能性。

nmcliはこんな感じで使うみたい。

$ sudo nmcli nm enable false ← ネットワークを無効化
$ sudo nmcli nm enable true  ← ネットワークを有効化
$ sudo nmcli nm              ← ネットワークの状態確認(引数にstatusを付けても同じ動作)
実行中          状態            WIFI ハードウェア WIFI       WWAN ハードウェア WWAN      
実行中          接続済み        有効            有効       有効            有効      
$ nmcli device wifi list     ← 飛んでいるWifiの状態一覧(Wifi装置がなかったので何も出なかった)
SSID                              BSSID               モード           周波数     レート     信号     セキュリティ アクティブ
$ nmcli device list          ← デバイスの一覧が出てくる
GENERAL.デバイス:                   eth0
GENERAL.タイプ:                      802-3-ethernet
GENERAL.ベンダー:                   Advanced Micro Devices, Inc. [AMD]
…<省略>
$ nmcli device disconnect iface eth0 ← デバイスを指定して切断(IPv6のLLAは残る)
$ nmcli con up id 有線接続\ 1        ← IDを指定して接続
$ nmcli con down id 有線接続\ 1      ← IDを指定して切断(だけど自動接続することを禁じないためにすぐに再起動する)

Wifi装置がなくても、WifiハードウェアもWifiも有効と言われる。

WWANってのはワイヤレスWANだそうで、キャリアの通信SIMとかを指して使う感じ？

さらに2日後、起動してみてDHCPクライアントの動作を見てみようと思った…

FreeKB / Obtain, renew, and release IP address using DHCLIENT command in Linux

$ cat /var/lib/dhcp/dhclient.leases
$

からっぽ？これはおかしい…IPアドレスをリリースするコマンドを叩いてもリリースできない。これは絶対変だ。

参照先のページでAvahiを止めて無効化すると書かれていた。調べてみると、お互いに自分の状態を伝えあって名前解決ができるようにする仕組みの模様。mDNSという。

ウチは全てをコントロールしようとしてDHCPを立ててDNSも動かしており、iPhone/iPadとプリンタとかが勝手にやり取りし合うことを止めることまではしないけれど、WindowsやLinuxでこのサービスを使う理由はまったくない状況。

そこで、avahi-daemonを止めることにした。

$ sudo apt install sysv-rc-conf
$ sudo sysv-rc-conf

avahi-daemonが起動しないように設定して再起動してみる。

・・・・・・avahi-daemonが起動してる。

仕方がないので、消して再起動。

$ sudo apt remove avahi-daemon

・・・・・・avahi-daemonが起動してる。本当にしぶとい。

$ sudo apt remove avahi-autoipd

まだ起動している。本当にどうなっているんだろう？

$ sudo apt remove avahi-daemon --purge
$ sudo apt remove avahi-autoipd --purge

これにより、/etc/network/if-up.d にあったavahi-daemonとavahi-autoipdが消えて起動しなくなった。

しかし、これでもリースファイルの中身は空っぽのまま。それでいてDHCPからIPアドレスが振り出されている。なぜ？

その後、再起動したところ、優先接続 1が有効にならずどこにもいけなくなった。

さらにメモ。

ガンガンテストしようとしたら、とにかくUbuntuのインストールが必要に。

都度SSHを設定するのも面倒だから、vmware-tools をインストールして色々と楽にしたかった。

kashiの日記 / ubuntu 16.04 インストール(2) vmware tools

$ sudo apt install open-vm-tools open-vm-tools-desktop
$ sudo reboot

これは大変ありがたい知識だった。

最後に。

まぁ、やりたいことができなかった愚痴なんですが、これじゃIPv6の普及って難しいのかなぁって思った。

IPv6オンリーなPCを作るとアクセスできないサイトが多数だし、IPv6オンリーなサーバーを作ってもテストのためのテザリングがIPv6に対応してない。IPv6でサービスを立てても外からアクセスできないじゃん。

宅内のIPv6だって実際には外から管理されてるわけで、自分の思い通りにしようと思ってもなかなかうまくいかない。どうにかしてサーバーを立てても、今度はクライアントが思い通りに動かない…と。

IPv4の枯渇って結局どうなったんだろう？

Openmeetingsのフル機能がライセンス的な意味で会社で使えなくなって2ヶ月がたとうとしているある日曜日、オープンソースなWeb会議システムを試してみようと考えた。

その名は Jitsi で、なんか面白そうな感じがする。

※今回、Chromeでカメラが使えない問題が発生した。どうやら、JitsiでもChromeでもなくWindowsが原因だった模様、解決できた。これは仕方ないかなぁ…最後の方で顛末を記している。

Jitsiの特徴は、インストールが簡単であること。また、ブラウザですれば簡単に会議室が開け、そのURLに他の人がアクセスするだけで会議に参加できること。

画面の共有はできるがOpenmeetingsのように相手に制御を渡すことはできない。また、Openmeetingsのようなホワイトボード機能やスケジュール機能はない。

Flash Playerは使わないし、JNLPを使うこともないので、追加で何かをインストールする必要もなさそう。

ってな具合。とっても良いと思う。

・学習
・インストール(Ubuntu16, Ubuntu18)
・他サービスとの共存を考える
・ユーザー認証を追加する
・アンインストール(再設定の時とかに必要になりそうだから)
・起きたこと

まずは学習だ。

Jitsi / New tutorial: Installing Jitsi Meet on your own Linux Server

Youtubeは凄いなー、テロップを自動で出すだけでなく、それを翻訳できる訳で…俺でもわかる！

このチュートリアルは Ubuntu 16.04 LTS へのインストールをしているようなので、仮想環境で作成。

インストール時にはOpenSSH Serverを選択し、インストール後に以下を行う。

• アップデートを全部インストールしておく。


• SSHで接続できるようにする。

チュートリアルでは以下が説明されていた…ように思われる。

• ルートユーザーでアクセスできるようにする。
  
  この後の操作は su - した後に行われている。


• ファイアウォールでTCPの22,80,443、およびUDPの10000-20000を解放する。
  
  ufw enable
  
  ufw allow in ssh
  
  ufw allow in 80/tcp ←でも80番ポートは使わないんじゃね？
  
  ufw allow in 443/tcp
  
  ufw allow in 10000:20000/udp


• モジュールをインストールするために鍵を読み込み、リポジトリを登録する。
  
  鍵をダウンロードする。
  
  wget https://download.jitsi.org/jitsi-key.gpg.key
  
  鍵を追加する。
  
  apt-key add jitsi-key.gpg.key
  
  ※本当は鍵を確認する手順が説明されているけど、ここでは省略した。


• リポジトリを追加する。
  
  echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list
  
  SSLによる暗号化を必要とするので、サーバーの証明書を用意する。
  
  すでにあるものを使ったり、Let's Encryptを利用したり、自己署名証明書を利用する。


• WebサーバーはnginxやApacheが利用できる、ブリッジさせる感じ？先にインストールしておく。パッケージインストール時に必要な設定がなされる。
  
  apt install nginx
  
  apt install apache2


• パッケージをインストールする。
  
  apt update
  
  apt install jisti-meet


• インストーラーがホストについて訪ねてくる。
  
  FQDN名やIPアドレスを入力する。IPアドレスを入力すると、その後はIPアドレスしか受け付けない。
  
  証明書はどうするか訪ねてくる。
  
  チュートリアルは生成することを選んでいる。
  
  うちの場合は自己署名証明書を使うので、I want to use my own certificate を選べば良さそう。


• ブラウザでアクセスして試す。

Ubuntu16.04でホスト名が使える場合

とりあえず、やってみた。

SSLが必要だから、事前にサーバーの証明書を用意しておく。過去記事ベースに作成。

$ sudo passwd ← rootのパスワード設定
$ su - ← rootになる
# ufw enable ← ファイアウォール設定
# ufw allow in ssh
# ufw allow in 443/tcp
# ufw allow in 10000:20000/udp
# ufw status ← 設定結果の確認
# wget https://download.jitsi.org/jitsi-key.gpg.key ← GPGキーのダウンロード
# apt-key add jitsi-key.gpg.key ← GPGキーの登録
# echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list ← リポジトリ追加
# apt update
# apt install nginx   ← WebサーバーにNginxを使う場合(どちらか一方)
# apt install apache2 ← WebサーバーにApacheを使う場合(どちらか一方)
# apt install jitsi-meet

インストール中の問い合わせ
The hostname of the current installation:
→ temp.hogeserver.hogeddns.jp

SSL certificate for the Jitsi Meet instance
→ I want to use my own certificate ※この選択はチュートリアルとは違っている

Full local server path to the SSL key file:
→ /etc/ssl/temp.hogeserver.hogeddns.jp.key ※SSLキーファイルをこのタイミングで要求している

Full local server path to the SSL certificate file:
→ /etc/ssl/temp.hogeserver.hogeddns.jp.crt ※SSL証明書ファイルをこのタイミングで要求している

これでインストールは終了。だけど、再起動しないとうまく動かない。

# reboot

ブラウザから https://temp.hogeserver.hogeddns.jp にアクセスするとサービスに接続できる。

会議名を適当に入れて会議室を作る…すると、マイクとカメラへのアクセスを求められる。

これだけで起動するし動作する。超簡単。

ちなみに、Apacheの場合、以下のようなサイトが作られて有効になっていた。

/etc/apache2/sites-enabled/temp.hogeserver.hogeddns.jp.conf

<VirtualHost *:80>
    ServerName temp.hogeserver.hogeddns.jp
    Redirect permanent / https://temp.hogeserver.hogeddns.jp/
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

<VirtualHost *:443>

  ServerName temp.hogeserver.hogeddns.jp

  SSLProtocol TLSv1 TLSv1.1 TLSv1.2
  SSLEngine on
  SSLProxyEngine on
  SSLCertificateFile /etc/ssl/temp.hogeserver.hogeddns.jp.crt
  SSLCertificateKeyFile /etc/ssl/temp.hogeserver.hogeddns.jp.key
  SSLCipherSuite "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  SSLHonorCipherOrder on
  Header set Strict-Transport-Security "max-age=31536000"

  DocumentRoot "/usr/share/jitsi-meet"
  <Directory "/usr/share/jitsi-meet">
    Options Indexes MultiViews Includes FollowSymLinks
    AddOutputFilter Includes html
    AllowOverride All
    Order allow,deny
    Allow from all
  </Directory>

  ErrorDocument 404 /static/404.html

  Alias "/config.js" "/etc/jitsi/meet/temp.hogeserver.hogeddns.jp-config.js"
  <Location /config.js>
    Require all granted
  </Location>

  ProxyPreserveHost on
  ProxyPass /http-bind http://localhost:5280/http-bind/
  ProxyPassReverse /http-bind http://localhost:5280/http-bind/

  RewriteEngine on
  RewriteRule ^/([a-zA-Z0-9]+)$ /index.html
</VirtualHost>

これらの設定をいろんなところに探しにいって、古い情報なのか新しい情報なのか確認しながら試行錯誤しなきゃならない…としたら大変だ。その点、このパッケージは本当に簡単に使えるので感謝である。

Ubuntu18.04でホスト名が使える場合

あまりに簡単だったから会社でも使ってみたい。

ホスト名を同じにしてSSLは16.04の時に作ったものを流用、パッケージは全てアップデートしておいた。

Ubuntu16.04との違いは、openjdk-8-jre-headlessを手でインストールすること。

$ sudo passwd ← rootのパスワード設定
$ su - ← rootになる
# ufw enable ← ファイアウォール設定
# ufw allow in ssh
# ufw allow in 443/tcp
# ufw allow in 10000:20000/udp
# ufw status ← 設定結果の確認
# wget https://download.jitsi.org/jitsi-key.gpg.key ← GPGキーのダウンロード
# apt-key add jitsi-key.gpg.key ← GPGキーの登録
# echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list ← リポジトリ追加
↓↓ Ubuntu18.04の場合のみ追加。OpenJDK-8がインストールできないから ↓↓
# echo 'deb http://archive.ubuntu.com/ubuntu bionic universe' > /etc/apt/sources.list.d/openjdk-8.list
# apt update
# apt install nginx   ← WebサーバーにNginxを使う場合(どちらか一方)
# apt install apache2 ← WebサーバーにApacheを使う場合(どちらか一方)
↓↓ Ubuntu18.04の場合のみ追加。OpenJDK-8が入っていないから ↓↓
# apt install openjdk-8-jre-headless
# apt install jitsi-meet

インストール中の問い合わせ
The hostname of the current installation:
→ temp.hogeserver.hogeddns.jp

SSL certificate for the Jitsi Meet instance
→ I want to use my own certificate ※この選択はチュートリアルとは違っている

Full local server path to the SSL key file:
→ /etc/ssl/temp.hogeserver.hogeddns.jp.key ※SSLキーファイルをこのタイミングで要求している

Full local server path to the SSL certificate file:
→ /etc/ssl/temp.hogeserver.hogeddns.jp.crt ※SSL証明書ファイルをこのタイミングで要求している

これでインストールは終了。だけど、再起動しないとうまく動かない。

# reboot

これで利用できる。

Ubuntu18.04でIPアドレスしか使えない場合

会社で使おうとするとき、内向きDNSにサービス登録するのが本来の形。

だけど正式に使うと宣言するまでのテスト段階では、IPアドレスでサービス提供したいな。

この場合、インストールの途中の問い合わせで…

インストール中の問い合わせ
The hostname of the current installation:
→ 172.16.nnn.nnn

とサービスを提供するIPアドレスを入力するだけ。

他のサービスと共存させる

ホスト名で名前解決できる環境ならば、ApacheでいうところのVirtualHostで、別の名前でサービス提供するのが良いと考えられる。サブディレクトリ？は全て「会議室の名前」として利用されるため、サブディレクトリでサービスを分けることができないから。

IPアドレスでアクセスする環境の場合、同様の理由から別のIPアドレスを追加してサービス提供するのが良いと考えられる。

ユーザー認証を追加する

Jitsiはアクセスさえできれば誰でも簡単に会議室を作ることができる。ただ、この状態でインターネットにサービスを公開したいとは思わないから…ユーザー認証機構を入れてみようと考えた。

Jitsiの場合、認証されたユーザーだけが会議室を作ることができるようにするようだ。その会議室には誰でも入ることができるが、会議室にパスワードを掛ければ利用者を限定できるよね、ということらしい。

で、その認証はXMPPサーバーで行うらしい。XMPP(Extensible Messaging and Presence Protocol)はサーバーを自由に立てることができ、メールサーバーのように他のXMPPサーバーと連携できる模様。XMPPサーバーはProsody。

# systemctl status prosody
● prosody.service - LSB: Prosody XMPP Server
   Loaded: loaded (/etc/init.d/prosody; generated)
   Active: active (running) since Sun 2019-03-24 05:31:06 UTC; 29min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 929 ExecStart=/etc/init.d/prosody start (code=exited, status=0/SUCCESS)
    Tasks: 1 (limit: 9472)
   CGroup: /system.slice/prosody.service
           mq1243 lua5.1 /usr/bin/prosody

Mar 24 05:31:03 temp systemd[1]: Starting LSB: Prosody XMPP Server...
Mar 24 05:31:04 temp prosody[929]:  * Starting Prosody XMPP Server prosody
Mar 24 05:31:06 temp prosody[929]:    ...done.
Mar 24 05:31:06 temp systemd[1]: Started LSB: Prosody XMPP Server.

なるほど。

Github / jitsi/jicofo に設定方法が書いてあって…

/etc/prosody/conf.avail/temp.hogeserver.hogeddns.jp.cfg.lua

(ホスト名は設置する場所に置き換える)

VirtualHost "temp.hogeserver.hogeddns.jp"
        -- enabled = false -- Remove this line to enable this host
        -- 認証方法変更
        -- authentication = "anonymous"      ← コメント化
        authentication = "internal_plain"    ← 追加
        -- Properties below are modified by jitsi-meet-tokens package config

-- ファイルの最後にこれらを追加
VirtualHost "guest.temp.hogeserver.hogeddns.jp"
    authentication = "anonymous"
    c2s_require_encryption = false

Prosodyを再起動してみる。

# systemctl restart prosody
# systemctl status prosody
・・・
Mar 24 06:15:29 temp systemd[1]: Started LSB: Prosody XMPP Server.
Mar 24 06:15:29 temp prosody[21794]: portmanager: Error binding encrypted port for https: No key present in SSL/TLS configuration for https port 5281
Mar 24 06:15:29 temp prosody[21794]: portmanager: Error binding encrypted port for https: No key present in SSL/TLS configuration for https port 5281

なんかエラーが出てるなぁ。

次に以下のファイルを編集。

/etc/jitsi/meet/temp.hogeserver.hogeddns.jp-config.js

var config = {
・・・
    hosts: {
        // XMPP domain.
        domain: 'temp.hogeserver.hogeddns.jp',
        anonymousdomain: 'guest.temp.hogeserver.hogeddns.jp', ←追加。最後のカンマも忘れずに。

/etc/jitsi/jicofo/sip-communicator.properties

これは元々は0バイトファイルだったところ、これを追加。

org.jitsi.jicofo.auth.URL=XMPP:temp.hogeserver.hogeddns.jp

ここまで設定したところで再起動。

# reboot

これでJitsiに接続してみると…あ、普通に会議室に入れるじゃん？と思ったら、違った、メッセージが表示された。

Waiting for the host ...

The conference 会議室名 has not yet started.
if you are the host then please authenticate.
Otherwise, please wait for the host to arrive.
                              [I am the host] ← このボタンを押すと認証画面に入る

で、ユーザーはコマンドで管理するっぽい。

ユーザーの追加
# prosodyctl register hoge temp.hogeserver.hogeddns.jp hogepassword
# prosodyctl adduser hoge@temp.hogeserver.hogeddns.jp ← パスワードはコマンド実行後に聞かれる
ユーザーの一覧
# ls -l /var/lib/prosody/*/accounts/*
-rw-r----- 1 prosody prosody 40 Mar 24 04:59 /var/lib/prosody/auth%2e172%2e16%2e219%2e73/accounts/focus.dat
-rw-r----- 1 prosody prosody 40 Mar 24 05:30 /var/lib/prosody/auth%2etemp%2ehogeserver%2ehogeddns%2ejp/accounts/focus.dat
-rw-r----- 1 prosody prosody 44 Mar 24 06:47 /var/lib/prosody/temp%2ehogeserver%2ehogeddns%2ejp/accounts/hoge.dat

なんだろな、この focus さんは。

さておき、追加したユーザー hoge@temp.hogeserver.hogeddns.jp と hogepassword を入力することでJitsiの認証ができて会議室が作れるようになった。

アンインストール

アンインストールするには以下を実行すればいいみたい。

Github / Jitsi Meet quick install

# apt purge jigasi jitsi-meet jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-web jicofo jitsi-videobridge
# reboot

きれいになるので再インストールを試すときにはこれを実行。

起きたこと(1) 画面共有ができない

どうにも画面共有が起動できない。いろいろと調べてみると、JitsiをアンインストールしてApacheやNginxをインストールしてからJitsiをインストールしてみ？的なやりとりが見つかった。

# apt --purge remove jitsi-meet jitsi-meet-web jitsi-meet-prosody jitsi-meet-web-config jicofo jitsi-videobridge
# apt install apache2 ← 日頃使い慣れているから。後でNginxも試したけど、それでもうまくいく。
# apt install jitsi-meet

あら、これだけでしっかりと使えるように。

/etc/apache2/sites-enable を見てみたら設定ファイルが作られていた。必要ならこれをちょっといじってあげればいいのだろうと思う。

間にApacheやNginxを挟まなくてもポートさえ空けておけば何とでもなるのかなと思っていたが、そうならなかった。理由を突き詰めるところまではやっていない。

起きたこと(2) タブレットのカメラが安定しない

タブレットはWindows10の32ビット版。こいつはカメラが使えるものの、明るくなったり暗くなったりと全然安定しない。なんでだろ？

こちらも、ApacheやNginxを事前にインストールした上でJitsiをインストールしたら解決した。

理由を突き詰めるところまではやっていない。

起きたこと(3) クロームでカメラが使えない

Firefoxでは使えてみたり、Edgeでも使えてみたりするのだけれど、Chromeでカメラにアクセスできない。設定画面では「Permission not granted」と表示される。

Jitsiを調べてみたけれどもこの問題が発生しているのは少数派っぽく、結論が出ていないように見えた。Windowsを再起動しても全然だめ…

試しにOpenmeetingsで試してみたら、マイクもカメラも使える。

これはWindows10の問題の可能性があるなと思い、以下を実行したところ解決した。

• 設定 を開く(スタートボタンをクリックすると表示される歯車をクリック)。


• 「プライバシー」をクリック。


• 左側のペインの「カメラ」をクリック。


• 項目「アプリがカメラにアクセスできるようにする」が「オン」になっているのを「オフ」にする。


• Chromeを開きJitsiの歯車をクリックして設定画面を開く。カメラは当然「Permission not granted」になる。Cancelで設定画面を閉じる。Chromeの再起動等は必要なし。


• 項目「アプリがカメラにアクセスできるようにする」を「オン」にする。


• ChromeからJitsiの歯車をクリックする。

一口に言うと、いったんWindows10の設定でカメラへのアクセスを制限しエラーを発生させ、その後に設定を緩めるとこの問題が解消するみたい。

再起動しても問題再発することはなかった。

結論、Flashからのカメラへのアクセスはうまくできていたけど、WebRTCからのカメラへのアクセスはWindows的に何かがあってうまくできていなかったのかなと。

性能が高くて使いやすいビデオ会議システムが簡単に構築できるのはいいなぁ。

SIPとかも連携できるようになるみたいだけど、自分にはハードルが高いと思うので今回は諦め。

昔の記事を見ながら宅内のNTPサーバーを立ててみたが、うまく動かない。

NTPでは123/udpを利用するので開けてある。だが、それ以前の問題としてサービスがうまく起動しない。

やることは Chrony というアプリケーションを設定すること。

そこに至る過程は、その後に記載。

よくわからないけど、NTPはChronyに置き換わったのかな？

Server World / NTP サーバー : Chrony の設定

を参考にインストールしてみる。

$ sudo apt install chrony

設定はntpdとよく似ている。

/etc/chrony/chrony.conf

pool ntp.nict.jp          iburst
pool ntp1.jst.mfeed.ad.jp iburst
pool ntp2.jst.mfeed.ad.jp iburst
pool ntp3.jst.mfeed.ad.jp iburst

keyfile /etc/chrony/chrony.keys

driftfile /var/lib/chrony/chrony.drift

logdir /var/log/chrony

maxupdateskew 100.0

rtcsync

makestep 1 3

# 接続元設定
allow 172.16.0.0/16
allow 24nn:nnnn:nnnn:nnnn::/64
allow fdnn:nnnn:nnnn:nnnn::/64

※コメントは割愛

NTPサーバーは以下を使わせていただくこととした。

日本標準時グループ / 公開ＮＴＰ

INTERNET MULTIFEED社 / 時刻情報提供サービス for Publicとは

サービスを再起動して、状況確認。

$ sudo systemctl restart chroky
$ chronyc sources
210 Number of sources = 7
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp-a2.nict.go.jp             1   6   377    32    +31us[ +103us] +/- 4256us
^+ ntp-a3.nict.go.jp             1   6   377    30   -474us[ -474us] +/- 4544us
^+ ntp-b2.nict.go.jp             1   6   377    29   +387us[ +387us] +/- 3895us
^+ ntp-a3.nict.go.jp             1   6   377    29   -648us[ -648us] +/- 4856us
^- ntp1.jst.mfeed.ad.jp          2   6   377    28   -291us[ -291us] +/-   79ms
^- ntp2.jst.mfeed.ad.jp          2   6   377    30   +592us[ +592us] +/-   74ms
^- ntp3.jst.mfeed.ad.jp          2   6   377    29   +799us[ +799us] +/-  109ms

さっくり動作、Windowsからも時刻の同期がとれた。

なんで Chrony をインストールしたかというと、ntpがうまく動かないから調べていたら CentOSではChronyへの流れになっているようだったから。Ubuntuがどうなのかはわからない。

当然動くんでしょ？ということでntpをインストールして設定してみる。

$ sudo apt install ntp

/etc/ntp.conf

driftfile /var/lib/ntp/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server ntp.nict.jp
server ntp.nict.jp
server ntp.nict.jp
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

restrict 127.0.0.1
restrict ::1

restrict 172.16.0.0 mask 255.255.0.0
restrict fdnn:nnnn:nnnn:nnnn:: mask ffff:ffff:ffff:ffff::
restrict 24nn:nnnn:nnnn:nnnn:: mask ffff:ffff:ffff:ffff::

設定をこうして、サービスを再起動してみた。

$ sudo systemctl restart ntp

いつまでたっても同期しない。先頭に*が付かない。

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ntp-a2.nict.go. .INIT.          16 u    -  256    0    0.000    0.000   0.000

サーバープールってのが気になったので…でも、これはサーバーを列挙してるだけだなぁ。

driftfile /var/lib/ntp/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server 0.jp.pool.ntp.org iburst
server 1.jp.pool.ntp.org iburst
server 2.jp.pool.ntp.org iburst
server 3.jp.pool.ntp.org iburst
server ntp.nict.jp
server ntp.nict.jp
server ntp.nict.jp
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

restrict 127.0.0.1
restrict ::1

restrict 172.16.0.0 mask 255.255.0.0
restrict fdnn:nnnn:nnnn:nnnn:: mask ffff:ffff:ffff:ffff::
restrict 24nn:nnnn:nnnn:nnnn:: mask ffff:ffff:ffff:ffff::

これでどうにか同期が始まったのだが…再起動して試そうと思ったら、サービス起動しない。サービスを有効にしてみたものの、再起動するといったんロードされて誰かにプロセスを落とされるみたい。

Quiita / Ubuntu 16.04にntpとntpdateを両方インストールするとOS起動時にntp.serviceが停止している

なんで、こんなに不親切な感じにしてあるんだろう？

やめよう。

$ sudo apt remove ntp --purge
$ sudo apt autoremove

今後は ntp じゃなくて Chronyってことなのかな。

今は他にやることもあるから、気にしないで進めることとする。

管理するサーバーが増えてきたので、間違えるのもいやなので、ログイン時にサーバー名を表示するようにした。表示される模様を変えたりしながら、自分なりに間違えない形を作っていこう。

以前書いていた記事と変わらないけど、当時より用意されているファイルが多かった。

ここに並んでいるファイルスクリプトが順番に表示される模様。

$ ls -l /etc/update-motd.d/
-rwxr-xr-x 1 root root 1220 Apr  9  2018 00-header
-rwxr-xr-x 1 root root 1157 Apr  9  2018 10-help-text
lrwxrwxrwx 1 root root   46 Apr  7 16:45 50-landscape-sysinfo -> /usr/share/landscape/landscape-sysinfo.wrapper
-rwxr-xr-x 1 root root 4264 Aug 20  2018 50-motd-news
-rwxr-xr-x 1 root root  604 Mar 22  2018 80-esm
-rwxr-xr-x 1 root root 3017 Mar 22  2018 80-livepatch
-rwxr-xr-x 1 root root   97 Jun 27  2018 90-updates-available
-rwxr-xr-x 1 root root  299 May 19  2017 91-release-upgrade
-rwxr-xr-x 1 root root  129 Jun 27  2018 95-hwe-eol
-rwxr-xr-x 1 root root  111 Oct 27  2017 97-overlayroot
-rwxr-xr-x 1 root root  142 Jun 27  2018 98-fsck-at-reboot
-rwxr-xr-x 1 root root  144 Jun 27  2018 98-reboot-required

自分的には、一番最後にメッセージが表示されるとうれしい模様。自分として目立つ形であれば何でも良かったので、こんなのを放り込んでみた。実行権も付けておく。

/etc/update-motd.d/99-about

#!/bin/sh
#
printf "****************************************\n"
printf "***** このサーバーは HogeHoge です *****\n"
printf "****************************************\n"

これで、サーバーが見分けやすくなる…ハズ…

先日JitsiというWeb会議システムをインストールしてみたのは、インストールが簡単そうで使いやすそうだったから。元々はOpenmeetingsを使っていたが、Flashが使われていたり、画面共有のためにJava8が必要でライセンス的に色々と心配になったために乗り換えを考えていたのだ。

ただ、OpenmeetingsもHTML5とかWebRTCに対応するとか書かれていたので期待していて、これはこれで環境構築を考えてみたかった。

Ubuntu18.04にインストールしてみようと思う。

手順書は Tutorials for installing OpenMeetings and Tools にあるものを使わせていただいた。

$ sudo apt update; sudo apt -y dist-upgrade

OpenJDKインストール
$ sudo apt install openjdk-8-jdk openjdk-8-jdk-headless
$ sudo update-alternatives --config java
There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1111      auto mode
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1111      manual mode
  2            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      manual mode

Press  to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java to provide /usr/bin/java (java) in manual mode

$ java -version
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.18.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

LibreOfficeのインストール
$ sudo apt install libreoffice

ImageMagickのインストール
$ sudo apt install imagemagick libjpeg62 zlib1g-dev

ここでファイル編集。

/etc/ImageMagick-6/policy.xml

・
・
・
  <!-- disable ghostscript format types -->
<!--  <policy domain="coder" rights="none" pattern="PS" /> --> ← コメントアウト
  <policy domain="coder" rights="none" pattern="EPI" />
  <policy domain="coder" rights="none" pattern="PDF" />
<!--  <policy domain="coder" rights="none" pattern="XPS" /> --> ← コメントアウト
・

続いて…

Soxインストール
$ sudo apt install sox

FFmpegインストール(手順書はコンパイルしている、手抜き。ちゃんと動かないかも)
$ sudo apt install ffmpeg

MariaDBインストール(多分、MySQLでも可)
$ sudo apt install mariadb-server
$ sudo mysqladmin -u root password rootのパスワード
$ sudo mysql -u root -p
Enter password: rootのパスワードを入力してEnter
MariaDB [(none)]> create database openmeetings default character set 'utf8';
MariaDB [(none)]> grant all privileges on openmeetings.* to 'openmeetings'@'localhost' identified by 'パスワード' with grant option;
MariaDB [(none)]> quit
Bye
※データベースはopenmeetings、ユーザーもopenmeetingsで作成。

Kurento Media Serverインストール(WebRTCサーバー)
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 5AFA7A83
$ sudo tee "/etc/apt/sources.list.d/kurento.list" >/dev/null <<EOF
> # Kurento Media Server - Release packages
> deb [arch=amd64] http://ubuntu.openvidu.io/6.10.0 bionic kms6
> ここで[Ctrl]+[D]
> -bash: warning: here-document at line 26 delimited by end-of-file (wanted `EOF')
$ sudo apt update
$ sudo apt install kurento-media-server
$ sudo systemctl start kurento-media-server

Openmeetingsを動かすユーザー(omuser)を追加する
$ sudo useradd --system --user-group omuser

ここまでインストールしたら、モジュールをダウンロードして溶かす。

インストール先はいつもの /usr/share/openmeetings とする。

で、作ったomuserの持ち物にする。

$ sudo chown -R omuser:omuser /usr/share/openmeetings

MySQLコネクターを利用するので、以下からダウンロードする。

MySQL / Download Connector/J

debパッケージになっているみたいだけど、Jarファイルがあればいいと思うので、Platform Independent を選択し、zipファイルをダウンロードする。

この日のバージョンは mysql-connector-java-8.0.16.jar (違っていても構わない)、/usr/share/openmeetings/webapps/openmeetings/WEB-INF/lib/ にコピーする。

起動用のスクリプト。手順書にあったものを少しだけ書き換えた。

/etc/init.d/openmetings

#! /bin/sh
#
### BEGIN INIT INFO
# Provides:          Openmeetings
# Required-Start:    mysql apache2 kurento-media-server
# Required-Stop:
# Should-Start:
# Should-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Apache Openmeetings Service
# Description:       Openmeetings provides video conferencing, instant messaging,
#                    white board, collaborative document editing and other groupware
#                    tools using API functions of the Red5 Streaming Server for
#                    Remoting and Streaming.
### END INIT INFO

# set the environment
# JAVA_OPTS=""
# CATALINA_OPTS=""
CATALINA_HOME=/usr/share/openmeetings
RUN_USER=omuser

# set TIME OUT values
# TIMELIMIT=10
# SLEEPTIME=40

# Function to wait until all Tomcat processes are killed
waitForTomcatToDie()
{
    PROCESSES=`ps auxwww | grep $HOME | grep 'java' | grep 'tomcat' | grep -v 'grep'`
    while [ ! -z "$PROCESSES" ] && [ $SECONDS -lt $TIMELIMIT ] && [ $TIMELIMIT -ne 0 ]; do
        echo -n "."
        sleep $SLEEPTIME
        PROCESSES=`ps auxwww | grep $USER | grep 'java' | grep 'tomcat' | grep -v 'grep'`
    done

    echo ""
    if [ ! -z "$PROCESSES" ]; then
        PROCESS_ID=`echo $PROCESSES | awk '{ print $2 }'`
        echo "Killing process: $PROCESS_ID"
    kill -9 $PROCESS_ID
    fi
}

# See how we were called.
case "$1" in
    start)
        $CATALINA_HOME/bin/startup.sh -u $RUN_USER -Dcatalina.base$CATALINA_BASE
        ;;
    # debug)
        # DEBUG_PORT=10001
        ## export JAVA_OPTS="${JAVA_OPTS} -Xdebug -Xrunjdwp:transport=dt_socket,address{DEBUG_PORT},server=y,suspend=n"
        # $CATALINA_HOME/bin/startup.sh -Dcatalina.base{CATALINA_BASE}
        # ;;
    stop)
        # $CATALINA_HOME/bin/shutdown.sh
        $CATALINA_HOME/bin/shutdown.sh
        waitForTomcatToDie
        echo "...Tomcat stopped."
        ;;
    restart)
        $0 stop
        echo "...Restarting..."
        sleep 8
        $0 start
        ;;
    status)
        status $PROG -p $PIDFILE
        RETVAL=$?
        ;;
        *)
        echo $"Usage: $0 {start|stop|restart|status}"
        RETVAL=1
esac

exit $RETVAL

起動用のスクリプトを有効化する。

$ sudo chown -R omuser:omuser /usr/share/openmeetings

$ sudo systemctl daemon-reload
$ sudo systemctl enable openmeetings
openmeetings.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable openmeetings
※怒られた^^; 本当のやり方はこれじゃないんだろうなぁ…

$ sudo /lib/systemd/systemd-sysv-install enable openmeetings
$ sudo systemctl start openmeetings

多分、これで起動しているだろうから、Openmeetingsにアクセスする。

http://[openmeetingsserver].hogeserver.hogeddns.jp:5080

※IPアドレスでもかまわない。

インストール画面にリダイレクトされる。

• 最初の画面
  
  ホワイトボードへのPDFのインポートを有効化する為に、GhostScriptをインストールするように書かれている。
  
  次へ…


• データベース構成
  
  MySQLを選択し、ユーサーとしてopenmeetings、パスワードを入力し、接続試験ボタンをクリックする。接続試験に成功すれば先に進める。
  
  次へ…


• ユーザー・データー
  
  最初のユーザーと、ユーザーが所属するグループを決める。
  
  タイムゾーンは Asia/Tokyo とする。
  
  次へ…


• 構成
  
  自己登録はクローズドな環境であれば許可して良いと思うが、インターネットに向けて公開するなら拒否した方がいいと思う。
  
  管理者のメールアドレス等の設定をする。
  
  次へ…


• 文書変換
  
  これは何も指定しなくてもパスが通っていそう。
  
  次へ…


• 暗号タイプ・red5SIP 構成
  
  何も指定しなくてもとりあえずはいいと思う。
  
  次へ…


• インストールボタンをクリックする。
  
  インストールが終了すると、念のために再起動しろと言われる。

Openmeetingsを再起動。

$ sudo systemctl restart openmeetings

改めてアクセスして、ログインしてみる。

http://[openmeetingsserver].hogeserver.hogeddns.jp:5080

日本語…って指定しているつもりだけど、日本語にはならなかった。

Administration → Configuration の 15番のDefault lang ID に 15 を設定し、これから作られるユーザーのデフォルト言語を日本語にできそう。

自分ユーザーは、プロフィールで日本語を選べば日本語で利用できる。

例によってApacheを使ってSSLをかぶせてみる。

まずは、Apacheをインストールして必要なモジュールを有効化する。

$ sudo apt install apache2
$ sudo a2enmod proxy proxy_http proxy_wstunnel rewrite headers ssl

5443へのProxyの設定を書いてみる。

/etc/apache2/sites-available/openmeetings.conf

<VirtualHost *:443>
    ServerName temp.hogeserver.hogeddns.jp
    ServerAdmin webmaster@hogeserver.hogeddns.jp

    ProxyPreserveHost on
    RewriteEngine on
    RewriteCond %{HTTP:Upgrade} =websocket [NC]
    RewriteRule /(.*)           wss://127.0.0.1:5443/$1 [P,L]
    RewriteCond %{HTTP:Upgrade} !=websocket [NC]
    RewriteRule /(.*)           https://127.0.0.1:5443/$1 [P,L]
    SSLProxyEngine on
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    ProxyPassReverse / https://127.0.0.1:5443/
    ProxyPassReverse /openmeetings/wicket/ wss://127.0.0.1:5443/openmeetings/wicket/

    ErrorLog  ${APACHE_LOG_DIR}/openmeetings-error.log
    CustomLog ${APACHE_LOG_DIR}/openmeetings-access.log combined

    SSLEngine on
    SSLCertificateFile    /etc/ssl/private/temp.crt
    SSLCertificateKeyFile /etc/ssl/private/temp.key
</VirtualHost>

HTTPはもう使わないだろうということで、80番のサービスをやめて Openmeetings の Proxy 設定を有効化させる。この時、モジュールも有効化しているので Apache は再起動する。

$ sudo a2dissite 000-default.conf
$ sudo a2ensite openmeetings.conf
$ sudo systemctl restart apache2

以前、この転送は例によってCSRF対策で引っかかるので、ソースを改変してアクセス可能にしていたが、443への転送は問題なく処理できた。俺の過去記事…とほほ、あのときにSSLProxyCheckPeerCNとかを知っていたらソースコンパイルとかいらなかったのかなぁ。

この間 Jitsi を試してこれでいいや！と思ったりもしたが、Openmeetingsはホワイトボード機能がいいよねー。画面共有は Jitsi と同じような選択画面になっていた。高機能な分、セットアップが大変だけど、セットアップが終わっちゃえば便利でしょう。

ただ、いつものパターンとしてファーストバージョンはバグが多い。今回、設定の問題なのかバグなのかはわからなかったけど、ビデオ・音声のテストができなかったり、画面共有時にFPSを選択できるのは良かったんだけど、一度決めたFPSを変更できなくなるのはおかしな感じ。他の機能は試せてないし、セッション管理に問題がないかどうかといった実用上のポイントは使ってみないとなんとも。

もう少し待って、安定版が出てからバージョンアップするのもいいかも。

サーバーがある程度安定稼働してきていて、SSHでアクセスしない日が増えてきている。そうなってくるとセキュリティアップデートを自動で適用させたくなってくる。何なら、セキュリティじゃなくても自動適用させたいし、必要ならさっさと再起動してもらって構わない。

あぁ、再起動タイミングは少し考えるか…OS2種類(タイトルは18.04だけど)、再起動タイミング2種類かな。

■ルーター君は即時再起動

ルーター君はUbuntu18.04、外部に向けてサービスを提供するためにPPP接続を張ってDynamicDNSに割り当てられたIPアドレスを通知している。既に設定は完了しており、今後機能を追加する予定はない。家族や親戚だけで利用しているサービスだし、仮に真っ昼間に1～2分程度止まっても何の問題もない。

■AD DC君は4時頃再起動

AD DC君はUbuntu18.04、DHCPやDNSが機能していて日頃普通に使っている。機能を変えるためにメンテナンスすることもあるから、意図しない再起動はちょっと困る。

■サーバー君も4時頃再起動

サーバー君はUbuntu16.04、Webサーバーの元で各種機能を展開している。こちらもメンテナンスすることがあるから、意図しない再起動はちょっと困る。

■unattended-upgrades

ここで超詳しく説明してくれている。

Qiita / Debian 系で unattended-upgrades を有効にする場合の追加設定 (メール通知, autoremove, autoclean, 再起動)

Ubuntu18.04でもUbuntu16.04でもインストールは一緒…だが、最初からインストールされてる。

$ sudo apt install unattended-upgrades ← 最初から入ってる

設定ファイルは3つある模様。

Narrow Escape / Ubuntu 16.04: 自動アップデート / アップグレードの設定をする

/etc/apt/apt.conf.d/10periodic ← unattended-upgradeでは利用されない。20が優先される

/etc/apt/apt.conf.d/20auto-upgrades ← 自動アップデートとアップグレードを設定。

/etc/apt/apt.conf.d/50unattended-upgrades ← 自動アップグレードの詳細を設定。

■ファイル 20auto-upgrades

ここに説明があるかな…と思いきや、ない。いや、枠組みの説明や、なくなったときの説明はあるんだけど、中身の説明がない。

debian wiki / UnattendedUpgrades

なので、画面の設定値を変えたらどうなるのか見てみた。

APT::Periodic::Update-Package-Lists "1"; 
→ Automatically check for updates(アップデートを自動的に確認する)
   Daily=1 / Every two days = 2 / Weekly = 7 / Every two weeks = 14 / Never = 0

APT::Periodic::Download-Upgradeable-Packages "0";
→ When there are security updates(セキュリティアップデートがある場合 その1)
   Download and install automatically = 1 / Download automatically = 1 / Display immediately = 0
   アップグレードするためにはダウンロードはしておく(=1)必要がある。

APT::Periodic::AutocleanInterval "0";
→ GUIをインストールして[Software & Updates]を起動したらできた項目だけど、対応項目が見つからない。
   何か設定を変えると必ず0になるけど、どうやらこれは日にちを入れる模様。恐らく以下。
   Daily=1 / Every two days = 2 / Weekly = 7 / Every two weeks = 14 / Never = 0

APT::Periodic::Unattended-Upgrade "1";
→ When there are security updates(セキュリティアップデートがある場合 その2)
   Download and install automatically = 1 / Download automatically = 0  / Display immediately = 0
   アップグレードするには1を設定しておく必要がある。

以上のことから、ウチの場合は以下の設定にしておけば良さそう。

再起動のタイミングは 50unattended-upgrades で設定する。

APT::Periodic::Update-Package-Lists "1";           ← 毎日アップデートをチェック
APT::Periodic::Download-Upgradeable-Packages "1";  ← アップデートをダウンロードする
APT::Periodic::AutocleanInterval "14";             ← 2週間に1回くらいクリーンアップ
APT::Periodic::Unattended-Upgrade "1";             ← アップデートをインストールする

なお、Ubuntu16.04ではファイルがなくなっていた。これは再構築できる。

$ dpkg-reconfigure -plow unattended-upgrades
…
[unattended-upgrades を設定しています]
自動的に安定版の更新をダウンロードしてインストールしますか?
→ はい
…
Creating config file /etc/apt/apt.conf.d/20auto-upgrades with new version

■ファイル 50unattended-upgrades

とにかく説明を探さないと…

Github / mvo5/unattended-upgrades

Ubuntu Manuals / unattended-upgrade

libre-software.net / How to set up automatic updates on Ubuntu Server 18.04

だけど、Githubの情報にたどり着いたのは調査の最後の方で、とにかく情報に行き当たらなかった。仕方なくファイルの中身をGoogle先生に翻訳してもらって若干の意訳を付けてみたりした…

// Automatically upgrade packages from these (origin:archive) pairs
// これらの(origin:archive)ペアから自動的にパッケージをアップグレードする
//
// Note that in Ubuntu security updates may pull in new dependencies
// from non-security sources (e.g. chromium). By allowing the release
// pocket these get automatically pulled in.
// Ubuntuでは、セキュリティアップデートにより、セキュリティ以外の
// ソース(例 chromium)から新しい依存関係が引き込まれる可能性があります。
// リリースポケットを許可することで、これらは自動的に引き込まれます。
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    // Extended Security Maintenance; doesn't necessarily exist for
    // every release and this system may not have it installed, but if
    // available, the policy for updates is such that unattended-upgrades
    // should also install from here by default.
    // 拡張セキュリティメンテナンス; 必ずしもすべてのリリースに存在するわけではなく、
    // このシステムにインストールされていない場合もありますが、
    // 利用可能であれば、デフォルトでunattended-upgradesも
    // ここからインストールするように更新のポリシーが定められています。
    "${distro_id}ESM:${distro_codename}";
//  "${distro_id}:${distro_codename}-updates";
//  "${distro_id}:${distro_codename}-proposed";
//  "${distro_id}:${distro_codename}-backports";
};

// List of packages to not update (regexp are supported)
// 更新しないパッケージのリスト(regexpがサポートされています)
Unattended-Upgrade::Package-Blacklist {
//  "vim";
//  "libc6";
//  "libc6-dev";
//  "libc6-i686";
};

// This option will controls whether the development release of Ubuntu will be
// upgraded automatically.
// このオプションはUbuntuの開発版を自動的にアップグレードするかどうかを制御します。
// ※Ubuntu16.04にない
Unattended-Upgrade::DevRelease "false";

// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run
//   dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
// このオプションを使用すると、dpkgがきれいに終了しなかった時に
// unattended-upgradesが自動的に実行されるかどうかを制御できます。
//   dpkg --force-confold --configure -a
// 更新が確実にインストールされるようにするため、デフォルトはtrueです。
// デフォルト値: true
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGTERM. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
// それらがSIGTERMで割り込まれることができるように可能な限り小さい塊にアップグレードを
// 分割してください。これによりアップグレードが少し遅くなりますが、アップグレードの
// 実行中にシャットダウンが可能になるという利点があります(わずかな遅延があります)。
// デフォルト値: true
//Unattended-Upgrade::MinimalSteps "false";

// Install all unattended-upgrades when the machine is shutting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
// マシンの実行中にバックグラウンドで実行するのではなく、
// マシンのシャットダウン時にすべての無人アップグレードをインストールします。
// これは(明らかに)シャットダウンを遅くします。
// デフォルト値: false 
//Unattended-Upgrade::InstallOnShutdown "true";

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
// 問題やパッケージのアップグレードがあれば、ここに電子メールを送ります。
// 有効なメールアドレスであることを確認してください、空または未設定の場合は送信されません。
// 'mailx'を提供するパッケージをインストールしておいてください。
// 例 "user@example.com"
// デフォルト値: 未設定
//Unattended-Upgrade::Mail "root";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
// エラー時にのみEメールを受信するには、この値を "true"に設定します。
// Unattended-Upgrade::Mailが設定されている場合、デフォルトでは常にメールを送信します。
// デフォルト値: false
//Unattended-Upgrade::MailOnlyOnError "true";

// Remove unused automatically installed kernel-related packages
// (kernel images, kernel headers and kernel version locked tools).
// 自動インストールされたカーネル関連パッケージが未使用になったら削除します。
// (カーネルイメージ、カーネルヘッダ、カーネルバージョンロックツール)
// デフォルト値: 情報なし
//Unattended-Upgrade::Remove-Unused-Kernel-Packages "false";

// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
// アップグレード後に新しい未使用の依存関係を自動的に削除します。
// (apt-get autoremoveと同等)
// デフォルト値: false
//Unattended-Upgrade::Remove-Unused-Dependencies "false";

// Automatically reboot *WITHOUT CONFIRMATION*
//  if the file /var/run/reboot-required is found after the upgrade
// アップグレード後に /var/run/reboot-required ファイルが見つかった場合は、
// *確認なし*に自動的に再起動します。
// デフォルト値: false
//Unattended-Upgrade::Automatic-Reboot "false";

// If automatic reboot is enabled and needed, reboot at the specific
// time instead of immediately
//  Default: "now"
// 自動再起動が有効で必要な場合は、すぐにではなく特定の時間に再起動します。
//  デフォルト値: "now"
//Unattended-Upgrade::Automatic-Reboot-Time "02:00";

// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
// この例では、ダウンロード速度を70kb/秒に制限しています。
//Acquire::http::Dl-Limit "70";

// Enable logging to syslog. Default is False
// syslogへのロギングを有効にします。
// デフォルト値: false
// ※Ubuntu16.04にない
// Unattended-Upgrade::SyslogEnable "false";

// Specify syslog facility. Default is daemon
// syslog機能を指定してください。
// デフォルト値: daemon
// ※Ubuntu16.04にない
// Unattended-Upgrade::SyslogFacility "daemon";

// Download and install upgrades only on AC power
// (i.e. skip or gracefully stop updates on battery)
// AC電源でのみアップグレードをダウンロードしてインストールします。
// (つまり、バッテリーのアップデートをスキップまたは正常に停止します)
// デフォルト値: 情報なし
// ※Ubuntu16.04にない
// Unattended-Upgrade::OnlyOnACPower "true";

// Download and install upgrades only on non-metered connection
// (i.e. skip or gracefully stop updates on a metered connection)
// 従量課金ではない接続でのみアップグレードをダウンロードしてインストールします。
// (つまり、従量課金接続では更新をスキップまたは適切に停止します)
// デフォルト値: 情報なし
// ※Ubuntu16.04にない
// Unattended-Upgrade::Skip-Updates-On-Metered-Connections "true";

それぞれの設定を見ていこうと思うけど…大変。Unattended-Upgrade::Allowed-Origins については、以下の内容が参考になりそう。

コはコンピューターのコ / unattended-upgradeでサードパーティリポジトリも自動アップデートする

セキュリティ以外のアップデートも一緒にやっておいて欲しいから、

"${distro_id}:${distro_codename}-updates"

を有効にしてみるか。

これ以外の項目はコメントを見ながらやってみよう！ということで、ファイルは以下の通りに変更。コメントは日本語にしちゃえ。

// これらの(origin:archive)ペアから自動的にパッケージをアップグレードする
//
// Ubuntuでは、セキュリティアップデートにより、セキュリティ以外の
// ソース(例 chromium)から新しい依存関係が引き込まれる可能性があります。
// リリースポケットを許可することで、これらは自動的に引き込まれます。
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    // Extended Security Maintenance; doesn't necessarily exist for
    // every release and this system may not have it installed, but if
    // available, the policy for updates is such that unattended-upgrades
    // should also install from here by default.
    // 拡張セキュリティメンテナンス; 必ずしもすべてのリリースに存在するわけではなく、
    // このシステムにインストールされていない場合もありますが、
    // 利用可能であれば、デフォルトでunattended-upgradesも
    // ここからインストールするように更新のポリシーが定められています。
    "${distro_id}ESM:${distro_codename}";
    "${distro_id}:${distro_codename}-updates"; ← 有効化
//  "${distro_id}:${distro_codename}-proposed";
//  "${distro_id}:${distro_codename}-backports";
};

// 更新しないパッケージのリスト(regexpがサポートされています)
Unattended-Upgrade::Package-Blacklist {
//  "vim";
//  "libc6";
//  "libc6-dev";
//  "libc6-i686";
};

// このオプションはUbuntuの開発版を自動的にアップグレードするかどうかを制御します。
Unattended-Upgrade::DevRelease "false";

// このオプションを使用すると、dpkgがきれいに終了しなかった時に
// unattended-upgradesが自動的に実行されるかどうかを制御できます。
//   dpkg --force-confold --configure -a
// 更新が確実にインストールされるようにするため、デフォルトはtrueです。
// デフォルト値: true
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";

// それらがSIGTERMで割り込まれることができるように可能な限り小さい塊にアップグレードを
// 分割してください。これによりアップグレードが少し遅くなりますが、アップグレードの
// 実行中にシャットダウンが可能になるという利点があります(わずかな遅延があります)。
// デフォルト値: true
//Unattended-Upgrade::MinimalSteps "false";

// マシンの実行中にバックグラウンドで実行するのではなく、
// マシンのシャットダウン時にすべての無人アップグレードをインストールします。
// これは(明らかに)シャットダウンを遅くします。
// デフォルト値: false 
//Unattended-Upgrade::InstallOnShutdown "true";

// 問題やパッケージのアップグレードがあれば、ここに電子メールを送ります。
// 有効なメールアドレスであることを確認してください、空または未設定の場合は送信されません。
// 'mailx'を提供するパッケージをインストールしておいてください。
// 例 "user@example.com"
// デフォルト値: 未設定
//Unattended-Upgrade::Mail "root";
Unattended-Upgrade::Mail "hogeuser@hogeserver.hogeddns.jp";
// ただし、メール送信のためにはpostfixとかも必要になることから、ちょっとハードルが高いかも。

// エラー時にのみEメールを受信するには、この値を "true"に設定します。
// Unattended-Upgrade::Mailが設定されている場合、デフォルトでは常にメールを送信します。
// デフォルト値: false
Unattended-Upgrade::MailOnlyOnError "true"; ← 有効化

// 自動インストールされたカーネル関連パッケージが未使用になったら削除します。
// (カーネルイメージ、カーネルヘッダ、カーネルバージョンロックツール)
// デフォルト値: 情報なし
//Unattended-Upgrade::Remove-Unused-Kernel-Packages "false";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
// アップグレード後に新しい未使用の依存関係を自動的に削除します。
// (apt-get autoremoveと同等)
// デフォルト値: false
//Unattended-Upgrade::Remove-Unused-Dependencies "false";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// アップグレード後に /var/run/reboot-required ファイルが見つかった場合は、
// *確認なし*に自動的に再起動します。
// デフォルト値: false
//Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot "true";

// 自動再起動が有効で必要な場合は、すぐにではなく特定の時間に再起動します。
//  デフォルト値: "now"
//Unattended-Upgrade::Automatic-Reboot-Time "02:00";
Unattended-Upgrade::Automatic-Reboot-Time "now";   ← 即時再起動チーム
Unattended-Upgrade::Automatic-Reboot-Time "04:00"; ← 4時再起動チーム

// この例では、ダウンロード速度を70kb/秒に制限しています。
//Acquire::http::Dl-Limit "70";

// syslogへのロギングを有効にします。
// デフォルト値: false
// Unattended-Upgrade::SyslogEnable "false";

// syslog機能を指定してください。
// デフォルト値: daemon
// Unattended-Upgrade::SyslogFacility "daemon";

// AC電源でのみアップグレードをダウンロードしてインストールします。
// (つまり、バッテリーのアップデートをスキップまたは正常に停止します)
// デフォルト値: 情報なし
// Unattended-Upgrade::OnlyOnACPower "true";

// 従量課金ではない接続でのみアップグレードをダウンロードしてインストールします。
// (つまり、従量課金接続では更新をスキップまたは適切に停止します)
// デフォルト値: 情報なし
// Unattended-Upgrade::Skip-Updates-On-Metered-Connections "true";

■メール送信について

mailutil にしても bsd-mailx にしても、Postfixを必要とする。

ルーター君は外からのメールをサーバー君に単純転送するなどの動きをしていることから、そんなものを設定することはできないなぁと。よって、ここでは説明をしない。

ウチの場合だと、ルーター君とAD DC君はメール送信ができなくて、サーバー君だけがメール送信できる状態になるが、まぁ、いいでしょう。

$ sudo apt install bsd-mailx
$ echo test | mail hogeuser@hogeserver.hogeddns.jp
→ これで宛先にテストメールが届く。

■動作確認

まずは、サービスが有効になっているか確認。

$ sudo systemctl status unattended-upgrades.service
● unattended-upgrades.service - Unattended Upgrades Shutdown
   Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-04-29 16:39:25 JST; 1 day 22h ago
…

どうやら、サービスが有効化されて起動している模様。

動作テスト。

$ sudo unattended-upgrade --dry-run --debug
Initial blacklisted packages:
Initial whitelisted packages:
Starting unattended upgrades script
Allowed origins are: o=Ubuntu,a=bionic, o=Ubuntu,a=bionic-security, o=UbuntuESM,a=bionic, o=Ubuntu,a=bionic-updates
Using (^linux-image-[0-9]+\.[0-9\.]+-.*|^linux-headers-[0-9]+\.[0-9\.]+-.*|^linux-image-extra-[0-9]+\.[0-9\.]+-.*|^linux-modules-[0-9]+\.[0-9\.]+-.*|^linux-modules-extra-[0-9]+\.[0-9\.]+-.*|^linux-signed-image-[0-9]+\.[0-9\.]+-.*|^kfreebsd-image-[0-9]+\.[0-9\.]+-.*|^kfreebsd-headers-[0-9]+\.[0-9\.]+-.*|^gnumach-image-[0-9]+\.[0-9\.]+-.*|^.*-modules-[0-9]+\.[0-9\.]+-.*|^.*-kernel-[0-9]+\.[0-9\.]+-.*|^linux-backports-modules-.*-[0-9]+\.[0-9\.]+-.*|^linux-modules-.*-[0-9]+\.[0-9\.]+-.*|^linux-tools-[0-9]+\.[0-9\.]+-.*|^linux-cloud-tools-[0-9]+\.[0-9\.]+-.*) regexp to find kernel packages
Using (^linux-image-4\.15\.0\-48\-generic$|^linux-headers-4\.15\.0\-48\-generic$|^linux-image-extra-4\.15\.0\-48\-generic$|^linux-modules-4\.15\.0\-48\-generic$|^linux-modules-extra-4\.15\.0\-48\-generic$|^linux-signed-image-4\.15\.0\-48\-generic$|^kfreebsd-image-4\.15\.0\-48\-generic$|^kfreebsd-headers-4\.15\.0\-48\-generic$|^gnumach-image-4\.15\.0\-48\-generic$|^.*-modules-4\.15\.0\-48\-generic$|^.*-kernel-4\.15\.0\-48\-generic$|^linux-backports-modules-.*-4\.15\.0\-48\-generic$|^linux-modules-.*-4\.15\.0\-48\-generic$|^linux-tools-4\.15\.0\-48\-generic$|^linux-cloud-tools-4\.15\.0\-48\-generic$) regexp to find running kernel packages
pkgs that look like they should be upgraded:
Fetched 0 B in 0s (0 B/s)
fetch.run() result: 0
blacklist: []
whitelist: []
No packages found that can be upgraded unattended and no pending auto-removals

さぁ、後はアップデートがされるのをじっと待つ感じかな。

新たにドメインを作ってサーバーを立てようと思いたったことから、そこでもKopanoをセットアップして使おうと思った。

だが、今回は1から構築じゃん。ハードルが高くて、ついつい後回しにしてたやつだ。

でも、やるなら今だ、今しかない！

やることをざっくり考えると…

• OSインストール直後の色々な初期設定


• Postfixのインストール(メール転送)


• MariaDBのインストール(各種データの保管場所)


• Apacheのインストール(Webサーバー)


• Kopanoのインストール(Exchange互換のシステム)


• Z-Pushのインストール(プッシュ通知)


• 各システムをつなげていく


• Postfixでメール送受信ができるように設定する

となる。まっさらな環境から作っていってみよう。

今回もDynamicDNSで hogeserver.hogeddns.jp が名前解決できる前提。

ここに temp というサーバーを立てて、temp.hogeserver.hogeddns.jp というFQDNとしている。

■OSインストール直後の色々な初期設定

IPv6を無効化(うちでは使えないため。これは必須ではない、使えるなら使いたい)。それと、再起動を早くする。0でも良さそうだけど。

/etc/default/grub

GRUB_TIMEOUT=1
GRUB_CMDLINE_LINUX="ipv6.disable=1"

反映して再起動。

$ sudo update-grub
$ sudo reboot

タイムゾーンの設定。

$ sudo timedatectl set-timezone Asia/Tokyo
$ timedatectl
                      Local time: Thu 2019-05-02 17:17:55 JST
                  Universal time: Thu 2019-05-02 08:17:55 UTC
…

色々アップデート、SSH以外のポートを閉じて再起動。

$ sudo apt update; sudo apt -y dist-upgrade; sudo apt -y autoremove
$ sudo ufw allow ssh comment SSH
$ sudo ufw enable
$ sudo reboot

※テスト環境のため、SSHの鍵設定は行っていない。

■Postfixのインストール

パッケージをインストール。

$ sudo apt install postfix postfix-mysql

[Postfix Configuration]
質問1 : Internet Site
質問2 : temp.hogeserver.hogeddns.jp
※ここではテスト用のドメインを入力。
　通常 hogeserver.hogeddns.jp を利用しているとして、今回はその下位に temp というサブドメインを立ててテスト。

$ getent passwd ※追加された分だけを抜粋
postfix:x:111:114::/var/spool/postfix:/usr/sbin/nologin

$ getent group ※追加された分だけを抜粋
ssl-cert:x:113:
postfix:x:114:
postdrop:x:115:

■MariaDBのインストール

パッケージをインストール。

$ sudo apt install mariadb-server

$ getent passwd ※追加された分だけを抜粋
mysql:x:112:116:MySQL Server,,,:/nonexistent:/bin/false

$ getent group ※追加された分だけを抜粋
mysql:x:116:

■Apacheのインストール

パッケージをインストールし、ポート80番を開ける。

http://temp.hogeserver.hogeddns.jp にアクセスしてみる。

$ sudo apt install apache2
$ sudo ufw allow http comment HTTP

$ getent passwd ※ここではユーザーが追加されなかった
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin ← 多分こいつが使われる

$ getent group ※ここではグループが追加されなかった
www-data:x:33: ← 多分こいつが使われる

■Kopanoのインストール

パッケージをインストールする。Kopanoはいくつものサービスが協調して動くのだけれども、ライブラリ的な依存関係はない模様。なので個別に設定。

$ sudo apt install kopano-webapp-apache2 kopano-utils kopano-dagent kopano-search kopano-spooler kopano-monitor kopano-gateway kopano-ical

[Configuring kopano-server]
Configure database for kopano-server with dbconfig-common?
※Google先生の翻訳
　これはオプションでdbconfig-commonで処理できます。
　あなたが上級データベース管理者であり、この設定を手動で実行したいことを知っている場合、
　またはデータベースが既にインストールされ設定されている場合は、このオプションを拒否するべきです。
　何をする必要があるかについての詳細は、おそらく/usr/share/doc/ kopano-serverで提供されるべきです。
　そうでなければ、おそらくこのオプションを選ぶべきです。
　dbconfig-commonでkopano-server用のデータベースを構成しますか？
→ YES

MySQL application password for kopano-server:
※Google先生の翻訳
kopano-serverがデータベースサーバーに登録するためのパスワードを入力してください。
空白のままにすると、ランダムなパスワードが生成されます。
→ 空白(どうせ、後でConfigファイルとかで見られるはず)


$ getent passwd ※追加された分だけを抜粋
kopano:x:113:117:Kopano,,,:/var/lib/kopano:/usr/sbin/nologin

$ getent group ※追加された分だけを抜粋
kopano:x:117:

kopano-webapp-apache2はKopanoのWeb用アプリ。kopano-serverには依存しているが…

kopano-dagentはメールをインポートする際に使うコマンド、kopano-spoolerは保留されたEメールを配信、kopano-searchは検索用のインデックス貼り、kopano-monitorはクオータの監視をする。で、kopano-utilsはユーザー追加とかをするコマンドを含んでいるから絶対に必要。

kopano-gatewayはPOP3, POP3S, IMAP, IMAPSのリスナーになり、kopano-icalはiCal, CalDAVのリスナーになるらしいが、Z-pushするからいらないかな…多分だけど、必要なければインストールしなくても良さそう…。

kopano-serverとkopano-dagentは有効になっていない。このインストールの仕方のせい？何かの間違い？手動で有効化する。

$ sudo systemctl enable kopano-server
Synchronizing state of kopano-server.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable kopano-server
※怒られた

$ sudo /lib/systemd/systemd-sysv-install enable kopano-server
$ sudo /lib/systemd/systemd-sysv-install enable kopano-dagent

これで再起動後も起動するだろう。

■Z-Pushのインストール

D-Pushにリブランドされているのかと思いきや、Z-Pushのままで用意されていた。

色々な仕組みに対応しているらしいのだけれど、今回はKopanoを使っているので恐らくこれ。

Z-Push Home / Installation

$ sudo apt install z-push-backend-kopano

■各システムをつなげていく

これまでバラバラにインストールしたアプリケーションたちをつないでいく。

 ┌───────────┐      ┌────┐
 │         Apach        │      │ Postfix│
 └─┬───────┬─┘      └─┬──┘
     │              │              │
 ┌─┴──┐    ┌─┴──┐        │
 │ Kopano ├──┤ Z-push │        │
 └─┬──┘    └────┘        │
     │                              │
 ┌─┴───────────────┴──┐
 │                 MariaDB                │
 └────────────────────┘

こんなつなぎ方になるから…

• Apach → Kopano


• Kopano → MariaDB


• Postfix → MariaDB


• Apach → Z-push


• Z-push → Kopano

を1つ1つ設定。

Apach → Kopano は、いわゆる httpd.conf 的なもので index.php が呼び出せるようにすれば良い。

サブディレクトリでサービスを提供したことで設定が複雑化した過去の反省から、サブディレクトリ形式ではなくサブドメイン形式で定義してみようと思う。

赤文字部分が追加箇所で、黒いところは元々あったやつ。

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>
    ServerName temp.hogeserver.hogeddns.jp
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

<VirtualHost *:80>
    ServerName kopano.temp.hogeserver.hogeddns.jp
    ServerAdmin hogeuser@temp.hogeserver.hogeddns.jp

    ErrorLog ${APACHE_LOG_DIR}/kopano_error.log
    CustomLog ${APACHE_LOG_DIR}/kopano_access.log combined

    # Kopano WebApp
    Alias / /usr/share/kopano-webapp/
    include /etc/kopano/webapp/apache2.conf

</VirtualHost>

アクセスしようとしたらエラーが出たので調べてみたら、本来はSSLが必要みたい。

これは以下で回避。SSLの設定は今回のテストの範囲外。

www.pc-howto.com / INSTALLATION: KOPANO – DER „NEUE“ STERN AM GROUPWAREHIMMEL – TEIL 1 (LAMP INSTALLATION)

/etc/kopano/webapp/config.php

#     define("INSECURE_COOKIES", false);
      define("INSECURE_COOKIES", true);

反映。

$ sudo systemctl reload apache2
$ sudo systemctl restart apache2 ← 動きがおかしいときはこれも一応試しておく

http://kopano.temp.hogeserver.hogeddns.jp でアクセスすると、ログイン画面が出てくる。

これでApach → Kopanoの接続はできた。

Kopano → MariaDB はデータベースユーザーがインストーラーによって作られているので大丈夫だろう。念のため kopano-server を再起動してみた。

$ sudo mysql -u root
MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| kopanoserver       |
| mysql              |
| performance_schema |
+--------------------+
4 rows in set (0.00 sec)

MariaDB [(none)]> select Host, User, Password from mysql.user;
+-----------+---------------+-------------------------------------------+
| Host      | User          | Password                                  |
+-----------+---------------+-------------------------------------------+
| localhost | root          |                                           |
| localhost | kopano-server | *B9ACB0B44160269C26AD0831CC234755BA484B40 |
+-----------+---------------+-------------------------------------------+
2 rows in set (0.00 sec)

MariaDB [(none)]> Bye

$ sudo systemctl restart kopano-server

ユーザーとグループを作ってみりゃ、ちゃんとつながっているかどうかは分かりそうだ。

※passwordのところは、ちゃんとしたパスワードを。-p指定がなければ聞かれると思う。

ubuntu manuals / kopano-admin - Manages Kopano users and stores

$ sudo kopano-admin -c root -p password -e root@temp.hogeserver.hogeddns.jp -f "Adminstrator" -a yes
$ sudo kopano-admin -c hogeuser -p password -e hogeuser@temp.hogeserver.hogeddns.jp -f "Hoge User" -a no
$ sudo kopano-admin -l
User list for Default(3):
        Username        Fullname        Homeserver
        ----------------------------------------------
        SYSTEM          SYSTEM          Kopano
        root            Adminstrator
        hogeuser        Hoge User

SYSTEMは内部ユーザーで、ログインとかはできない。

Postfix → MariaDB はどうだろう？自分の過去記事を見ると3つのファイルをいじる、とある。公式には2つで良さそうだったけど…

Kopano Knowledge Base / Postfix

実際にはmaster.cfをいじらないと、上で作成したrootというユーザーにメールが送れない問題が発生したので、結局3つのファイルをいじる。kopano-dagentはここで間に挟まってるんだなぁ。

/etc/postfix/main.cf

# for Kopano ※ファイルの最後に追記
virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf
mailbox_command = /usr/sbin/kopano-dagent "$USER"
mailbox_transport = kopano: kopano_destination_recipient_limit = 1

/etc/postfix/mysql-aliases.cf ← 新規作成

データベース名、ユーザー名、パスワードは /etc/kopano/debian-db.cfg に答えが書いてある。

熱い情報なので、root以外からは見えないようにchmod で 600 なファイルにする。

# The user name and password to log into the mysql server.
user = kopano-server
password = ***************
hosts = 127.0.0.1
dbname = kopanoserver

# For Postfix 2.2 and later The SQL query template.
# See mysql_table(5) for details.
query = select value from objectproperty where objectid=(select objectid from objectproperty where value='%s' limit 1) and propname='loginname';

/etc/postfix/master.cf

これは実際何をやっているのかが…userに存在しない vmail って書いても正しく動いたりするから、使われないパラメータも書いちゃってるんだと思う。ご容赦。

# for Kopano ※ファイルの最後に追記
kopano    unix  -       n       n       -       10      pipe
  flags=DRhu user=kopano argv=/usr/sbin/kopano-dagent -R ${recipient}

権限変更と反映。

$ sudo chmod 600 /etc/postfix/mysql-aliases.cf
$ sudo systemctl restart postfix

Apach → Z-push は、confファイルに設定を書き入れる。ActiveSyncは本来SSLで暗号化されて使われるべきものだが、今回はテストのためSSLはテストの範囲外とし、80番ポートでやりとりする。

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>
    ServerName temp.hogeserver.hogeddns.jp
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

<VirtualHost *:80>
    ServerName kopano.temp.hogeserver.hogeddns.jp
    ServerAdmin hogeuser@temp.hogeserver.hogeddns.jp

    ErrorLog ${APACHE_LOG_DIR}/kopano_error.log
    CustomLog ${APACHE_LOG_DIR}/kopano_access.log combined

    # Z-push
    Alias /Microsoft-Server-ActiveSync /usr/share/z-push

    # Kopano WebApp
    Alias / /usr/share/kopano-webapp/
    include /etc/kopano/webapp/apache2.conf

</VirtualHost>

※気持ちとしては、Z-PushはWebAppの下に書きたかったけど、WebAppのAliasがルート(/)になっているから、Z-Pushを先に書いておかないとMicrosoft-Server-ActiveSyncにたどり着かないのだった。

Z-push → Kopano はkopano-backendってのをインストールしているわけで、細かな設定はいらないようになっていた。ユーザー・パスワードはユーザー側が各デバイスで入力する。

ここでの設定はタイムゾーンをちょこっと変えるだけ。

/etc/z-push/z-push.conf.php

    // Defines the default time zone, change e.g. to "Europe/London" if necessary
    define('TIMEZONE', 'Asia/Tokyo');

ここまで設定ができたら再起動して、それぞれが正しくつながったか確認しよう。

$ sudo reboot

http://kopano.temp.hogeserver.hogeddns.jp にアクセスし、作成したユーザーでログインする。そうすると質問されるから、Language: 日本語 だけはしっかり選択して Continue する。そうすると、ログインした後の画面が見られる。

ここまでのところで、Kopanoユーザー同士のメール送受信は問題なくできるようになった。

さらに…管理者root君は、webmasterだったり、postmasterだったりする。そこであだ名を付ける。

/etc/aliases

# See man 5 aliases for format
postmaster:    root ← 既に作られていた
webmaster:     root

反映。

$ sudo newaliases

これで、postmaster@temp.hogeserver.hogeddns.jp と webmaster@temp.hogeserver.hogeddns.jp でメッセージが受けられる。

■Postfixでメール送受信ができるように設定する

2004年に発表されたスパム対策技術 S25R を設定したい。

個人的には8年前から利用させていただいており、恐らく不正なメールは転送していない。ログを見れば毎日毎日相当数の不正な要求をはねつけており、ネットワークに不審な動きなし、プロバイダからの警告も一切受けていない。

欠点として、必要なメールも受信できない場合があるのだが、8年利用して7回。気付いたときにはホワイトリストに入れることで、その後は問題なくやりとりができるようになる。利用は一部公共サービスを除いてほとんどが家族間での利用であるが、スパムが届かないので重宝している。

今回はこれにRealtime Blackhole List(RBL)による対策を加え、まだRBLに登録されていないサーバーからのリクエストを S25R のルールで延期・拒否する。過剰設定だが拒否が S25Rによって引き起こされたのかどうか切り分けやすくなると想定。RBLはSPAMHAUSを利用させていただく。

/etc/postfix/main.cf

#smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) ← Banner: 220 temp.hogeserver.hogeddns.jp ESMTP Postfix (Ubuntu)
smtpd_banner = $myhostname ESMTP                      ← Banner: 220 temp.hogeserver.hogeddns.jp ESMTP もしかしたら、UbuntuでPostfixと表示した方が攻撃意欲が失せる？かも
biff = no
append_dot_mydomain = no
delay_warning_time = 4h
readme_directory = no
compatibility_level = 2

smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = temp.hogeserver.hogeddns.jp
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, temp.hogeserver.hogeddns.jp, localhost.hogeserver.hogeddns.jp, localhost
#relayhost =
mynetworks = 172.16.0.0/16 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4

# for Relay (OP25B)
relayhost = [smtp.provider.com]:587 ← 利用しているプロバイダのサーバーを書くところ
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/isp_passwd ← .dbはつけない(付与される)。プロバイダへの接続情報はここに
smtp_sasl_security_options = noanonymous, noplaintext
smtp_sasl_mechanism_filter = cram-md5, plain, login
# for Sub domain postfix ※テストのときに親サーバーで使うかも
#relay_domains = hogeserver.hogeddns.jp temp.hogeserver.hogeddns.jp
#transport_maps = hash:/etc/postfix/transport

# for S25R ※スパム対策
smtpd_client_restrictions =      ← クライアントへの要求、書いた順に評価される
    permit_mynetworks            ← 許可: mynetworksに含まれる
    check_client_access regexp:/etc/postfix/white_list     ← 独自にOKとしたルール(7件登録)
    check_client_access regexp:/etc/postfix/white-list.txt ← 提供していただいているホワイトリスト(週1回ダウンロード)
    reject_rbl_client zen.spamhaus.org                     ← RBLによる拒否
    check_client_access regexp:/etc/postfix/rejections     ← S25R拒否条件。論文で説明されているファイルの内容。GENERIC PROTECTION 以下が重要
smtpd_helo_required = yes        ← 相手に自己紹介を要求
smtpd_helo_restrictions =        ← 相手のHELO・EHLOコマンドを判定
    permit_mynetworks            ← 許可: mynetrowksに含まれる(効果があるのか未確認)
    reject_invalid_helo_hostname ← 拒否: ホスト名が不正な形式の場合に拒否
    check_helo_access regexp:/etc/postfix/helo_restrictions
                                 ↑ 拒否: 拒否ファイルによる。だが、現状中身は空っぽ。
smtpd_sender_restrictions =      ← 相手のMAIL FROMコマンドを判定
    permit_mynetworks            ← 許可: mynetrowksに含まれる(効果があるのか未確認)
    reject_non_fqdn_sender       ← 拒否: fromアドレスがFQDNではない
    reject_unknown_sender_domain ← 拒否: ウチが最終宛先ではない AND (fromドメインがMXやAレコードを持たない or MXレコード異常)

# for Kopano
virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf
mailbox_command = /usr/sbin/kopano-dagent "$USER"
mailbox_transport = kopano: kopano_destination_recipient_limit = 1

ホワイトリストは週に1回ダウンロード。システム全体の設定なので、crontabに書き込んでしまう。時間とかを気にしないなら、/etc/cron.weekly にシェルを放り込んでおけば良い。

毎週月曜日の朝4:55にダウンロード。

/etc/crontab

# 分 時 日 月 曜日(0:日曜 1:月曜…) ユーザー 実行するコマンド
55 4 * * 1   root    /root/download_whitelist

ホワイトリストをダウンロードするシェル。更新時間を比較して新しければダウンロード。

/root/download_whitelist

#!/bin/sh
wget http://www.gabacho-net.jp/anti-spam/white-list.txt -N -P /etc/postfix

S25Rの拒否条件は論文から切り出して作成。

/etc/postfix/rejections

# S25R client rejection specifications for Postfix
# Contributed by ASAMI Hideo (Japan), Jun 2004; Jul 2007
# Refer to: http://www.gabacho-net.jp/en/anti-spam/
#
# To use this file, add following lines into the /etc/postfix/main.cf file:
#
# smtpd_client_restrictions =
#   permit_mynetworks,
#   check_client_access regexp:/etc/postfix/white_list
#   check_client_access regexp:/etc/postfix/rejections
#
# where "rejections" is the name of this file.
※ブラックリスト部分はカット
#
# *** GENERIC PROTECTION ***
#
# [rule 0]
/^unknown$/                         450 reverse lookup failure, be patient

… 最後のところまでコピペ。

# ex.: xdsl-5790.lubin.dialog.net.pl
/^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9]/    450 S25R check, be patient

HELOコマンドの拒否リストも論文ベース。コメントだけだがコピーして作成。

/etc/postfix/helo_restrictions

# Illegal HELO command blocking specification
# Provided that your mail server's IP address is 223.12.34.56 and its
# acceptable domain name is "example.com", specify as follows:
#
#/^\[?223\.12\.34\.56\]?$/                      REJECT
#/^(.+\.)?example\.com$/                        REJECT

OP25Bに対応したプロバイダを利用しているので、以下に示された方法で設定。

受信したメールはKopanoに放り込まれるので、送信部分だけどうにかすれば良さそう。

パソコンおやじ / OP25B対策(Outbound Port 25 Blocking対策)

main.cf で # for Relay (OP25B) のあたりで書いたことがそれ。

プロバイダへの接続設定はこんな感じで記載。

/etc/postfix/isp_passwd

[smtp.provider.com]:587 UserID:Password

これを書いたら、以下のコマンドでハッシュ化。

/etc/postfix/isp_passwd.dbができあがる。元のファイルは消してもOK。

$ sudo postmap /etc/postfix/isp_passwd
$ sudo chmod 600 /etc/postfix/isp_passwd.db
$ sudo chmod 600 /etc/postfix/isp_passwd ← 消してもOK。今回は取っておいた。

ここまで設定したら、postfixを再起動して設定を反映させる。

$ sudo systemctl restart postfix

設定をしくじっても postfix が mail.err にエラーを出力するのは最初の1回だけだった。

次にエラーが表示されるのは、それが実際に利用されるときになるそうな。時々設定を自動読込することがその設計のベースになっていると想像、すごいけど怖い。

/var/log/mail.log を見てみるとこんな感じ。設定を変えたらkopanoユーザー同士のメール送受信のテストをすべし。

May  4 07:22:18 temp postfix/smtpd[3690]: error: open /etc/postfix/white_list: No such file or directory
この間に何度 postfix を再起動してもエラーは出力されないが、メールを自分自身に1通出してみたらエラーが表示された。
May  4 07:35:02 temp postfix/smtpd[4854]: error: open /etc/postfix/white_list: No such file or directory

設定ができたと確信できたら25番ポートを開放。

ルーター配下にいる場合には、25番ポートをこのサーバーに転送すれば、外部からのメールを受け取ることができる。

$ sudo ufw allow smtp comment SMTP

今回、ウチで行ったテストでは25番ポートの転送はできない。何故なら…

 ┌───────────┐
 │        router        │
 └─────┬─────┘
             ├──────────────┐
 ┌─────┴─────┐  ┌──────┴───────┐
 │従来君                │  │temp君                      │
 │hogeserver.hogeddns.jp│  │temp.hogeserver.hogeddns.jp │
 │ routerから25番ポート │  │hogeserverからメールのリレー│
 │ の転送を受けている   │  │を25番ポートで待ち受ける    │
 └───────────┘  └──────────────┘

という、既に運用しているたまにメールが届くかもしれないサーバーがあるから。

外部とのメールのやりとりを試そうと思ったとき、従来君からtempにメールを転送して欲しかったがなかなかうまく行かず、結果的に以下にたどり着いた。

従来君 /etc/postfix/main.cf

# for Sub domain postfix ※テストのときに親サーバーで使うかも
relay_domains = hogeserver.hogeddns.jp temp.hogeserver.hogeddns.jp
transport_maps = hash:/etc/postfix/transport

従来君 /etc/postfix/transport

# ローカルネットワークについてはsmtpで回す
# ここにないものは relayhost の設定が使われる模様
.hogeserver.hogeddns.jp    smtp:

従来君でハッシュ化し、反映。

$ sudo postmap /etc/postfix/transport
$ sudo systemctl restart postfix

以上の設定で、インターネットからメールが届く環境ができた。

ログを見てみる。

メールが着信したとき(これは従来君のもの、多分tempと一緒)。

May  4 05:51:19 hogeserver postfix/smtpd[42265]: connect from xxxxx.google.com[nnn.nnn.nnn.nnn]
May  4 05:51:20 hogeserver postfix/smtpd[42265]: 2D8263601F6: client=xxxxx.google.com[nnn.nnn.nnn.nnn]
May  4 05:51:20 hogeserver postfix/cleanup[42269]: 2D8263601F6: message-id=<xxxxxxx@mail.gmail.com>
May  4 05:51:20 hogeserver postfix/qmgr[40902]: 2D8263601F6: from=<xxxxx@gmail.com>, size=2628, nrcpt=1 (queue active)
May  4 05:51:20 hogeserver postfix/smtpd[42265]: disconnect from xxxxx.google.com[nnn.nnn.nnn.nnn] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
May  4 05:51:20 hogeserver postfix/pipe[42271]: 2D8263601F6: to=<hogeuser@hogeserver.hogeddns.jp>, relay=kopano, delay=0.5, delays=0.3/0.01/0/0.19, dsn=2.0.0, status=sent (delivered via kopano service)
May  4 05:51:20 hogeserver postfix/qmgr[40902]: 2D8263601F6: removed

メールを送信するとき。

May  4 05:54:05 temp postfix/smtpd[6821]: connect from localhost.localdomain[127.0.0.1]
May  4 05:54:05 temp postfix/smtpd[6821]: 5440082867: client=localhost.localdomain[127.0.0.1]
May  4 05:54:05 temp postfix/cleanup[6825]: 5440082867: message-id=<kcim.xxxxxx@temp.hogeserver.hogeddns.jp>
May  4 05:54:05 temp postfix/qmgr[6801]: 5440082867: from=<hogeuser@temp.hogeserver.hogeddns>, size=1811, nrcpt=1 (queue active)
May  4 05:54:05 temp postfix/smtpd[6821]: disconnect from localhost.localdomain[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
May  4 05:54:05 temp postfix/smtp[6826]: 5440082867: to=<xxxxx@gmail.com>, relay=smtp.provider.com[nnn.nnn.nnn.nnn]:25, delay=0.12, delays=0.02/0.03/0.05/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 35A553601F6)
May  4 05:54:05 temp postfix/qmgr[6801]: 5440082867: removed

メールを転送するとき(従来君)。

May  4 05:54:08 hogeserver postfix/smtpd[42461]: connect from unknown[172.16.nnn.nnn]
May  4 05:54:08 hogeserver postfix/smtpd[42461]: 35A553601F6: client=unknown[172.16.nnn.nnn]
May  4 05:54:08 hogeserver postfix/cleanup[42464]: 35A553601F6: message-id=<kcim.xxxxxx@temp.hogeserver.hogeddns.jp>
May  4 05:54:08 hogeserver postfix/qmgr[40902]: 35A553601F6: from=<hogeuser@temp.hogeserver.hogeddns.jp>, size=1997, nrcpt=1 (queue active)
May  4 05:54:08 hogeserver postfix/smtpd[42461]: disconnect from unknown[172.16.nnn.nnn] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
May  4 05:54:08 hogeserver postfix/smtp[42465]: 35A553601F6: to=<xxxxxx@gmail.com>, relay=smtp.provider.com[nnn.nnn.nnn.nnn]:587, delay=0.46, delays=0.01/0.01/0.19/0.24, dsn=2.0.0, status=sent (250 2.0.0 x43Ks5Nq007425 Message accepted for delivery)
May  4 05:54:08 hogeserver postfix/qmgr[40902]: 35A553601F6: removed

メールをS25Rで拒否するとき(従来君)。

Apr 23 01:06:58 hogeserver postfix/smtpd[88302]: connect from D964D5AA.static.ziggozakelijk.nl[217.100.213.170]
Apr 23 01:06:59 hogeserver postfix/smtpd[88302]: NOQUEUE: reject: RCPT from D964D5AA.static.ziggozakelijk.nl[217.100.213.170]: 450 4.7.1 <D964D5AA.static.ziggozakelijk.nl[217.100.213.170]>: Client host rejected: S25R check, be patient; from=<webhosting@provider.ne.jp> to=<check212014@gmail.com> proto=ESMTP helo=<rbyisovdjn>
Apr 23 01:07:00 hogeserver postfix/smtpd[88302]: lost connection after RCPT from D964D5AA.static.ziggozakelijk.nl[217.100.213.170]
Apr 23 01:07:00 hogeserver postfix/smtpd[88302]: disconnect from D964D5AA.static.ziggozakelijk.nl[217.100.213.170] ehlo=1 mail=1 rcpt=0/1 rset=1 commands=3/4
May  2 11:32:25 hogeserver postfix/smtpd[129885]: connect from 60-251-231-190.HINET-IP.hinet.net[60.251.231.190]
May  2 11:32:25 hogeserver postfix/smtpd[129885]: NOQUEUE: reject: RCPT from 60-251-231-190.HINET-IP.hinet.net[60.251.231.190]: 450 4.7.1 <60-251-231-190.HINET-IP.hinet.net[60.251.231.190]>: Client host rejected: S25R check, be patient; from=<test@provider.ne.jp> to=<test@gmail.com> proto=SMTP helo=<win2012.domain>
May  2 11:32:27 hogeserver postfix/smtpd[129885]: lost connection after RCPT from 60-251-231-190.HINET-IP.hinet.net[60.251.231.190]
May  2 11:32:27 hogeserver postfix/smtpd[129885]: disconnect from 60-251-231-190.HINET-IP.hinet.net[60.251.231.190] helo=1 mail=1 rcpt=0/1 commands=2/3

May  4 00:04:50 hogeserver postfix/smtpd[18766]: connect from unknown[220.126.80.28]
May  4 00:04:50 hogeserver postfix/smtpd[18766]: NOQUEUE: reject: RCPT from unknown[220.126.80.28]: 450 4.7.1 <unknown[220.126.80.28]>: Client host rejected: reverse lookup failure, be patient; from=<cxnmxvdshje@ebbstudy.com> to=<photo053@hanmail.net> proto=SMTP helo=<__--__>
May  4 00:09:51 hogeserver postfix/smtpd[18766]: timeout after DATA from unknown[220.126.80.28]
May  4 00:09:51 hogeserver postfix/smtpd[18766]: disconnect from unknown[220.126.80.28] helo=1 mail=1 rcpt=0/1 data=0/1 commands=2/4

とかとか。メール着信や転送するときには(queue active)が表示されるが、これらはキューに入らない。
後、S25Rではないが、こういうのも結構見られる。

May  2 11:56:41 hogeserver postfix/smtpd[724]: connect from unknown[185.234.216.229]
May  2 11:56:42 hogeserver postfix/smtpd[724]: disconnect from unknown[185.234.216.229] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
May  2 12:00:03 hogeserver postfix/anvil[726]: statistics: max connection rate 1/60s for (smtp:185.234.216.229) at May  2 11:56:41
May  2 12:00:03 hogeserver postfix/anvil[726]: statistics: max connection count 1 for (smtp:185.234.216.229) at May  2 11:56:41
May  2 12:00:03 hogeserver postfix/anvil[726]: statistics: max cache size 1 at May  2 11:56:41

1分間の接続要求がおかしなことになっていると見られる。
こんなのがしょっちゅう届くわけで、踏み台にならないように設定には注意したい。

■さいごに

Ubuntu(Debian?)がKopanoを取り込んでくれたことで、少なくともUbuntu18.04では相性とかを気にしないでサクッと apt install kopano* できちゃうので、最初にZarafaでサーバーを構築した当時に比べて格段に安心。ありがとうございます！

Kopanoはコミュニティ版を使わせていただいている身。正直なところアップデートに対応できずに置きっぱなしになっている。つーか、ぶっちゃけ、Kopanoのアップデートを一発でやり遂げる自信がなくてメインサーバーはUbuntu16.04のままになっている。どっかで設定方法を整理しておく必要があったから、今回トライしてみた。

Ubuntu18.04における設定方法を詳しく書いているところがどうにも見つからなくて、自分の過去記事ベースで作業したけれども、当時は訳わかんないまんまでやってたことがよく分かった。今となってはちょっと恥ずかしいが、まぁいいや、今もわかんないことあるし、今の俺の役には立ったから。

それと、改めてS25Rの凄さを感じる。発表から10年以上たつのに色あせない鉄壁の守り！個人として約8年にもわたってインターネットにメールサーバーを安心してさらしておけたことに、感謝の気持ちでいっぱいになる。ありがとうございます！

後は新しいサーバーの中身が充実させられるかどうかがポイント。うまくいくといいな。

Samba-ad-dc の操作メモ。

今回は、ユーザー追加、ホームディレクトリの設定、ポート開放について記載。

■ユーザー追加

Samba AD DC環境でユーザーを追加するとき、過去記事ではWindowsのGUIに頼っていた。

コマンドでやってみようと思い立ったのでここに。

参考：

SambaWiki / Adding users with samba tool

Sugio Laboratory / SAMBA4のDCオペレーション

まず、DDNSを実現するためのユーザーを作ってみた。

■Ubuntuに登録されたdhcpdの情報を調べておく
$ getent passwd | grep dhcpd
dhcpd:x:111:117::/var/run:/usr/sbin/nologin

■ユーザー追加(dhcpd)
$ sudo samba-tool user create dhcpd --uid-number 111 --gid-number 117 --unix-home /var/run --login-shell /usr/sbin/nologin
New Password:    ← ここで dhcpd ユーザーのパスワードを設定
Retype Password: ← 再入力

$ id myhome\\dhcpd
uid=111(dhcpd) gid=117(dhcpd) groups=117(dhcpd),100(users),3000009(BUILTIN\users)

$ getent passwd | grep dhcpd
dhcpd:x:111:117::/var/run:/usr/sbin/nologin
MYHOME\dhcpd:*:111:100::/home/dhcpd:/bin/bash

■グループ追加
$ sudo samba-tool group addmembers DnsAdmins dhcpd
Added members to group DnsAdmins
$ sudo samba-tool group removemembers users dhcpd
Removed members from group users

$ id myhome\\dhcpd
uid=111(dhcpd) gid=117(dhcpd) groups=117(dhcpd),100(users),3000038(MYHOME\dnsadmins),3000009(BUILTIN\users)
$ sudo samba-tool group listmembers dnsadmins
dhcpd ← idコマンドの確認結果はちょっと変だけど、DnsAdminsに登録されているのでOKとした。

■パスワードの期限をなくす
$ sudo samba-tool user setexpiry dhcpd --noexpiry
Expiry for user 'dhcpd' disabled.

そうそう、自分ユーザーも作っとこ。

■Ubuntuに登録されたhogeの情報を調べておく
$ getent passwd | grep hoge
hoge:x:1000:1000:Hoge Hoge:/home/hoge:/bin/bash

■ユーザー追加
$ sudo samba-tool user create hoge --uid-number 1000 --gid-number 1000 --unix-home /home/hoge --login-shell /bin/bash
New Password:
Retype Password:
User 'hoge' created successfully

$ id myhome\\hoge
uid=1000(hoge) gid=1000(hoge) groups=1000(hoge),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd),100(users),3000009(BUILTIN\users)

$ getent passwd | grep hoge
hoge:x:1000:1000:Hoge Hoge:/home/hoge:/bin/bash
MYHOME\hoge:*:1000:100::/home/hoge:/bin/bash

作り方はdhcpdさんと同じ。

■ホームディレクトリの設定

サーバーにWindows共有でアクセスしようとしたらホームディレクトリに行けなかった。

以下を追加。

[homes]
    path = %H
    read only = No
    browseable = No

※pathには従来%Uを使っていたんだけど、0x80070043エラーになった。/var/log/samba/log.smbdを見てみたら、

canonicalize_connect_path failed for service home, path /home/hoge_hogeserver.hogeddns.jp

とかになっていて、そりゃアクセスできるわけがないな、ということで%Hにした。

設定反映。

$ sudo systemctl reload samba-ad-dc
$ sudo systemctl restart samba-ad-dc ← 色々いじってキャッシュ？のためか設定反映されないとき

■ポート開放

で、Sambaが利用するポートについて調べてみたところ、ここにきっちりと書いてある。

Samba Wiki / Samba AD DC Port Usage

インターネットに向けてポートが開いているケースがあるよー、と警告されているとかいう文言を検索中にチラチラ見たから、内側に向けてだけポートを開放しよう。

$ sudo ufw allow to any port 445 proto tcp from 172.16.0.0/16 comment "SAMBA SMB over TCP"
$ sudo ufw allow to any port 445 proto tcp from fdnn:nnnn:nnnn:nnnn::/64 comment "SAMBA SMB over TCP"
$ sudo ufw allow to any port 445 proto tcp from 24nn:nnnn:nnnn:nnnn::/64 comment "SAMBA SMB over TCP"

※コメントを付けておくと、後で「なんでこのポート開いてるんだっけ？」というあるあるな無駄時間を避けることができる。

グローバールなIPv6アドレスについては、その割り当て範囲をよく確認してから開けないと、結局インターネットに向かってポートがあいてしまうことになるだろう…。

もっとも、ルーターのポートを開放しない限りは外からのパケットを受け付けたりはしないのかもしれないけど、そういうつもりが実は間違ってルーターが開いちゃってましたテヘペロって可能性もなくはないので、念のためきちっと整理しておく。

それと、KerberosやLDAPなんかも Samba AD DC は内包しているから、これらを利用する場合にはポートを開けておく必要がありそう。

やりたいことはいっぱいあるけど、サーバーがプアーなので1つのサーバーに色々組み込んで運用してきた。だが、サーバーを再起動するのに時間がかかるようになってきたから、基本的なサービスとアプリケーション的なサービスを分けてみようというのが今年のGWの活動目標だった。

で、分けていくと痛感するのが今までのサービス提供の方法の悪さ。

ほとんど全てのサービスを hogeserver.hogeddns.jp ドメインで、サブディレクトリで分ける方法を使って提供してきたが、Samba AD DCサーバーを外に立てたら途端にそれが破綻した。

具体的には dc.hogeserver.hogeddns.jp を立てて、Realmを hogeserver.hogeddns.jp に設定してDNSを動かしてみたところ、当たり前だけど、hogeserver.hogeddns.jp の名前解決をすると dc のアドレスが帰ってくるようになった。

つまり…家の外からアクセスするときには、ルーターがIP指定でパケットを転送してくるから問題なしなのだが、家の中からアクセスすると hogeserver.hogeddns.jp だと dc のアドレスが返り、hogeserver.hogeserver.hogeddns.jp ないしは hogeserver と指定しないと hogeserver のアドレスが返ってこない。これでは宅内に内向きDNSを立てる意味がないのだった。

そのため、基本的なサービスは dc で提供し、HTTPS的なものは全て dc → hogeserver へ転送するように設定してみた。将来的には service.hogeserver.hogeddns.jp 的な公開方法に移行していくにしても、すぐにはできないのだからこの方法しかないな、と。

各システムをシングルサインオンに対応させることも考えると、自分が思うとおりにネットワークを構成するには少し時間がかかりそう。だいたい、うちにはWindows10 HomeやAndroidなどドメインに参加できないデバイスもたくさんあるじゃん…そんな場合はどうすりゃサービスを提供できるんだっけ？とかとか、楽しみがたくさんあるじゃん！やること、やれることがあるのはいいね！

独自ドメインでサーバーを運営するならSSL化が必要か…ということで、Let's Encryptからのワイルドカード指定で証明書を発行してもらうことにした。どうやら、難しくはなさそうなんだけれど…

Let's Encrypt 総合ポータル(非公式解説サイト) で概要をさらっと見て作業を開始。

今日の時点ではUbuntu18.04でもリポジトリからインストールできた。

$ sudo apt install letsencrypt

結論からすると、ドメインとワイルドカード付きドメインを対象として、手動で、マルチドメインに対応したサーバーにdns-01という方法で認証してもらった。

カットアンドトライ。最初にメールアドレスを聞かれてみたり、利用規約を承諾したりしていたのだけれど、色々なエラーが出て止まり、やり方を変えて止まり…以下のような実行結果になった。

$ sudo certbot certonly -d hogeserver.hogeddns.jp -d *.hogeserver.hogeddns.jp --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns-01
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None

-------------------------------------------------------------------------------
You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/hogeserver.hogeddns.jp.conf)

It contains these names: *.hogeserver.hogeddns.jp

You requested these names for the new certificate: hogeserver.hogeddns.jp, *.hogeserver.hogeddns.jp.

Do you want to expand and replace this existing certificate with the new
certificate?
-------------------------------------------------------------------------------
(E)xpand/(C)ancel: E
Renewing an existing certificate
Performing the following challenges:
dns-01 challenge for hogeserver.hogeddns.jp
dns-01 challenge for hogeserver.hogeddns.jp

-------------------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
-------------------------------------------------------------------------------
(Y)es/(N)o: Y

-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.hogeserver.hogeddns.jp with the following value:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue[上記の値をDynamicDNSのTXTレコードに登録してEnter]

-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.hogeserver.hogeddns.jp with the following value:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue[慌てすぎた？再度TXTを更新してEnter]
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/hogeserver.hogeddns.jp/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/hogeserver.hogeddns.jp/privkey.pem
   Your cert will expire on 2019-08-10. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

ちょっと自動化が厳しいので、今後しばらくは時々手で処理。

■やってみたこと

テスト実行してみたらエラーが出た。

$ sudo certbot
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Certbot doesn't know how to automatically configure the web server on this system. However, it can still get a certificate for you. Please run "certbot certonly" to do so. You'll need to manually configure your web server to use the resulting certificate.

最初からつまずいた感じだが…かつてあったテストみたいのはなくなったのかしら？

2019-05-12 10:50:58,570:DEBUG:certbot.main:certbot version: 0.23.0
2019-05-12 10:50:58,571:DEBUG:certbot.main:Arguments: []
2019-05-12 10:50:58,572:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2019-05-12 10:50:58,640:DEBUG:certbot.log:Root logging level set at 20
2019-05-12 10:50:58,641:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-05-12 10:50:58,814:DEBUG:certbot.plugins.selection:Requested authenticator None and installer None
2019-05-12 10:50:58,815:DEBUG:certbot.plugins.selection:No candidate plugin
2019-05-12 10:50:58,815:DEBUG:certbot.plugins.selection:Selected authenticator None and installer None

証明書を利用するサブコマンドで…

• Apacheの自動設定を行う。


• Webサーバー上でこのコマンド実行して*.hogeserver.hogeddns.jpの証明書を取得する。
  
  その際の認証には/var/www/htmlディレクトリを利用する。

としてみた。

$ sudo certbot certonly --webroot -w /var/www/html -d *.hogeserver.hogeddns.jp
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): webmaster@hogeserver.hogeddns.net

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: A

-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o: Y
Obtaining a new certificate
The currently selected ACME CA endpoint does not support issuing wildcard certificates.

IMPORTANT NOTES:
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

認証サーバーが対応していないと。

Qiita / letsencryptでワイルドカード認証を取るぞ！[Ubuntu 18.04][nginx v1.15]

Qiita / Let's Encrypt (certbot) でワイルドカード証明書できた！

じゃあ、対応しているサーバーを設定しよう。

$ sudo certbot certonly --webroot -w /var/www/html -d *.hogeserver.hogeddns.jp --server https://acme-v02.api.letsencrypt.org/directory
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): webmaster@hogeserver.hogeddns.net

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: A

-------------------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about EFF and
our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------------------
(Y)es/(N)o: Y
Obtaining a new certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.

IMPORTANT NOTES:
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

DNS認証が必要だ、と。

本日も乙 / CertbotでDNSによる認証(DNS-01)で無料のSSL/TLS証明書を取得する

$ sudo certbot certonly -d *.hogeserver.hogeddns.jp --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns-01
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for hogeserver.hogeddns.jp

-------------------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
-------------------------------------------------------------------------------
(Y)es/(N)o: Y

-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.hogeserver.hogeddns.jp with the following value:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue[上記の値をDynamicDNSのTXTレコードとして登録してからEnter]
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/hogeserver.hogeddns.jp/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/hogeserver.hogeddns.jp/privkey.pem
   Your cert will expire on 2019-08-10. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

$

できた。Apacheでできあがった証明書を使うように設定する → あれ？ ワイルドカード証明書って、hogeserver.hogeddns.jpそのものには効果がないの？

やり直し…

ということで、一番最初に書いた実行結果となった。

Apacheの設定を自動で行ってくれそうなプラグインがあるので追加でインストール。

いずれできるようになるかもしれないので、メモとして残すレベル。

Let's encrypt / Certbot missing Apache plugin

$ sudo apt install python3-certbot-apache
$ sudo certbot --apache

移転しました

とつぜんマインスイーパーがやりたくなって、Microsoft Store を起動したら「接続を確認してください」と言われた。コード: 0x80072EFD。

Chromeでは問題なくインターネット接続できるよ、これなんでしょ？

結論からすると、Windows10 October 2018 Update (1809) を適用した場合、IPv6を有効にしていないと Microsoft Store、Edge、ストアアプリのMahjongやMinesweeperが起動しない。対策のアップデートなし。※2018/10/14現在(ろっひー調べ)

Windows10 October 2018 Update (1809) に早々にアップデート。ファイルが消える問題は発生しなかったので良かったーと思っていたけど、これはその影響なの？

さらに、Edge も起動すると「このページを表示できません」と言われる。「INET_E_RESOURCE_NOT_FOUND」と表示されることも。これって？

Edgeのエラーは少なくとも October する前には発生していなかったから、どうやらこの２つの問題は October の影響ではないかと思われた。

検索すると、Microsoft Store にアクセスできない問題はちょこちょこ起きるらしい。

なーんだ、と、対策を試したが改善しない・・・これは深刻なのかも。

対策にヒントはこちらに。

https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11182916056

もともと、IPv6は使っていないので無効化していた。そこで、有効にしてみたら接続ができるようになった。

当面、Microsoft Store 等を利用するときだけ IPv6 を有効にすることで運用していくしかなさそう。

Ubuntuがアップをはじめました。

家族のアカウントを作って、音楽が聞けるようにして・・・気持ちよく動くねぇ。

VMware Playerがどうにも動かせないけど、他のに移行していきゃいいか。

本当に移行するとなったら家族の抵抗は大きいだろうけれども、ぶっちゃけ、俺以外はみんなネット利用の殆どをスマホで済ませてるんだよな～、それにちょっとしたネット検索くらいならUbuntuでもChromeを使えば問題なくできるし。

Officeだけが問題になるかな、表示の互換性が完全ではないから。なーんて考えてみると、昔あった国産の素晴らしいワードプロセッサを駆逐したのは大きな罪だよな～、選択肢が狭くなってるもん。

少しずつ移行を考えていこう。真面目にこんなことを考えるときが来るとは…

移転しました

公開中のサーバーを維持しつつv6プラスに移行

前回の記事でUbuntuがアップを始めた…と書いたものの、v6アクセスすると夜のゴールデンタイムのネットワーク速度低下が解消できることがわかり、やってみようかなと考えて申し込み。



光回線ナビ / IPv6対応で速くなる？「IPv6 IPoE + IPv4 over IPv6 接続サービス」って何者？

コムサス / Nifty-V6プラス変更について(IPv6接続オプションではないです)

紆余曲折あったが、関係先のみなさんが親切にしてくれたおかげで開通！だが、v6プラス契約の場合、IPv6のアドレスで公開できるポートが限られる。いわゆるウェルノウンポートは使用できないのだが、ルーターつないじゃったよ速度が早くなっちゃったよ後戻りはできないよ、どーすんの俺？と、長く暗いトンネルの入り口に立ったのだった…

結論から。

• v6プラス契約でゴールデンタイムでも90Mbpsを超える通信が可能になった(Googleのスピードテスト)。


• PPPoE接続でIPv4のアドレスが得られたことで、従来通り各種サービスをインターネットに向けて公開できた。
  
  ゴールデンタイムの場合でも、「インターネット側からの要求」は5～20Mbps程度であるものの、「インターネットへの応答」は90Mbps程度あるかもしれない。※

※かもしれないと書いたのは、相手がv6プラスみたいなサービスでアクセスしてくれば早そうだという予測から。計測してみると、IPv4のPPPoEは下りは遅くなるけれど、上りは高速。

ネットワーク構成は以下の通り。物理と論理がちょっと違っている。実はウチはClass Bのアドレス体系でネットワークを運用している。

     [ Internet ] 物理構成図
          │
      ┌─┴─┐
      │ ONU  │
      └─┬─┘
┌────┴────┐
│Router(1)         │
│IP: 172.16.1.1/16 │
└────┬────┘
      ┌─┴─┐                                                ┌──────┐
      │ HUB  ├──────────────────────┬─┤ WiFi Bridge├─┬─── ・・・
      └─┬─┘                                            │  └──────┘  │
┌────┼──────────────────┐┌────┴────┐┌────┴────┐
│        │                         VMware ESXi││Main PC           ││Android Phone     │
│     (Bridge)                                 ││IP: 172.16.1.2/16 ││IP: 172.16.1.3/16 │
│        ├───────────┐            ││GW: 172.16.1.1    │└─────────┘
│┌───┴─────┐┌────┴─────┐││NS: 172.16.1.100  │
││Router(2)         ││Server              ││└─────────┘
││IP: 172.16.2.1/16 ││IP: 172.16.1.100/16 ││
││GW: 172.16.2.1    ││GW: 172.16.2.1      ││
││PPPoE Connection  ││NS: 172.16.2.1      ││
│└─────────┘└──────────┘│
└───────────────────────┘

論理的には、サーバーはRouter(2)の下に入って別ネットワークを構成する形になる。

論理的には別ネットワークだが、物理的に1つのネットワーク上にあるとMain PCからServerに問題なくアクセスができる。同じ172.16.0.0/16のセグメントにいることがポイントである(もちろん、192.168.nnn.0/24のネットワーク体系でも同じセグメントならOK)。

このことをとある有力な技術者から教えてもらったことで、今回の結論を導き出すことができた。超感謝。

もしも別のセグメントにしていたら、サーバー側にかなりの変更が必要にり、ひょっとすると未だにサービス復旧できていなかったかもしれない。

ネットワークの経路は、

• MainPCやAndroid Phoneは、Router(1)を通ってIPv4 over IPv6、ないしは、IPv6 IPoEでインターネットに接続。[高速]


• ServerはRouter(2)のPPPoE接続を通ってインターネットに接続する。[低速]

となる。[低速]とは書いたものの、昼間はv6プラスと同じとは言わないがかなりの速度が出る。あくまでもゴールデンタイムについてのイメージ記述。

このネットワーク構成にすることにより以下のメリットがある。

• Serverの設定はゲートウェイの変更のみ。これだけでPPPoE接続を通ったインターネットアクセス(従来通り)ができる上に、ネットワーク上の他の端末からも問題なくアクセスができる。


• LAN内の他の端末は設定を変更する必要がない。

得られた結果に満足！

■貸与されたルーターの設定変更

図で言うところの Router(1) の設定変更。

PPPoEブリッジをONにする。

→ 今回NTTから貸与されたルーターはデフォルトでONだったと思う。

これにより、Router(1) 配下に設置予定の Router(2) が PPPoE 接続できるようになる。

■ルーターの構築

図で言うところの Router(2) の構築。

結果からすると、ブロードバンドルータを1つ追加で購入するのが一番簡単な気がする。しかし、Ubuntuでルーターを組んじゃえばいいんじゃね？と思ってしまったがために、ちょっと大変なことになった。

ルーターにするOSとして Ubuntu 18.04 Server を選定。理由は使い慣れているから、ということだけなので新しいものならなんでも大丈夫なんじゃないかと思う。メモリは最低要件の512MBとしたが、設定完了後もメモリが余りまくっているので問題なさそう。

■IPv6無効化

インストールは過去記事ベースで行う。このルーターは従来のIPv4によるサービス公開のために構築するのだから、IPv6は無効化する。IPv6接続はRouter(1)に任せておけば良い。

ついでに、起動時の待ち時間が発生しないようにタイムアウト時間も1秒に変更。

/etc/default/grub

#GRUB_TIMEOUT=10
GRUB_TIMEOUT=1
#GRUB_CMDLINE_LINUX=""
GRUB_CMDLINE_LINUX="ipv6.disable=1"

反映。

$ sudo update-grub

インストール後にアップデートやパッケージのインストールをするので、インターネットに接続できなきゃならない。よって、セットアップ時にIPアドレスは設定せずServerが提供するDHCPサービスを利用し、ルーター化する準備ができてからIPアドレスを変えていく。

■PPPoE接続ができるようにする

具体的なコマンドは以下。

$ sudo apt update; sudo apt dist-upgrade; sudo apt autoremove
$ sudo apt install pppoeconf

ここで、pppoeconfを使ってPPPoE接続の設定情報を作る。

$ sudo pppoeconf ← これでインストール画面になる

pppoeconfの設定は以下の回答で進めた。

• POPULAR OPTIONS
  
  → Yes


• ENTER USERNAME
  
  → 以前使っていたブロードバンドルーターに設定していたユーザー名。


• ENTER PASSWORD
  
  → 同パスワード


• USE PEER DNS
  
  → Yes


• LIMITED MSS PROBLEM
  
  → Yes


• DONE(ブート時に接続を開始するかどうか聞かれている)
  
  → Yes


• ESTABLISH A CONNECTION
  
  → Yes


• CONNECTION INITIATED
  
  → Ok

結果を確かめてみる。

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.nnn/16 brd 172.16.255.255 scope global ens160
       valid_lft forever preferred_lft forever
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1454 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp
    inet nnn.nnn.nnn.nnn peer nnn.nnn.nnn.nnn/32 scope global ppp0
       valid_lft forever preferred_lft forever

pppoeconfによりPPPoE接続ができるようになったから、LANのインターフェースになっているens160の設定を変える。

/etc/netplan/50-cloud-init.yaml

# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        ens160:
            addresses:
            - 172.16.2.1/16 ← Router(2)の計画に合わせて変更
            dhcp4: false
            gateway4: 172.16.2.1 ← Router(2)はGWでもある
            nameservers:
                addresses:
                - 8.8.8.8 ← 実際にはPPPoE開始時にresolv.confが書き換えられるので何でも良いように思われる
                search: []
    version: 2

変更を反映して確認する。

$ sudo netplan apply
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 172.16.2.1/16 brd 172.16.255.255 scope global ens160
       valid_lft forever preferred_lft forever
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1454 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp
    inet nnn.nnn.nnn.nnn peer nnn.nnn.nnn.nnn/32 scope global ppp0
       valid_lft forever preferred_lft forever

ここまでで、Router(2)はインターネットに接続できて、172.16.0.0/16とも接続できるようになった。

■ルーティング設定

ここからルーターとして動作するように設定していく。

まず、カーネルパラメーターを変更し、パケット転送をオンにする。

/etc/sysctl.conf

net.ipv4.ip_forward = 1

--- 攻撃回避メモ(以下は最初から1になっているので設定不要だった)
net.ipv4.tcp_syncookies=1
net.ipv4.icmp_echo_ignore_broadcasts=1

反映。

$ sudo sysctl -p

次に、転送の仕方を書く。今まで ufw を使うなどしてどうにか避け続けてきた iptables だ…。ファイルはどこに作ってもいいと思うんだけど、今回はここに作って実行して直して実行して…を繰り返した。

※危険な設定があれば教えてください…

/root/iptable-settings

#!/bin/sh ← テストを繰り返すにはスクリプトにしたほうが楽チンだった

readonly   thishost='172.16.2.1'
readonly  localarea='172.16.0.0/16'

readonly  myserver1='172.16.1.100'
readonly  myserver2='172.16.1.101' ← 別IPアドレスで公開しているサーバーがあるので書いている

readonly        any='0.0.0.0/0'

readonly  local_nic='ens160'
readonly global_nic='ppp0'


#-------------------------------------------------------------------------------
# Initialize
#-------------------------------------------------------------------------------

# Initialize
iptables -F        ← デフォルトテーブルのチェインを初期化
iptables -t nat -F ← natテーブルのチェインを初期化
iptables -X        ← デフォルトテーブルの組み込み以外のチェインを削除
iptables -Z        ← 全てのチェインのパケットカウンタとバイトカウンタをゼロに
iptables -P INPUT   ACCEPT
iptables -P OUTPUT  ACCEPT
iptables -P FORWARD ACCEPT

iptables -N LOGGING_I ← ログ用のチェーンを先に作っておく
iptables -N LOGGING_F
iptables -N LOGGING_O

# Policy
iptables -P INPUT DROP ← 基本、入力を拒否。ただし、接続済み、あるいはそれに関連するものは許可。
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -P OUTPUT ACCEPT ← 基本、出力を許可。ただし、ローカルパケットが外に出ようとしたら拒否。
iptables -A OUTPUT -o $global_nic -d 10.0.0.0/8     -j LOGGING_O ← LOGGING_Oチェーンに遷移させてDROP。
iptables -A OUTPUT -o $global_nic -d 176.16.0.0/12  -j LOGGING_O
iptables -A OUTPUT -o $global_nic -d 192.168.0.0/16 -j LOGGING_O
iptables -A OUTPUT -o $global_nic -d 127.0.0.0/8    -j LOGGING_O

iptables -P FORWARD DROP ← 基本、転送を拒否。ただし、ローカルから外に出るものはポート135,137:139,445を除いて許可。接続済み、あるいはそれに関連するものは許可。
iptables -A FORWARD -p tcp -i $local_nic -o $global_nic -m multiport --dports 135,137:139,445 -j DROP
iptables -A FORWARD -p udp -i $local_nic -o $global_nic -m multiport --dports 135,137:139,445 -j DROP
iptables -A FORWARD -i $local_nic -o $global_nic -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Loopback
iptables -A INPUT  -i lo -j ACCEPT ← ループバックはすべて許可。
iptables -A OUTPUT -o lo -j ACCEPT


#-------------------------------------------------------------------------------
# Router setting
#-------------------------------------------------------------------------------
iptables -t nat -A POSTROUTING -s $localarea -o $global_nic -j MASQUERADE ← ローカルから外に出るものはマスカレード。


#-------------------------------------------------------------------------------
# Local area network setting
#-------------------------------------------------------------------------------

### DNS
iptables -A INPUT -p udp -i $local_nic -d $thishost --dport 53 -j ACCEPT ← 主にServer(内向きDNSとして稼働)からの問い合わせを受け付ける。

### ICMP
iptables  -A INPUT  -p icmp --icmp-type echo-request -i $global_nic -j ACCEPT -m comment --comment 'ICMP(grobal)'
iptables  -A INPUT  -p icmp --icmp-type echo-reply   -i $global_nic -j ACCEPT -m comment --comment 'ICMP(grobal)'
#iptables -A OUTPUT -p icmp --icmp-type echo-reply   -o $global_nic -j ACCEPT -m comment --comment 'ICMP(grobal)' ← 書き方を忘れないためのメモ
#iptables -A OUTPUT -p icmp --icmp-type echo-request -o $global_nic -j ACCEPT -m comment --comment 'ICMP(grobal)' ← 書き方を忘れないためのメモ
iptables  -A INPUT  -p icmp -i $local_nic -j ACCEPT -m comment --comment 'ICMP(all-ok, local)'
#iptables -A OUTPUT -p icmp -o $local_nic -j ACCEPT -m comment --comment 'ICMP(all-ok, local)' ← 書き方を忘れないためのメモ

### IGMP(この経路でこの接続をするのか微妙なところ)
#iptables -A INPUT  -p igmp -j ACCEPT
#iptables -A OUTPUT -p igmp -j ACCEPT

### SSH
iptables -A INPUT -p tcp -i $local_nic -d $thishost --dport 22 -j ACCEPT


#-------------------------------------------------------------------------------
# Listen on wide area network setting
#-------------------------------------------------------------------------------

### HTTPS
iptables -t nat -A PREROUTING -p tcp -i $global_nic -d $any       --dport 443   -j DNAT --to-destination $myserver1:443
iptables        -A FORWARD    -p tcp -i $global_nic -d $myserver1 --dport 443   -j ACCEPT

### HTTP
iptables -t nat -A PREROUTING -p tcp -i $global_nic -d $any       --dport 80    -j DNAT --to-destination $myserver1
iptables        -A FORWARD    -p tcp -i $global_nic -d $myserver1 --dport 80    -j ACCEPT

### SMTP
iptables -t nat -A PREROUTING -p tcp -i $global_nic -d $any       --dport 25    -j DNAT --to-destination $myserver1
iptables        -A FORWARD    -p tcp -i $global_nic -d $myserver1 --dport 25    -j ACCEPT

### HTTP(Server2)
iptables -t nat -A PREROUTING -p tcp -i $global_nic -d $any       --dport 18080 -j DNAT --to-destination $myserver2
iptables        -A FORWARD    -p tcp -i $global_nic -d $myserver2 --dport 18080 -j ACCEPT

### RTMP(Adobe Systems Flash Time Messaging Protocol)
iptables -t nat -A PREROUTING -p tcp -i $global_nic -d $any       --dport 1935  -j DNAT --to-destination $myserver1
iptables        -A FORWARD    -p tcp -i $global_nic -d $myserver1 --dport 1935  -j ACCEPT

### L2TP
iptables -t nat -A PREROUTING -p udp -i $global_nic -d $any       --dport 1701  -j DNAT --to-destination $myserver1
iptables        -A FORWARD    -p udp -i $global_nic -d $myserver1 --dport 1701  -j ACCEPT

### ISAKMP
iptables -t nat -A PREROUTING -p udp -i $global_nic -d $any       --dport 500   -j DNAT --to-destination $myserver1
iptables        -A FORWARD    -p udp -i $global_nic -d $myserver1 --dport 500   -j ACCEPT

### IPSec NAT Traversal
iptables -t nat -A PREROUTING -p udp -i $global_nic -d $any       --dport 4500  -j DNAT --to-destination $myserver1
iptables        -A FORWARD    -p udp -i $global_nic -d $myserver1 --dport 4500  -j ACCEPT


#-------------------------------------------------------------------------------
# Diffender
#------------------------------------------------------------------------------- 
# 攻撃に対する対策を入れるならここ


#-------------------------------------------------------------------------------
# Logging
#-------------------------------------------------------------------------------

iptables -A LOGGING_I -j LOG --log-level warning --log-prefix "[IPT BLOCK I] " -m limit ← 本番
#iptables -A LOGGING_I -j LOG --log-level warning --log-prefix "[IPT BLOCK I] " ← デバッグ中はこちらの方がチェックしやすい
iptables -A LOGGING_I -j DROP
iptables -A INPUT -j LOGGING_I

iptables -A LOGGING_F -j LOG --log-level warning --log-prefix "[IPT BLOCK F] " -m limit
#iptables -A LOGGING_F -j LOG --log-level warning --log-prefix "[IPT BLOCK F] "
iptables -A LOGGING_F -j DROP
iptables -A FORWARD -j LOGGING_F

iptables -A LOGGING_O -j LOG --log-level warning --log-prefix "[IPT BLOCK O] " -m limit
#iptables -A LOGGING_O -j LOG --log-level warning --log-prefix "[IPT BLOCK O] "
iptables -A LOGGING_O -j DROP
#iptables -A OUTPUT -j LOGGING_O ← ここまできたものはデフォルトポリシーで通過

作成にあたっては、以下で勉強をさせていただいた。

@IT / 習うより慣れろ！ iptablesテンプレート集

Qiita / Ubuntu 16.04 でルータつくる

Nibelungen Code / iptablesでログを取る

ディーネット / iptablesにコメントを加えてみよう

この設定に加えて、以下で晒されている(！)攻撃に対する対策を組み込む。

対策部分はほとんどコピー＆ペーストで追加できると思う。矛盾はない。実際に攻撃してみていないが、それはまた余裕が出てきたらやってみよう。

Qiita / 俺史上最強のiptablesをさらす

このスクリプトを実行し、/var/log/syslogに出力されるログで動作を確認。

プロトコル番号の一覧はこちら。

Wikipedia / プロトコル番号一覧

パケットがどこまで飛んだか確認するのはこちら。

Qiita / 超絶初心者むけtcpdumpの使い方

■設定を恒久化

スクリプトで作った設定は再起動すると消えてしまう。

できあがった設定を恒久化させる必要がある。

Qiita / Ubuntu 16.04 iptables設定（基礎知識）

/etc/network/if-pre-up.d/にスクリプトを保存しておくと、ネットワーク接続が確立する寸前に実行してくれるので、そこでiptablesの設定を復元する、ということの模様。

/etc/network/if-pre-up.d/iptables-settings を新規作成。

#!/bin/sh
/sbin/iptables-restore < /etc/network/iptables.rules
exit 0

※パーミッションは755に。

iptables.rules を作成。

$ sudo iptables-save | sudo tee /etc/network/iptables.rules

再起動して確かめる。

■DynamicDNSサービスへの通知

起動時、PPPoEのセッションが確立したらDynamicDNSサービスに通知がしたい。

使わせていただいているDynamicDNSはメールサーバーにアクセスすることでIPアドレスを通知できるようになっている。通知にはbiffpopが便利なので使わせていただいている。

従来は、Router(1)が何らかの理由で再起動するとIPアドレスが変わってしまうが、それを検知する方法もない…ということで、20分毎に通知をしていた(スミマセン)。

今後はPPPoEのセッションが確立したときに通知が送られるようにすれば良い。

/etc/ppp/ip-up.d/9ddns

#!/bin/sh
/etc/ppp/biffpop -s -c /etc/ppp/.biffpoprc
exit 0

※パーミッションは755に。

また、cronによる通知はDynamicDNSサービスのルールから考えて、日に1回で十分なので修正しておく。

■ログの出力先を変える

こんなにサクッとできるものなのね…知識があるって大事だなぁ。

HACKnOTE / iptablesでdropしたパケットのログの出力先を変える

into the void / syslogの使い方をあらためて整理してみた

ログをiptables.logというところにだけ出すようにする。

/etc/rsyslog.d/30-iptables.conf を新規作成(UFWのをそのまま利用)。

# Log kernel generated UFW log messages to file
:msg,contains,"[IPT " /var/log/iptables.log

# Uncomment the following to stop logging anything that matches the last rule.
# Doing this will stop logging kernel generated UFW log messages to the file
# normally containing kern.* messages (eg, /var/log/kern.log)
& stop ← これにより、syslogにログが出力されなくなる。とても助かる。

反映。

$ sudo systemctl restart rsyslog.service

ついでに、ログローテーションができるようにしておこう。

/etc/logrotate.d/iptables を新規作成(UFWのをそのまま利用)。

/var/log/iptables.log
{
    rotate 54 ← 1年くらい前まで遡ることができれば大丈夫だろうと安易に設定
    weekly
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        invoke-rc.d rsyslog rotate >/dev/null 2>&1 || true
    endscript
}

こちらは、ファイルを作っておけば良く、cron → /etc/cron.daily で日々呼び出される模様。

こんなに簡単に切り分けできるのね…びっくり。

■サーバーの起動順序を変える

ESXi の設定を見直し、Router(2) → Server の順で起動するように変える。

停電→起動！ってなときに、Router(2)が先に起動してPPPoE接続を確立して待ち受け、Serverが起動してウチのネットワークが動き始める…というシナリオだ。

以上で2つ目のルーターが稼働し、従来通りにサービスを提供することができるようになった。

契約変更に伴ってルーターが金曜日の夜に届き、土曜日の午前中に設置…その時点から提供していたサービスが停止し、水曜深夜まで再開することができなかった。ここまでサービス停止が長引いたのは初めてではなかったか。準備不足であった感は否めない。

ん？じゃあ、準備していればできたの？といえば、それがそうでもなくて、まず、iptablesは避けて通ってきたし、IPv6もかじったけど理解できる前に終わってる。そう、困らなきゃ本気にならないし、本気にならないと覚えないという性格なだけに、困った状況を作り出して一気にそれを解決する必要があったのだ。

今にして思えば、古いルーターにもPPPoEブリッジ機能はあったんだから、契約を申し込む前にUbuntuルーターを構築することもできたし、ルーターが届いたからと言ってIPv6接続にこだわらずIPv4接続だけに切り替えてサービスを提供しながらUbuntuルーターを構築することもできた。自信がなければルーターを買ってくるという手もあった。でも、それは今だから思えることであって、暗中模索であってもできるまで突っ走っる性格なんだぜ～。

ということで、やっぱ必然で、避けられなくて、やるしかなかったのですよ。

結果として、iptablesが少しわかり、Ethernetってものが少しわかり、IPv6もわかってきた。

そして、あの有力な技術者の知識は半端じゃねぇということが良くわかった。ネットワークに関する様々な問題に対応しようとするとき、彼が頼りになる仲間であることを再認識できたことは最高だった。

いいことあるじゃん！あるじゃん！すごくあったじゃん！

さぁ、明日からも頑張っていこう！

■起こったこと(1)

新しく貸与されたルータを繋いでIPv4の「静的マスカレード設定」を進めていく…で、テストするとうまく行かなくて、もう一度ルーターの設定画面を見に行くと「静的マスカレード設定」の項目がなくなっている。

おかしいな…出荷時状態に戻してもう一回、もう一回と繰り返したが、「静的マスカレード設定」の項目が途中でなくなっちゃう。URLを覚えておいてアクセスしても怒られる。何だこれ？

Qiita / IPv6プラス環境におけるIPv4ポート公開設定

NORIのブログ / v6プラスを使ってみよう　その１

これを見たら…うーん、なるほど、設定項目は消えるようになっているのね、ウェルノウンポートでサービス公開ができないのね、と理解。同時に[本当に]目の前が暗くなった。

でも、解決策はあって、ルーターがもう1つ必要なのね、とわかった。

疲労コンパイル / v6プラスとIPv4(PPPoE)を併用する（その1）

ルーターは実はあるのだけれど、Wifiルーターなので設置場所が結構重要で動かせない。

じゃあ、線を増やす方法は？と考えたけれども配線工事が必要で大掛かりすぎる。

じゃあ、Linuxで作るか、あぁ、ルーティングか、iptablesか…と茨の道が見えてきたのだった。

■起こったこと(2)

sudoでコマンド実行時にエラーメッセージが表示された。

$ sudo ls
sudo: unable to resolve host router2

/etc/hosts にホスト名を追記して解決。

127.0.0.1       localhost.localdomain   localhost
::1             localhost6.localdomain6 localhost6
127.0.0.1       router2

# The following lines are desirable for IPv6 capable hosts
::1             localhost ip6-localhost ip6-loopback
fe00::0         ip6-localnet
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters
ff02::3         ip6-allhosts

■起こったこと(3) ※未解決

そうだ、IPv6でサービス提供できればいいんじゃね？と一瞬考えた。

利用させていただいている Dynamic DNS サービスはPOP3アクセスでIPを通知するようになっているので、IPv6のアドレスを通知すりゃいいんじゃないの？と。

サーバーはUbuntu 12からアップグレードし続けて運用中。IPv6のIPアドレスは以下で追加・削除ができた。

Quitta / 初歩のipコマンドの使い方（Link、IPアドレス）

/etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 172.16.1.100
netmask 255.255.0.0
gateway 172.16.1.1
dns-domain hogeserver.hogeddns.jp
dns-nameservers 172.16.1.1
iface eth0 inet6 manual
 up   ip -6 addr add xxxx:xxxx:xxxx:xxxx::100/64 dev $IFACE
 down ip -6 addr del xxxx:xxxx:xxxx:xxxx::100/64 dev $IFACE

auto eth0:1
iface eth0:1 inet static
address 172.16.1.101
netmask 255.255.0.0
gateway 172.16.1.1
dns-nameservers 127.0.0.1

反映。

$ sudo systemctl restart networking

※たまに、何度やってもどうにも変更ができなくなることがあった。この場合は再起動…

で、通知にはbiffpopを利用させていただいているのだが、何度やってもIPv4でアクセスしている。なんでだろと調べ直してみたら…

ナカタの Digital Wonder Land / POP3/APOP によるメイルチェッカー IPv6 対応

以前、コンパイルする際にはIPv6を無効化していたので、それでもコンパイルできる方法で作っていた模様。結果、IPv6アクセス部分が含まれていなかった。

改めてコンパイルしたら、IPv6でアドレスを通知するようになった！

※しかし、今度はサーバーのIPv6アドレスを思い通りにコントロールできず、この方向の検討は中断。別途。

■起こったこと(4) ※未解決

Router(2)に別セグメントのIPアドレスを振った。具体的には192.168.1.1を。さらに、Serverに192.168.1.100のアドレスを振った。

ルーティングやIPテーブルに関して調べて調べて試して試して…どうにかローカルにおいた192.168.1.2のテストマシンからApache→Wordpressにアクセスしたらエラーが出た。

設定が自ホストのIPじゃないよ、と。

これはきっとServerに192.168.1.100のアドレスを振るんじゃなくてルーティングすりゃ良さそうだとは思ったものの、iptables の暗中模索が続き、サーバーが停止し続けていたで断念。

■起こったこと(5) ※未解決

なんだか不思議なログが…

Nov 11 05:59:46 router2 kernel: [55808.580792] [IPT BLOCK I] IN=ens160 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=172.16.1.100 DST=<ppp0のIPアドレス> LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=21957 DF PROTO=TCP SPT=44988 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0

※最初はなぜFORWARDしないの？と思ったのだが、宛先がppp0のアドレスなのでINPUTだった。

送ってきているのはサーバーなので、誰が？とこのログが出るタイミングを見計らって以下を実行。

$ sudo lsof -i

結果、以下の表示が…

apache2   4561  www-data   28u  IPv4  39998      0t0  TCP 172.16.1.100:44988-><Router2のpppのホスト名>:https (SYN_SENT)
apache2   4564  www-data   26u  IPv6  35273      0t0  TCP 172.16.1.100:https->172.16.1.nnn:51851 (ESTABLISHED)

そもそも、宅内ネットワークはIPv4とIPv6のデュアルスタックになったので内向きDNSはIPv6対応させたいが、ApacheはIPv6で動いて欲しくない。

Qiita / Apache httpd IPv4のみで通信

これに従って、現在有効なサイト設定のVirtual Hostをすべて書き換えた。

#<VirtualHost *:443>
<VirtualHost 0.0.0.0:443>

だけど、IPv6なのは変わらず。これはApacheの仕様の模様。

そしてHTTPSに対してこんな要求が飛ぶのはなぜ？ということでモジュールを見てみたら、なんだかウチでは使っていないはずのものが動いてるぞ…

$ sudo a2dismod proxy_balancer
$ sudo a2dismod proxy_ftp
$ sudo systemctl restart apache2.service

使ってなさそうなモジュールを止めてみたものの、それでも止まらなかった。

ただ、特段問題が起きているようにも見えないので放っておくことにした。

■起こったこと(6)

なんだか知らないがOUTPUTのパケットがドロップする。おかしいな…

元々は、こんなのを /root/iptable-settings に書いていた。

iptables -P INPUT   DROP
iptables -P OUTPUT  ACCEPT
iptables -P FORWARD DROP
・・・
iptables -N LOGGING
iptables -A LOGGING -j LOG --log-level warning --log-prefix "DROP:" -m limit
iptables -A LOGGING -j DROP
iptables -A INPUT   -j LOGGING
iptables -A OUTPUT  -j LOGGING
iptables -A FORWARD -j LOGGING

デフォルトポリシーがACCEPTなんだから、OUTPUTは基本許されるんだろうと思っていた。

ところが…実際には、設定した色々な評価をすり抜けてここに到達したとき、

iptables -A OUTPUT -j LOGGING

の記述によって出力パケットはLOGGINGチェーンに遷移し、そこでログを出力した後にDROPされてしまうのだった。

これ、参照元のテンプレートでは適切に処理したり、赤文字行を含まない形のテンプレートにしたりして問題がないように整理されていたのだが、その事に気づいたのは学習から7日後のことだった(5日後にサービスをとりあえず復旧したときにはOUTPUTを書いてどうにか動かしていた)。

デフォルトチェーンを通過

　→ 最後に赤文字行で無条件にLOGGINGチェーンに遷移

　　→ 無条件ドロップ

結局、このiptablesの設定はデフォルトポリシーがどんなものであれ、ACCEPTされなかったパケットは結果的にLOGGINGチェーンに遷移し、必ずドロップするのだ。

本編で書いた設定は、「ACCEPTとFORWARDはそもそもデフォルトポリシーがDROPなんだから、LOGGINGチェーンに落ちてドロップしても構わない」訳なので、最後まできたところでLOGGINGチェーンに落として無条件DROPさせることにした。

一方で、OUTPUTはデフォルトポリシーがACCEPTなので問題のあるパケットをLOGGINGチェーンに落としてDROPさせ、問題のないパケットはスルーすることでデフォルトポリシーのACCEPTと判断される設定にした。

これで、DROPしたパケットはすべてログに出力される理想的な状態になった。