From owner-freebsd-users-jp@FreeBSD.ORG Wed Apr 1 20:33:46 2015 Return-Path: Delivered-To: freebsd-users-jp@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB60D948 for ; Wed, 1 Apr 2015 20:33:46 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 929BB6DE for ; Wed, 1 Apr 2015 20:33:45 +0000 (UTC) Received: from alph.d.allbsd.org (alph.d.allbsd.org [IPv6:2001:2f0:104:e010:862b:2bff:febc:8956] (may be forged)) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id t31KXV9m089998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2015 05:33:33 +0900 (JST) (envelope-from hrs@allbsd.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.9/8.14.9) with ESMTP id t31KXU8E053177; Thu, 2 Apr 2015 05:33:31 +0900 (JST) (envelope-from hrs@allbsd.org) Date: Thu, 02 Apr 2015 05:31:32 +0900 (JST) Message-Id: <20150402.053132.1512763590932251857.hrs@allbsd.org> To: hiroo.ono+freebsd@gmail.com, chaltier@agate.plala.or.jp From: Hiroki Sato In-Reply-To: <20150331212326.2783.A7D5A726@agate.plala.or.jp> References: <20150330.003733.1964185496119167015.inetd@x.inetd.co.jp> <20150331.013014.1399253678235921793.inetd@x.inetd.co.jp> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Apr__2_05_31_32_2015_000)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Thu, 02 Apr 2015 05:33:38 +0900 (JST) X-Spam-Status: No, score=1.9 required=13.0 tests=CONTENT_TYPE_PRESENT, ISO2022JP_BODY,RCVD_IN_AHBL,RCVD_IN_AHBL_PROXY,RCVD_IN_AHBL_SPAM,RDNS_NONE autolearn=no autolearn_force=no version=3.4.0 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on gatekeeper.allbsd.org X-Mailman-Approved-At: Wed, 01 Apr 2015 20:42:59 +0000 Cc: freebsd-users-jp@freebsd.org Subject: [FreeBSD-users-jp 95501] Re: =?iso-2022-jp?b?aXBmdxskQiRHRkNEahsoQklQGyRCMEozMCROQFwbKEI=?= =?iso-2022-jp?b?GyRCQjMkckU+QXckNyQ/JCQbKEI=?= X-BeenThere: freebsd-users-jp@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion relevant to FreeBSD communities in Japan List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 20:33:47 -0000 ----Security_Multipart(Thu_Apr__2_05_31_32_2015_000)-- Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit 佐藤です。 Hiroo Ono (小野寛生) wrote in : hi> 2015年3月31日 1:30 : hi> > 鈴木＠葛飾区です。 hi> > なんか、最初のご質問を私読み違えてますね。。。リモートへの転送と大変な hi> > 勘違いで。。 hi> > hi> > fwd 127.0.0.1,2222 なのでローカルへの転送なのでnatを使うまでもなくルー hi> > ルにマッチすれば2222に転送されるはずですね。。。 hi> hi> 私もそう思ってはじめはコメントするのを控えたのですが、「BSDカーネルの hi> 設計と実装」13.4節に hi> “ホストが複数のアドレスを持っている場合、パケットはその送信先がこれら hi> のどれかに一致すれば受け入れられる。” hi> とありますので、127.0.0.1:2222 に届いたけれども、パケットの宛先アドレ hi> スとポート番号を見て hi> 192.168.11.3:22 宛のパケットという処理がされているのではないかと思いま hi> す。 hi> ということで、パケットを書き換える NAPT が必要という指摘は正しいはずで hi> す。 hi> よくわかっていませんが。 このケースはローカルへの転送ですので、NAPT は必要ありません。 次の条件 - 127.0.0.1:2222 で listen している sshd と、 192.168.11.3:22 で listen している sshd が、それぞれ 同一のホスト (以降ホスト B と呼びます) に存在している - ホスト B の IPFW の fwd ルールで、192.168.11.3:22 宛のパケットが 127.0.0.1:2222 に転送される が満たされる場合、別のホスト 192.168.11.2 (以降ホスト A と 呼びます) からの TCP 接続要求は、次のような動作になります。 1. 始点 192.168.11.2:E, 終点 192.168.11.3:22 の TCP SYN が A から B に送られる。（E は ephemeral port） 2. IPFW がホスト B 上で 1. のパケットを 127.0.0.1:2222 に転送する。 この時、fwd ルールは、パケットの始点・終点アドレスを書き換えないため、 実際には 127.0.0.1:2222 に送られるにも関わらず、 ホスト B のネットワークスタックが socket レベルで認識する 終点アドレスは 192.168.11.3:22 のままです。 3. 2222 ポートで listen している sshd は、パケットを受け取って accept(2) をコールし、接続用の新しい socket を生成する。 この受け取ったパケットは、192.168.11.2:E -> 192.168.11.3:22 という 始点・終点アドレスとして解釈されるため、ホスト B からの TCP SYN+ACK の返送は、逆転して 192.168.11.3:22 -> 192.168.11.2:E に なります。 つまり、接続用の新しい socket には、ピアの始点として 127.0.0.1:2222 ではなく、192.168.11.3:22 が設定されます。 したがって、実際にパケットは 127.0.0.1:2222 に転送されているにも関わらず、 - A->B 方向の通信は 192.168.11.2:E -> 192.168.11.3:22 - B->A 方向の通信は 192.168.11.3:22 -> 192.168.11.2:E というアドレスにパケットが流れているように見えることになり、 アプリケーションからは、転送の事実は見えません。 sshd などのデーモンは accept した時点で接続用の socket から 通信相手のアドレス・ポート番号を取得しますが、 得られるピアの始点・終点には、127.0.0.1:2222 が現れないということです。 なので、2222/tcp と 22/tcp で待ち受けている 2 つの sshd がホスト B に あって、始点アドレスを条件に IPFW fwd で振り分けた場合、 外からは、どちらも 22/tcp に接続しているように見えます。 127.0.0.1:2222 で待ち受けているのに、192.168.11.3:22 から通信が 行なわれているように動作するのは奇妙な話のように思えますが、 listen しているアドレスと、accept の時の終点アドレスが 異なっているという状態は、特別なものではありません。 たとえばデーモンが INADDR_ANY (0.0.0.0) で listen している場合、 accept して生成される通信用 socket のピア始点アドレスは 当然ながら 0.0.0.0 ではなく、接続してきた相手のアドレスが使われます。 それとまったく同じです。 Tetsuya Ito wrote in <20150331212326.2783.A7D5A726@agate.plala.or.jp>: ch> 結果を纏めますと、 ch> ch> add 1001 pass tcp from any to any established ch> add 1002 fwd 127.0.0.1,2222 tcp from not <特定IP> to me 22 ch> ch> ⇒ 先にestablishedがある場合はNG (22/tcpに接続される) ch> ch> add 1001 fwd 127.0.0.1,2222 tcp from not <特定IP> to me 22 ch> add 1002 pass tcp from any to any established ch> ch> ⇒ 想定通り特定IP以外は2222/tcpに接続される。 ch> ch> という結果となりました。 ch> ch> ただ、ローカルネットの接続まで拒否されてしまうので、ちょっと困ってます。 ch> ローカルネット接続のpassルールをfwdの前に設定するしかないですかね...。 established が先にあると、TCP の最初のパケットだけ 127.0.0.1:2222 に 転送されて、それ以降は 192.168.11.3:22 に送られてしまうため、 動作しないのだと思います。 ローカルネットの接続が拒否される、というのが具体的に 何を指しているのかがよく分からないのですが、 たとえばホスト B 上で "ssh 127.0.0.1" とやった時に 22/tcp ではなく 2222/tcp に接続されてしまうのが困るという話であれば、 to me ではなく to 192.168.11.3 と fwd を限定すれば良いように思います。 -- Hiroki ----Security_Multipart(Thu_Apr__2_05_31_32_2015_000)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlUcVaQACgkQTyzT2CeTzy273ACbB4ghMx0inn4YT3y+DrzV+TIX mUIAoJwo2h6aX+M6n3HJKQ7IBfcKitll =Uvcz -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Apr__2_05_31_32_2015_000)----