Hatena::ブログ(Diary)

..たれろぐ.. このページをアンテナに追加 RSSフィード

2018-03-10

ESXi のパスワードにアンダーバー ( _ ) を入れてはまったら

ESXi 触ってみたんですよ。それで、アンダーバーを含んだパスワードを指定したんですね。
そしたらなんか DCUI にはそのパスワードログインできるものの Web Clientログインできないという状態になりまして。

Login Name の部分を使って入力具合を確認すると、キーボード配列日本語配列の状態でアンダーバーを入れると謎の空白キャラクタが入力されていることが判明。
(なお、キーボード配列が US Default ならしかるべきキーを叩くとちゃんとアンダーバーが入ります)
Web Clientログインフォームでは、日本語配列状態でも正しくアンダーバーが入るので、そこの齟齬で Web Clientログインできなくなっていたようです。

一旦アンダーバーのないパスワードに変更するために、

  1. DCUI で ALT+F1 を押し、 ESXi Shell に移る(事前に ESXi Shell 有効にしておくこと)
  2. passwd コマンドでアンダーバーのないパスワードに一時変更する

と変更した後に、

  1. そのパスワードで Web Clientログインし、Web Client からパスワードを変更する

ということで、アンダーバー入りのパスワードにできました。

今度は DCUI 側で不具合が出るので、DCUI の操作は、キーボード配列を US Default にしておくと
いいでしょう(慣れていない人は記号キーの対応表を用意)

IE11 で Java applet が動かない場合

64bitの Windows 環境で最新の Java を入れていても 「表示中のページは Java を使用しています」と出て、インターネットオプションやらコントロールパネルの Java 設定を弄っても効果が無い場合、

32bit版のJREを入れると動くかもしれない。

http://did2memo.net/2017/01/21/internet-explorer-32bit-or-64bit/

はまったorz

2017-12-03

VyOS と PPPoE と MSS clamp の設定と

先に結論。
VyOS で MSS 制限設定入れる場合、そのトラフィックが出入りする全インタフェース
に set policy route しないといけない。(VyOS 1.1.7時点)

よくあるのが Flets の PPPoE の MTU 1454 byte 環境用に MSS 1414 byte と制限し
たい場合はこんなルールを作って、

policy {
    route PPPOE-IN {
        rule 10 {
            destination {
                address 0.0.0.0/0
            }
            protocol tcp
            set {
                tcp-mss 1414
            }
            tcp {
                flags SYN
            }
        }
    }
}

PPPoEインタフェースLAN インタフェースの両方に指定するのが正解です。

set interfaces ethernet eth0 pppoe 0 policy route PPPOE-IN
set interfaces ethernet eth1 policy route PPPOE-IN

いまいちスマートさに欠けるので、別のスマートな設定方法あるか将来バージョンで
set interface ethernet eth0 pppoe 0 mss-limit 1414 みたいなことができればいいなぁとか思いつつ。

以下のサイトは、自身が過去にも参考にさせてもらったりしてるのですが、どれも LAN
側のみに設定しているだけなので、上手くいかない場合があります。

海外だと同じ問題にぶつかって「双方向で指定しないと」って話があるようなんだけ
れども、国内じゃさっぱり見かけないので。

なんで?というお話


TCP において、MSS のネゴシエーションはコネクション確立時に行われ、SYNパケット
に付けられる MSS オプションを使って双方の MSS を送りあった後、より小さい MSS
をコネクションの MSS として採用するという形で実現されています。

PC1 が MSS1200、 PC2 が MSS1400 の場合、通常時は以下のように MSS 情報の交換が
行われます。

1. PC1 --(SYN    : MSS1200)-> PC2
2. PC1 <-(SYN+ACK: MSS1400)-- PC2
3. PC1 --------(ACK)--------> PC2

1. の時点で、 PC2 は PC1 の MSS を知り、自身の MSS より小さいため MSS = 1200 を
採用します。
2. の時点で、 PC1 は PC2 の MSS を知ることになりますが、自身の MSS のほうが小さい
ため、そちらを採用します。
以降このコネクションでは MSS = 1200 として無難に通信が進むことになります。

問題になるのは以下のように、途中のルータで MSS 制限を加える場合。
PC1, PC2 とも途中経路に制限があるとも知らず、 MSS1460 で通信をしようとしています。
ルータ - PC2 間が PPPoE を挟むので、ルータで MSS1414 に制限しようとします。
このとき、ルータが片方向でしか MSS を変えてくれない場合に問題が生じます。

1. PC1 --(SYN    : MSS1460)-> ルータ --(SYN    : MSS1414)-> PC2 
2. PC1 <-(SYN+ACK: MSS1460)-- ルータ <-(SYN+ACK: MSS1460)-- PC2 
3. PC1 --------(ACK)--------> ルータ --------(ACK)--------> PC2

1. ではルータが MSSを1414を変更して PC2 に伝えるので、 PC2 は MSS=1414 を採用します。
しかしながら、 2. において、ルータが戻りパケットの MSS オプションを変更しないので、
そのパケットを見て PC1 は MSS=1460 で大丈夫だと判断してしまいます。
そうすると、パケットサイズによって PC1 -> PC2 のパケットが落ちたりして不安定な状態
になってしまいます。

set interfaces policy で片方のインタフェースにしか指定しないと、まさにこの状態になって
しまいます。

実際の所、どうなってるの?ということで、 PPPoE インタフェースLAN インタフェースを通る
3way ハンドシェイクをモニタ(tcpdump)した結果を見てみましょう。
LAN内の PC から 59.106.194.36 (d.hatena.ne.jp) に接続してみたときの結果です。

まず、LAN側のみ PPPOE-IN を適用している場合。
LAN 側 IF (eth1) を通る 3way ハンドシェイク は次の通り。

$ monitor interfaces ethernet eth1 traffic filter "host 59.106.194.36"
  0.000000 192.168.0.17 -> 59.106.194.36 TCP 58563 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
  0.014629 59.106.194.36 -> 192.168.0.17 TCP 80 > 58563 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 WS=9
  0.015777 192.168.0.17 -> 59.106.194.36 TCP 58563 > 80 [ACK] Seq=1 Ack=1 Win=65700 Len=0

次に PPPoE インタフェースをモニタした結果。
$ monitor interfaces pppoe pppoe0 traffic filter "host 59.106.194.36"
  0.000000 218.211.81.60 -> 59.106.194.36 TCP 58548 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1414 WS=2
  0.014321 59.106.194.36 -> 218.211.81.60 TCP 80 > 58548 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 WS=9
  0.015360 218.211.81.60 -> 59.106.194.36 TCP 58548 > 80 [ACK] Seq=1 Ack=1 Win=65700 Len=0

PC -> 59.106.194.36 への MSS は PPPoE に出て行く時点で MSS=1414 に変更されているものの、
59.106.194.36 の応答 SYN パケットのそれは MSS=1460 のまま、変更されていません。


そして、LAN側、PPPoE側の双方に PPPOE-IN を適用した場合では、
$ monitor interfaces ethernet eth1 vif 5 traffic filter "host 59.106.194.36"
Capturing traffic on eth1.5 ...
  0.000000 192.168.0.17 -> 59.106.194.36 TCP 58688 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
  0.013817 59.106.194.36 -> 192.168.0.17 TCP 80 > 58688 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1414 WS=9
  0.014805 192.168.0.17 -> 59.106.194.36 TCP 58688 > 80 [ACK] Seq=1 Ack=1 Win=66456 Len=0
$ monitor interfaces pppoe pppoe0 traffic filter "host 59.106.194.36"
Capturing traffic on pppoe0 ...
  0.000000 218.211.81.60 -> 59.106.194.36 TCP 58678 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1414 WS=2
  0.013987 59.106.194.36 -> 218.211.81.60 TCP 80 > 58678 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 WS=9
  0.015217 218.211.81.60 -> 59.106.194.36 TCP 58678 > 80 [ACK] Seq=1 Ack=1 Win=66456 Len=0

PC -> 59.106.194.36 への SYN パケットと、 59.106.194.36 -> PC の応答SYNパケットの双方で MSS=1414
に変更できていることがわかると思います。

なんでなんでー?というお話


詳細は調べてないのでわからないのですが、 policy route で指定する tcp-mss は iptables の mangle
テーブルの PREROUTING チェインに入るようです。

インタフェースの受信パケットは → PREROUTING チェインで MSS 変更 → ルーティング
ルーティングインタフェースから出力、という流れで処理されるため、 LANインタフェースに指定し
ただけでは、 PPPoE インタフェースで受信されたパケットに対して MSS 変更処理がされず、上に書いた
ような状況に遭遇してしまうと考えられます。
(Linux の受信パケットの流れは 画像検索”iptables prerouting” 参照)

以下、LANインタフェースのみに指定したときの iptables の状態。

$ sudo /sbin/iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 4263 packets, 753K bytes)
 pkts bytes target     prot opt in     out     source               destination 
 342K  142M VYATTA_FW_IN_HOOK  all  --  *      *       0.0.0.0/0            0.0.0.0/0
Chain INPUT (policy ACCEPT 1074 packets, 82127 bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 2841 packets, 628K bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 680 packets, 66835 bytes) pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 3521 packets, 695K bytes) pkts bytes target prot opt in out source destination 306K 138M VYATTA_FW_OUT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0
Chain PPPOE-IN (5 references) pkts bytes target prot opt in out source destination 8559 444K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* PPPOE-IN-10 */ tcp flags:0x02/0x02 TCPMSS set 1414 175K 18M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 /* PPPOE-IN-10000 default-action accept */
Chain VYATTA_FW_IN_HOOK (1 references) pkts bytes target prot opt in out source destination 1072 166K PPPOE-IN all -- eth1 * 0.0.0.0/0 0.0.0.0/0
Chain VYATTA_FW_OUT_HOOK (1 references) pkts bytes target prot opt in out source destination


続いて、 PPPoE 側、LAN 側の双方に指定した場合の iptables の状態。
$ sudo /sbin/iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 172 packets, 23721 bytes)
 pkts bytes target     prot opt in     out     source               destination 
 343K  142M VYATTA_FW_IN_HOOK  all  --  *      *       0.0.0.0/0            0.0.0.0/0
Chain INPUT (policy ACCEPT 60 packets, 5003 bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 99 packets, 18075 bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 45 packets, 4652 bytes) pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 144 packets, 22727 bytes) pkts bytes target prot opt in out source destination 307K 138M VYATTA_FW_OUT_HOOK all -- * * 0.0.0.0/0 0.0.0.0/0
Chain PPPOE-IN (6 references) pkts bytes target prot opt in out source destination 8594 446K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* PPPOE-IN-10 */ tcp flags:0x02/0x02 TCPMSS set 1414 175K 18M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 /* PPPOE-IN-10000 default-action accept */
Chain VYATTA_FW_IN_HOOK (1 references) pkts bytes target prot opt in out source destination 48 11695 PPPOE-IN all -- pppoe0 * 0.0.0.0/0 0.0.0.0/0 1075 166K PPPOE-IN all -- eth1 * 0.0.0.0/0 0.0.0.0/0
Chain VYATTA_FW_OUT_HOOK (1 references) pkts bytes target prot opt in out source destination


経緯

新しく買ったタブレットからのWiFi通信が通らず、あかんやーんとしばらく放って
たところ、古いタブレットでも同じ現象が出ることに気づき、 LTE 経由だとちゃん
通信が通ったので、まず WiFi AP の不具合を疑い、ファーム更新したり再起動
たりでも改善せず、MTU 絡みの可能性を疑って、 MSS がちゃんと変更されてるかパ
ケットキャプチャしてみたところ、戻りパケットで MSS が変更されてないことに気
付き、元設定じゃダメじゃんとなった次第。

PPPoE インタフェースにも set policy route の設定を入れたら、新タブでも通信
できるようになったので、ようやく新タブが使えるようになったorz
PCからの通信も妙に遅かったのもこれのせいだったぽい。

これについて書かれたものが見あたらないので、国内だとあまり問題になってない
地雷を踏み抜いたんだろうか…(or VyOSユーザがレアなのか)

VyOSっぽいOSが動くルーター EdgeRouter Lite では機能として MSS clamp が載っ
てる模様。
17,000円で買えるVyOSっぽいOSが動くルーター EdgeRouter Lite(ERLite-3)を使ってみる — どこか遠くでのんびり怠惰に暮らしたい

iptables を触って PPPoE インタフェースの POSTROUTING チェインに無理矢理
TCPMSS を書けばコンフィグ上はシンプルに収まりそうだけど、裏技臭がひどく
て運用的に問題がでそうだし。

2017-11-23

プライマリDNSの設定からセカンダリDNSの設定を起こす

CentOS 7.3 BIND chroot 環境 でのプライマリサーバの設定ファイルから
セカンダリサーバの設定を作る方法。

1. プライマリサーバの named.conf をセカンダリサーバにコピーする。
2. named.conf の allow-transfer を none にする。

allow-transfer { none; };

3. named.conf の zone 設定を変更する。
3-1. type を slave に変更する。
3-2. masters にプライマリサーバIPアドレスを設定する。
3-3. file の頭に slaves を付ける。

zone "example.com" {
        type slave;
        masters {
                192.168.1.5;
       };
        file "slaves/example.zone";
};
zone "1.168.192.in-addr.arpa" { type slave; masters { 192.168.1.5; }; file "slaves/example.rev.zone"; };


/var/log/messages などのログファイルに以下のエラーが出ている場合は、最後の slaves の付け忘れ。zone転送時はsleves下にファイル出力される模様。

 dnsslave named[7455]: dumping master file: tmp-S0N6hyvAgw: open: permission denied

start して /var/named/chroot/var/named/slaves 以下にファイルが出来ていればOK

# systemctl start named-chroot.service

# ls -l /var/named/chroot/var/named/slaves
-rw-r--r--. 1 named named  629 12月 24 22:56 example.rev.zone
-rw-r--r--. 1 named named  531 12月 24 22:56 example.zone

さらに dig でセカンダリに問い合わせて解決できればOK

dig @192.168.1.6 hogehoge.example.com