Ubuntu

Ubuntu 12.04 色々なことが起きているので調べてみるメモ

2013.07.09

logcheckからの報告を見ると、なんだかとにかく色々な報告が出ている。

広告

Zarafa WebApp でログインした途端に以下のブロックメッセージが出る。

Jul  8 22:49:00 hogeserver kernel: [146633.002195] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=3801 DF PROTO=TCP SPT=51441 DPT=80 WINDOW=16423 RES=0x00 ACK FIN URGP=0
Jul  8 22:49:00 hogeserver kernel: [146633.003263] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=3803 DF PROTO=TCP SPT=51434 DPT=80 WINDOW=16174 RES=0x00 ACK FIN URGP=0
Jul  8 22:49:00 hogeserver kernel: [146633.302934] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=3814 DF PROTO=TCP SPT=51441 DPT=80 WINDOW=16423 RES=0x00 ACK FIN URGP=0
Jul  8 22:49:00 hogeserver kernel: [146633.302976] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=3815 DF PROTO=TCP SPT=51434 DPT=80 WINDOW=16174 RES=0x00 ACK FIN URGP=0
Jul  8 22:49:00 hogeserver kernel: [146633.562762] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=3817 DF PROTO=TCP SPT=51443 DPT=80 WINDOW=16423 RES=0x00 ACK FIN URGP=0
Jul  8 22:49:00 hogeserver kernel: [146633.562785] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=3818 DF PROTO=TCP SPT=51442 DPT=80 WINDOW=16423 RES=0x00 ACK FIN URGP=0
Jul  8 22:49:01 hogeserver kernel: [146633.903053] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=3820 DF PROTO=TCP SPT=51441 DPT=80 WINDOW=16423 RES=0x00 ACK FIN URGP=0
Jul  8 22:49:01 hogeserver kernel: [146633.903109] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=3821 DF PROTO=TCP SPT=51434 DPT=80 WINDOW=16174 RES=0x00 ACK FIN URGP=0
Jul  8 22:49:01 hogeserver kernel: [146634.162821] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=3826 DF PROTO=TCP SPT=51445 DPT=80 WINDOW=16285 RES=0x00 ACK FIN URGP=0
Jul  8 22:49:02 hogeserver kernel: [146635.102918] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=40 TOS=0x00 PREC=0x00 TTL=128 ID=3865 DF PROTO=TCP SPT=51441 DPT=80 WINDOW=16423 RES=0x00 ACK FIN URGP=0

 

じゃあ、かならず出るのかというとそうでもなく、暫くの間はログインしても全く出なかったり、ブラウザを落とすと突然出力されたり、と出たり出なかったり。
Zarafaがどーのこーのというよりは、ブラウザが何かやってるんじゃないかと思えてくる。

パケットを見て調べるのが本来だろうけど、その気力なし。

で、結局のところ理解には至っていないが、ココを見るとどうやらACK FINという信号がクライアントから飛んできた時にブロックしているらしい。

ufwでどうやって接続を許可したらいいのかわからなくて、以下を追加してみた。

/etc/ufw/before.rules

# ブラウザでアクセスするとBLOCKが出まくる件への対応
-A ufw-before-input -p tcp --dport 80 --tcp-flags FIN,ACK FIN -j ACCEPT
-A ufw-before-input -p tcp --dport 80 --tcp-flags ACK,FIN,ACK FIN -j ACCEPT
-A ufw-before-input -p tcp --dport 80 --tcp-flags ACK,FIN ACK,FIN -j ACCEPT


# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

 

その後、ufwを一旦無効化し、有効化する。

$ sudo ufw disable
$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y

 

これで出なくなるっぽい。
この設定で良いか悪いかわからないけれども、apacheはエラーを吐いていないようなので、多分問題はないだろう。

同じようなことが Z-pushでも発生している。

Jul  9 06:47:47 hogeserver kernel: [175359.987824] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=121 TOS=0x00 PREC=0x00 TTL=64 ID=47512 PROTO=TCP SPT=60395 DPT=10443 WINDOW=8192 RES=0x00 ACK PSH FIN URGP=0
Jul  9 06:47:47 hogeserver kernel: [175359.988818] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=121 TOS=0x00 PREC=0x00 TTL=64 ID=55943 PROTO=TCP SPT=60394 DPT=10443 WINDOW=8192 RES=0x00 ACK PSH FIN URGP=0
Jul  9 06:47:53 hogeserver kernel: [175366.684219] [UFW BLOCK] IN=eth0 OUT= MAC=nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn:nn SRC=172.16.nnn.cli DST=172.16.nnn.nnn LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=53388 PROTO=TCP SPT=60394 DPT=10443 WINDOW=8192 RES=0x00 ACK RST URGP=0

 

以下を追加する。
/etc/ufw/before.rules

# Z-pushでも問題が発生する件への対応
-A ufw-before-input -p tcp --dport 10443 --tcp-flags RST,PSH FIN -j ACCEPT
-A ufw-before-input -p tcp --dport 10443 --tcp-flags ACK,FIN ACK,FIN -j ACCEPT
-A ufw-before-input -p tcp --dport 10443 --tcp-flags ACK,PSH ACK,PSH -j ACCEPT
-A ufw-before-input -p tcp --dport 10443 --tcp-flags ACK,RST ACK,RST -j ACCEPT

 

2015/5/6追記 マニュアルによれば

Allows TCP packets with specific bits, or flags, set to be matched with a rule.
The --tcp-flags match option accepts two parameters.
The first parameter is the mask, which sets the flags to be examined in the packet.
The second parameter refers to the flag that must be set to match.
The possible flags are:
・ACK
・FIN
・PSH
・RST
・SYN
・URG
・ALL
・NONE

ほぼGoogle先生による翻訳。
特定のビットかフラグがセットされたTCPパケットがルールに合致すれば許可します。
--tcp-flags 照合オプションは、2つのパラメータを受け取ります。
最初のパラメータはマスクで、パケットの検査対象となるフラグを設定します。
2番目のパラメータが参照するフラグは、合致するように設定されていなければなりません。

 

その後、ufwを一旦無効化し、有効化する。

$ sudo ufw disable
$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y

 

これで様子を見てみる。

iPhoneからSoftbank回線でVPNに接続すると、ipsec関連の対話の情報がそのままログに出力される。2013/07/10追記

Jul 10 08:40:48 hogeserver pluto[1825]: packet from 126.nnn.nnn.nnn:500: received Vendor ID payload [RFC 3947] method set to=109
Jul 10 08:40:48 hogeserver pluto[1825]: packet from 126.nnn.nnn.nnn:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
Jul 10 08:40:48 hogeserver pluto[1825]: packet from 126.nnn.nnn.nnn:500: ignoring unknown Vendor ID payload [8hexhexhexhexhexhexhexhexhexhex8]
Jul 10 08:40:48 hogeserver pluto[1825]: packet from 126.nnn.nnn.nnn:500: ignoring unknown Vendor ID payload [4hexhexhexhexhexhexhexhexhexhex2]
Jul 10 08:40:48 hogeserver pluto[1825]: packet from 126.nnn.nnn.nnn:500: ignoring unknown Vendor ID payload [4hexhexhexhexhexhexhexhexhexhex5]
Jul 10 08:40:48 hogeserver pluto[1825]: packet from 126.nnn.nnn.nnn:500: ignoring unknown Vendor ID payload [8hexhexhexhexhexhexhexhexhexhexe]
Jul 10 08:40:48 hogeserver pluto[1825]: packet from 126.nnn.nnn.nnn:500: ignoring unknown Vendor ID payload [9hexhexhexhexhexhexhexhexhexhexb]
Jul 10 08:40:48 hogeserver pluto[1825]: packet from 126.nnn.nnn.nnn:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
Jul 10 08:40:48 hogeserver pluto[1825]: packet from 126.nnn.nnn.nnn:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
Jul 10 08:40:48 hogeserver pluto[1825]: packet from 126.nnn.nnn.nnn:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
Jul 10 08:40:48 hogeserver pluto[1825]: packet from 126.nnn.nnn.nnn:500: ignoring Vendor ID payload [FRAGMENTATION 80000000]
Jul 10 08:40:48 hogeserver pluto[1825]: packet from 126.nnn.nnn.nnn:500: received Vendor ID payload [Dead Peer Detection]
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[9] 126.nnn.nnn.nnn #9: responding to Main Mode from unknown peer 126.nnn.nnn.nnn
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[9] 126.nnn.nnn.nnn #9: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[9] 126.nnn.nnn.nnn #9: STATE_MAIN_R1: sent MR1, expecting MI2
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[9] 126.nnn.nnn.nnn #9: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): both are NATed
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[9] 126.nnn.nnn.nnn #9: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[9] 126.nnn.nnn.nnn #9: STATE_MAIN_R2: sent MR2, expecting MI3
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[9] 126.nnn.nnn.nnn #9: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[9] 126.nnn.nnn.nnn #9: Main mode peer ID is ID_IPV4_ADDR: '172.nnn.nnn.nnn'
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[9] 126.nnn.nnn.nnn #9: switched from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #9: deleting connection "L2TP-PSK-NAT" instance with peer 126.nnn.nnn.nnn {isakmp=#0/ipsec=#0}
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #9: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #9: new NAT mapping for #9, was 126.nnn.nnn.nnn:500, now 126.nnn.nnn.nnn:41749
Jul 10 08:40:48 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #9: Dead Peer Detection (RFC 3706): enabled
Jul 10 08:40:49 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #9: Applying workaround for Mac OS X NAT-OA bug, ignoring proposed subnet
Jul 10 08:40:49 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #9: the peer proposed: 125.1.128.169/32:17/1701 -> 126.nnn.nnn.nnn/32:17/0
Jul 10 08:40:49 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #10: responding to Quick Mode proposal {msgid:865c76b2}
Jul 10 08:40:49 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #10:     us: 172.16.nnn.nnn<172.16.nnn.nnn>[+S=C]:17/1701
Jul 10 08:40:49 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #10:   them: 126.nnn.nnn.nnn[172.20.nnn.nnn,+S=C]:17/57809
Jul 10 08:40:49 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #10: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jul 10 08:40:49 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #10: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Jul 10 08:40:50 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #10: Dead Peer Detection (RFC 3706): enabled
Jul 10 08:40:50 hogeserver pluto[1825]: "L2TP-PSK-NAT"[10] 126.nnn.nnn.nnn #10: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2

 

最初のほうで

ignoring Vendor ID payload [FRAGMENTATION 80000000]

 

等と言われているので気にはなるのだが、接続はできている。

ネットで対策を探しきれなかったので、syslogに出力するのをやめさせてみることにした。

/etc/ipsec.conf

config setup
        plutostderrlog=/var/log/pluto

 

$ sudo service ipsec restart

 

これにより、plutoの細かなログは/var/log/plutoに出力される。
iPhoneから切断をするとエラーログが syslog に出るので、なにか致命的な問題が出た時には syslog にエラー内容が出力されるだろうと想像。

これで様子を見てみる。

広告
rohhie

コメントはこちらから お気軽にどうぞ ～ 投稿に関するご意見・感想・他