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

tips

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 が動かない場合

tips

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

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

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

はまったorz

VyOS と PPPoE と MSS clamp の設定と

VyOS tips

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


※2019-03-21 PPPoEインタフェースのみでMSS制限する方法書きました → https://naga-sawa.hatenablog.com/entry/2019/03/21/152748
naga-sawa.hatenadiary.org


よくあるのが 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 を書けばコンフィグ上はシンプルに収まりそうだけど、裏技臭がひどくて運用的に問題がでそうだし。

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

Linux

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

「Java(TM) Platform SE binary は動作を停止しました」 Avast 環境での対処

Java tips

「Java(TM) Platform SE binary は動作を停止しました」が出て java -version も動かない場合

環境

Avast の挙動監視シールドが C:\ProgramData\Oracle\Java\javapath\java*.exe の実行にちょっかい出しているのが原因っぽい。

タスクトレイのアイコンなどからAvastを開く→設定→コンポーネント→挙動監視シールド→カスタマイズ→スキャンから除外
に 「C:\ProgramData\Oracle\Java\*」を追加。

除外パスが「C:\ProgramData\Oracle\Java\javapath\*」でないのは、javapathがJunctionな影響で除外設定が効かないため。
「C:\ProgramData\Oracle\Java\*」だと除外範囲が広くて気持ち悪い、という場合は javapathのJunction先を指定すれば大丈夫（その場合、JDK, JREの更新時などにパスが変更されて、再設定が必要になる可能性があります）

RaspberryPi で tagged VLAN を扱う

RaspberryPi Linux tips

Raspbian jessie で 802.1Q のタグVLANを扱うインタフェースの設定方法について。

vlan パッケージをインストールする。 lsmod | grep 8021q して 8021q が既にいればこの手順は基本不要。

$ sudo apt-get install vlan
$ sudo modprobe 8021q
$ sudo su
# echo 8021q >> /etc/modules
# exit

eth1 にタグ付き VLAN100 を流し込み、 Raspberry Pi 上で VLAN100 を扱うインタフェースを作る場合、

$ sudo vi /etc/network/interfaces

auto eth1
iface eth1 inet manual
    pre-up ifconfig $IFACE up
    post-down ifconfig $IFACE down

auto eth1.100
iface eth1.100 inet manual
    vlan-raw-device eth1
    pre-up ifconfig $IFACE up
    post-down ifconfig $IFACE down

VLAN インタフェースの eth1.100 へのアドレスの割当てなどは dhcpcd.conf でその他普通のインタフェースと同じように書けばOK。
eth1 が DHCP でアドレス取得すると面倒なので noipv4, noipv6 で阻止する。
(denyinterfaces eth1 でいいかもしれない)

sudo vi /etc/dhcpcd.conf

interface eth1
noipv4
noipv6

interface eth1.100
static ip_address=192.168.100.2/24
static routers=192.168.100.1
static domain_name_servers=192.168.100.1

再起動するかサービス再起動で設定反映。

$ sudo service networking restart

参考 :