タグ:VPN ( 7 ) タグの人気記事
VPN環境で閲覧できないWEBサイトの原因は、MTU...
YAMAHAのRTX1200でVPNを組みました。
構成としては以下のようなスター型のネットワークで、外部へのインターネットもセンター側を経由して行くようにしています。
e0091163_16361044.jpg


さて、拠点側から一部のWEBサイトが見えないという問合せがありました。
例えばMicrosoftのサイト(htt://www.microsoft.com/)とか、借りている一部のレンタルサーバ上のWEBとかです。
IEで見ると、ずっと接続に行ってるような感じですが、何も表示されず最終的にタイムアウトしてしまっているようです。
Googleとかは普通に表示されまし、センター側の端末も何も問題なく表示されます。


ということで、拠点側のPCで WireShark を使ってパケットをキャプチャして見ました。
閲覧できないレンタルサーバ上(IP:xxx.xxx.xx.xxx)に、数キロバイトのHTMLを置きそれにアクセスした時の状態です。

No. Time Source Sport Destination Dport Protocol Length Info
5 13.089742 192.168.100.100 1738 xxx.xxx.xx.xxx 80 TCP 62 gamegen1 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
6 13.116909 xxx.xxx.xx.xxx 80 192.168.100.100 1738 TCP 62 http > gamegen1 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 SACK_PERM=1
7 13.116934 192.168.100.100 1738 xxx.xxx.xx.xxx 80 TCP 54 gamegen1 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
8 13.117216 192.168.100.100 1738 xxx.xxx.xx.xxx 80 TCP 609 gamegen1 > http [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=555
9 13.945675 xxx.xxx.xx.xxx 80 192.168.100.100 1712 TCP 60 http > registrar [RST, ACK] Seq=1 Ack=1 Win=65535 Len=0
10 16.269908 192.168.100.100 1738 xxx.xxx.xx.xxx 80 TCP 609 [TCP Retransmission] gamegen1 > http [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=555
11 22.285239 192.168.100.100 1738 xxx.xxx.xx.xxx 80 TCP 609 [TCP Retransmission] gamegen1 > http [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=555
12 34.316287 192.168.100.100 1738 xxx.xxx.xx.xxx 80 TCP 590 [TCP Retransmission] [TCP segment of a reassembled PDU]
13 46.456608 192.168.100.100 1738 xxx.xxx.xx.xxx 80 TCP 590 [TCP Retransmission] gamegen1 > http [ACK] Seq=1 Ack=1 Win=65535 Len=536
14 58.597028 192.168.100.100 1738 xxx.xxx.xx.xxx 80 TCP 609 [TCP Retransmission] gamegen1 > http [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=555
15 59.854326 xxx.xxx.xx.xxx 80 192.168.100.100 1738 TCP 60 http > gamegen1 [RST, ACK] Seq=2829 Ack=556 Win=65535 Len=0
16 59.854345 192.168.100.100 1738 xxx.xxx.xx.xxx 80 TCP 54 [TCP Dup ACK 14#1] gamegen1 > http [ACK] Seq=556 Ack=1 Win=65535 Len=0
17 59.880261 xxx.xxx.xx.xxx 80 192.168.100.100 1738 TCP 60 http > gamegen1 [RST] Seq=1 Win=0 Len=0


最初のTCPのコネクションは上手く行っているようですが、その後クライアントからの[TCP Retransmission]が大量に出ていますね。
TCP Retransmissionは再送要求をしているようです。時間内にサーバからパケットが来なかったので要求してると思われます。
で、最終的にサーバ側から RST フラグつまり、TCP接続を中断したというメッセージが来ています。
(TCPのフラグの意味は@IT:TCPパケットの構造を参照)


で、今度は別の閲覧可能なレンタルサーバ上(IP:xxx.xx.xx.xxx)に、同じく数キロバイトのHTMLを置きそれにアクセスした時は以下のようになりました。

No. Time Source Sport Destination Dport Protocol Length Info
1 0 192.168.100.100 1661 xxx.xx.xx.xxx 80 TCP 62 netview-aix-1 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
2 0.013593 xxx.xx.xx.xxx 80 192.168.100.100 1661 TCP 62 http > netview-aix-1 [SYN, ACK] Seq=0 Ack=1 Win=5632 Len=0 MSS=1408 SACK_PERM=1
3 0.01362 192.168.100.100 1661 xxx.xx.xx.xxx 80 TCP 54 netview-aix-1 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
4 0.013877 192.168.100.100 1661 xxx.xx.xx.xxx 80 HTTP 496 GET /hoge.html HTTP/1.1
5 0.026311 xxx.xx.xx.xxx 80 192.168.100.100 1661 TCP 60 http > netview-aix-1 [ACK] Seq=1 Ack=443 Win=6432 Len=0
6 0.02715 xxx.xx.xx.xxx 80 192.168.100.100 1661 TCP 1294 [TCP segment of a reassembled PDU]
7 0.027209 xxx.xx.xx.xxx 80 192.168.100.100 1661 TCP 1294 [TCP segment of a reassembled PDU]
8 0.027221 192.168.100.100 1661 xxx.xx.xx.xxx 80 TCP 54 netview-aix-1 > http [ACK] Seq=443 Ack=2481 Win=65103 Len=0
9 0.027235 192.168.100.100 1661 xxx.xx.xx.xxx 80 TCP 54 [TCP Dup ACK 8#1] netview-aix-1 > http [ACK] Seq=443 Ack=2481 Win=65103 Len=0
10 0.04047 xxx.xx.xx.xxx 80 192.168.100.100 1661 TCP 1294 [TCP segment of a reassembled PDU]
11 0.040535 xxx.xx.xx.xxx 80 192.168.100.100 1661 TCP 1294 [TCP segment of a reassembled PDU]
12 0.040549 xxx.xx.xx.xxx 80 192.168.100.100 1661 HTTP 652 HTTP/1.1 200 OK (text/html)
13 0.040581 192.168.100.100 1661 xxx.xx.xx.xxx 80 TCP 54 netview-aix-1 > http [ACK] Seq=443 Ack=5559 Win=64505 Len=0
14 0.04062 192.168.100.100 1661 xxx.xx.xx.xxx 80 TCP 54 [TCP Dup ACK 13#1] netview-aix-1 > http [ACK] Seq=443 Ack=5559 Win=64505 Len=0


データ受信時に[TCP segment of a reassembled PDU]が発生してますが、これはセグメントが分割されて送ってきたよというメッセージのようです。
(分割には、IPレベルで分割というかフラグメントする方法がありますが、これはそれではありません。IPレベルでの分割の場合が起こっている場合、Wiresharkでは [Fragmented IP protocol] となります。IPレベルで分割されると、ルータがパケットを分割するためスループットが非常に悪くなります。よって、大抵の通信はIPプロトコルで分割しないフラグ Don't Fragment をONにしてるようです)

この[TCP segment of a reassembled PDU]は大きなデータを送受信するときは必ず発生します。
なぜなら、通信では1回の転送で送信できるデータの最大値(MTU)が決まっていますが、アプリケーション側からみた1回のデータの送信はMTU(IPパケット全体の長さ)やMSS(IPパケット内のデータ部分の長さ)を考えないからです。
送信時に、大きいデータはお互いの通信路で適切なMTU値に分割されて、受信側で、[TCP segment of a reassembled PDU]で送られてきたパケットを結合してアプリケーション側に渡していると思われます。
このことから、この分割は普通、アプリケーションから送るデータがMSSを超えている場合に起こることがわかります。

さて、サーバとクライアントはどのように分割するサイズ、つまりMSSを知るのでしょうか。
TCPではコネクションを確立する3wayハンドシェイクで、お互いのMSSを通知し合って、値が小さい方を採用するようです。
例えば、上記の閲覧できたレンタルサーバのパケットキャプチャを見ると、以下のようになっていることがわかります。
e0091163_16362489.jpg


で、今回問題となっていたのはVPN内のMTUです。
@IT:pingでMTUサイズを調査するを参考にして、センター側と拠点間のMTUサイズを測って見ました。
最終的に以下のパケットサイズより大きい値にすると、"Packet needs to be fragmented but DF set."エラーが出てしまいました。つまり、1253以上のパケットになるとIPフラグメントするわけですね。

ping xxx.xxx.xxx.xxx -l 1252 -f


なのでこのVPNルータ間のMTUは以下の計算によると、1280Byteのようです。
1252+8(ICMPヘッダ)+20(IPヘッダ)=1280(MTU)
(1280なのはヤマハのRTXルータでVPN組んだ時のデフォルト値のようです。本当はもっと大きい値でも問題なさそうな気がするのですが。。。)

IP,TCPのヘッダはそれぞれ20Byteなので、このVPNルータ間のMSSは以下のように1240Byteになります。

1280-20(IP)-20(TCP)=1240(MSS)


さて、送られてきたデータのサイズが大きすぎる場合でDFビットON(分割不可)の場合、ルータはパケットを破棄し、ICMP Type3 Coede4を送信元ホストに送信し、ホストはそれによりパケットサイズを調整して再送という段取りをとるようです。
上記のような仕組みを、Path MTU Discovery(経路MTU検索)と言うようです。
DFビットが設定されていないと、ルータはフラグメントを行なってパケットを送信するようです。(スループットは落ちます)
e0091163_16363449.jpg


しかし、送信元に「パケットでかいから小さくしてよ」というICMPパケットがFWなどによって遮断されるとどうなるでしょうか。
WEBサーバ側はクライアントからACKパケットが帰ってこないため、RST パケットを送り、パケットが届かねぇから通信辞めると捨て台詞を吐いてるようです。
おそらく、MSのサイトを始め幾つかのサイトが見れなかったのはこれが原因だと思います。
試しに、拠点側PCのMTUを強制的に 1280 に書き換えてみたところ、閲覧出来なかったサイトも見れるようになりました。
MTUのサイズを変更するには、MSサポート:ブラック ホール ルーターの問題をトラブルシュートする方法の方法3に有るように、以下の手順を行います。(以下引用)
(ネットワークのMTUサイズを変更する - @ITにも書かれてます)

1.[スタート] ボタン、[コントロール パネル] の順にクリックします。

2.[ネットワークとインターネット接続]をクリックし、[ネットワーク接続] をクリックして開きます。

3.複数のネットワーク接続が表示された場合は、各接続をダブルクリックし、表示された [状態] インターフェイスの [サポート] タブをクリックします。[デフォルト ゲートウェイ] エントリが表示された場合、その接続がインターネット接続に使用されているネットワーク接続であると考えられます。接続名 ("ローカル エリア接続 2" など) をメモします。

4.レジストリ エディタ (Regedit.exe) を起動します。

5.HKEY_LOCAL_MACHINE ツリーの下にある次のレジストリ キーに移動します。
SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\

6.このキーの下に、数字の識別子を持ついくつかのキーがあります。各キーには Connection サブキーが設定されています。次のようなキーをすべて調べます。
アダプタの ID\Connection
Connection サブキーの [Name] 値には、ネットワーク接続フォルダに使用されるネットワーク接続名が設定されています。ステップ 3 でメモした名前と一致するものが見つかったら、そのネットワーク接続名の アダプタの ID をメモします。

7.HKEY_LOCAL_MACHINE に戻り、次のレジストリ キーに移動します。
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\アダプタの ID
アダプタの ID は、ステップ 6 でメモした番号です。このキーを強調表示すると、画面の右側にいくつかの値が表示され、その中に [DefaultGateway] および [EnableDHCP] が含まれています。

8.画面の右側を右クリックし、[新規] をクリックして、[DWORD 値] をクリックします。この値に [MTU] という名前を付けます。

9.その値をダブルクリックして編集します。[表記] を [10 進数] に変更し、Ping テストで確認した MTU の最大許容サイズを入力します。

10.レジストリ エディタを終了します。


以下のような感じです。
e0091163_16364499.jpg


このあたりの話は、Path MTU Discovery 1で詳しく図入りでまとめられています。


この現象を再現するために、センター側にxpでWEBサーバを立てて検証して見ました。
全パケット素通しにした場合は、VPNの向こう側の拠点からページの閲覧できました。(MTUは1280になっており、ルータからICMPパケットが届いているのが確認できました。)
しかし、WEBサーバ側にFW(今回はフリーのKerio使いました)を入れ、ICMP全遮断すると、拠点からページの閲覧ができない状態になりました。


さて、この場合の解決方法としてはどうすればいいのでしょうか。
ICMPパケットがブロックされるのは向こう側の問題なので、どうしようもありません。つまり、経路MTU検索は使えないというわけです。
拠点側のクライアント全部のMTUを、VPNのMTUより小さくすればOKですが、端末数が多い場合設定に手間取ります。
幸い今回VPNルータに使ったYAMAH RTX1200には、TCPコネクション開始時にMSSを調整してくれる機能があるようです。
コマンドどしては以下になります。

ip tunnel tcp mss limit auto


上記のコマンドによって以下のようになります。
e0091163_1636534.jpg


これで、なんとかまともに通信ができるようになりました。
補足ですが、強制的にMTUを指定したい場合は以下のように出来ます。
(設定する値はMSS(MTUから40バイト引いた値)なので、MTUと間違えないように注意)

ip tunnel tcp mss limit 1240


LAN3のインターフェイスでMSS指定したい場合は以下のようにします。

ip lan3 tcp mss limit 1240


今回のように、経路MTU検索が使えず、VPN内でMTUが小さくなる故に通信できなくなるという現象は、VPN組んでいると結構あるようです。
ルータによっては経路MTUより検索に対応しておらず、ICMP type3 code4パケットを返さないものもあるようで、このようなルータはブラックホールルータと呼ばれているようです。

まぁ理屈がわかれば非常に簡単な話ですが、TCP/IPの基礎を忘れかけてた3流PGは、原因突き止めるのに結構時間がかかってしまいました。


参考:
ペンギンの覚書: ネットワーク更改時のトラブル "YAMAHAのルータではVPN等のMTUがデフォルトで1280バイトになっている。対応策は、ip tunnel tcp mss limit auto"
◎IPの分割化と再構築 ここの"3.MTUとMSSとの違い。"に、ヤマハルータでのMSS自動調整"ip tunnel tcp mss limit auto"に関する記述があります。
あんじーのテクニカルブログ: MTUが小さいVPN間でファイル共有通信をすると通信できなくなる問題 "VPN通信では1280Byte、それ以外は1500Byteになっていて、ICMPパケットを破棄する設定になっていると通信できなくなる問題を引き起こすようです。"
@IT:VPNの実力を知る(後編)"(4)MTUに関する確認"あたりにMTUの話があります。
PPPoE ルータ同志で IPsec を構築するときの問題 - nabeの雑記帳
忘れっぽいエンジニアのメモ MTUとMRUとMSSについて
経路MTU探索 - Networkキーワード:ITpro
[PR]
by jehoshaphat | 2014-01-15 00:34 | ネットワーク | Trackback | Comments(3)
L2TP/IPSecでWindowsサーバとVPN張る時のルーティング情報
(WindowsServer2008)会社と自宅間で L2TP/IPSec VPNを構築してみた で、L2TP/IPSec VPNの構築したんですが、VPNに接続すると、インターネットの通信全てがVPN接続先を経由してしまいます。

また、接続元PCと同じLAN内にある別セグメント(ルータを挟んでる)に接続できなくなりました。(Pingを飛ばしても届きません)


もしやと思って、IP設定情報とPCのルーティング情報を確認してみました。
まず、VPN接続前の状態です。

C:\Documents and Settings\test>ipconfig /all

Ethernet adapter ローカル エリア接続 2:
(省略)
IP Address. . . . . . . . . . . . : 10.0.2.15
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.0.2.2
DHCP Server . . . . . . . . . . . : 10.0.2.2
DNS Servers . . . . . . . . . . . : 10.1.1.1
(省略)

C:\Documents and Settings\test>route print
===========================================================================
(省略)
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.2.2 10.0.2.15 20
10.0.2.0 255.255.255.0 10.0.2.15 10.0.2.15 20
10.0.2.15 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.0.2.15 10.0.2.15 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 10.0.2.15 10.0.2.15 20
255.255.255.255 255.255.255.255 10.0.2.15 10.0.2.15 1
Default Gateway: 10.0.2.2
===========================================================================
Persistent Routes:
None

↑はまぁ普通のセッティングですね。同じサブネットじゃないIP(0.0.0.0)はルータである 10.0.2.2 にパケットを投げるように設定されています。

次に、VPNに接続した後のネットワーク設定情報です。

C:\Documents and Settings\devlop>ipconfig /all

Ethernet adapter ローカル エリア接続 2:
(省略)
IP Address. . . . . . . . . . . . : 10.0.2.15
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.0.2.2
DHCP Server . . . . . . . . . . . : 10.0.2.2
DNS Servers . . . . . . . . . . . : 10.1.1.1
(省略)

PPP adapter test:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-53-45-00-00-00
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.0.54
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 192.168.0.54
DNS Servers . . . . . . . . . . . : 192.168.0.1

C:\Documents and Settings\devlop>route print
===========================================================================
(省略)
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.0.2.2 10.0.2.15 21
0.0.0.0 0.0.0.0 192.168.0.54 192.168.0.54 1
10.0.2.0 255.255.255.0 10.0.2.15 10.0.2.15 20
10.0.2.15 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.0.2.15 10.0.2.15 20
61.45.22.204 255.255.255.255 10.0.2.2 10.0.2.15 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.54 255.255.255.255 127.0.0.1 127.0.0.1 50
192.168.0.255 255.255.255.255 192.168.0.54 192.168.0.54 50
224.0.0.0 240.0.0.0 10.0.2.15 10.0.2.15 20
224.0.0.0 240.0.0.0 192.168.0.54 192.168.0.54 1
255.255.255.255 255.255.255.255 10.0.2.15 10.0.2.15 1
255.255.255.255 255.255.255.255 192.168.0.54 192.168.0.54 1
Default Gateway: 192.168.0.54
===========================================================================
Persistent Routes:
None

↑同じサブネットじゃないIP(0.0.0.0)が、VPN接続先(192.168.0.54)に行くようになってしまっています。デフォルトゲートウェイもVPN接続先になっていますね。
(ちなみに、Metric は同じルートが複数存在する場合、どれを優先するかを決めるために使われます。値が小さい方が優先になるので、0.0.0.0宛てのパケットは 10.0.2.2 ではなくメトリックの値の小さい 192.168.0.54 に行くようになってしまっています)
このせいで、インターネットの通信が、VPN接続先を介し、接続元PCと同じLAN内にある別セグメント(ルータを挟んでる)に接続できなくばってしまっていたわけですね。

これを解決するためには、0.0.0.0 宛てのパケットを 10.0.2.2 に行くようにすればいいわけです。
具体的には、0.0.0.0 が 192.168.0.54 に行くように定義している静的ルートを削除してしまえばいいわけですね。
下記コマンドを打つとそうできます。

route delete 0.0.0.0 mask 0.0.0.0 192.168.0.54


いちいちVPN接続するたびにコマンド打つの面倒だなと思ったらWindowsの設定でありました。
クライアントのVPNの接続のTCP/IPのプロパティの詳細設定で、「リモートネットワークでデフォルトゲートウェイを使う」のチェックを除ければいいだけでした。


下記に詳しい解説が載っていました。
TechNet:インターネットおよびイントラネットへの同時アクセスのためのスプリット トンネリング

参考先:
MSフォーラム:リモート ネットワークでデフォルト ゲートウェイを使用
@IT:>ルーティング・テーブルを操作するルーティング・テーブルを操作する
@IT:route ~ルーティングテーブルの表示/設定を行う
[PR]
by Jehoshaphat | 2011-08-16 21:17 | ネットワーク | Trackback | Comments(0)
エントリーIP-VPN

VPNと言えば、IP-VPN(MPLS)、広域イーサネット、インターネットVPN(IPsec,SSL)が一般的です。
中小企業でよく使うのは費用がかからないインターネットVPNでしょう。

しかし、3流PGも最近知ったのですが、エントリーVPNというのが最近流行ってるようです。

どんなものか調べてみたところ、ブロードバンドをアクセス回線として用い、通信事業者の閉域IP網上でVPNを提供するサービスのようです。
代表的なサービスには、NTTのフレッツ・グループ、フレッツ・VPN ワイド、Group-VPNなどがあるようです。


インターネットに出ないのでインターネットVPNよりかはセキュアです。
また、フレッツVPNワイドとかだと、地域IP網の中だけでVPNを張れるので、ある程度インターネットVPNより高速というメリットも有りますね。


中小企業にとってはよい選択肢かもしれません。

参考:
企業ネットワーク(VPN)基礎講座 | ブロードバンド時代の新潮流(エントリーVPN) | フリービットクラウド | フリービット
ASCII.jp:通信事業者のVPNサービスを学ぶ|VPN完全制覇
ASCII.jp:【3本目】エントリーVPNでWANの増強を安上がりに|コスト削減100本ノック
エントリーVPN とは - Networkキーワード:ITpro
企業向け拠点間接続の定番「フレッツVPN」を知る - 企業向け拠点間接続の定番「フレッツVPN」を知る:ITpro
フレッツ・VPNワイドの特徴と構築例
[PR]
by jehoshaphat | 2011-05-13 00:31 | ネットワーク | Trackback | Comments(0)
PacketiX のオープンソース版 UT-VPN
ソフトイーサ、VPNソフト「UT-VPN」のソースコードを配布開始 -INTERNET Watchという記事で知ったんですが、PacketiX のオープンソース版が「UT-VPN」ってのが出てたんですね。

PacketiX の前身の SoftEther 1.0 や 2.0ベータのころはフリーだったんでよく使ってたというより、これで L2VPN の勉強をさせてもらってたんですが、PacketiX になってから無償で使えなくなったんで、Hamachi や TinyVPN を使ってました。

しかし、オープンソース版が出たということで、次にL2VPNを構築するときは UT-VPN 使ってみたいですね。

なお、UT-VPN オープンソースプロジェクト Web サイト - 第 2 章ではSoftEtherからPacketiXの無償版公開停止そして、UT-VPNの公開という内部的な経緯が書いてあり結構楽しめます。
[PR]
by jehoshaphat | 2010-06-29 06:00 | 思ったこととかニュースとか。。 | Trackback | Comments(0)
(WindowsServer2008)会社と自宅間で L2TP/IPSec VPNを構築してみた (その2)
(WindowsServer2008)会社と自宅間で L2TP/IPSec VPNを構築してみたの続きです。

しばらく運用してたんですが、ある社内LANのクライアントPCがVPN兼ファイル兼DNSサーバにSMBアクセスできないという事態になりました。
ただ、ほかのクライアントPCはサーバにアクセスできてます。

調査していると、社外からVPNでVPN兼ファイル兼DNSサーバに接続している間に、社内クライアントPCのOSを起動させサーバ見ようとするとつながらないということでした。
ただし、pingでサーバ名のIPを指定するとちゃんと届きます。
また、エクスプローラから ¥¥サーバIP でもちゃんとつながります。

ということで、DNS周りが曲者だと思って "nslookup サーバ名" してみました。
すると、
 192.168.1.10 →これは実際のNICの静的IP
 192.168.1.247 →見覚えのないIP
となります。

この見覚えのないIPを使って、エクスプローラからサーバにアクセスしようとするとできません。

この見覚えのないIPですが、管理ツール「ルーティングとリモートアクセス」の「IPv4」→「全般」で表示される一覧の「内部」というインターフェイスに割り当てられていました。
(ちなみに、DHCPの設定はサーバのプロパティ「IPv4」で「動的ホスト構成プロトコルを使う」にしています。)
e0091163_22251425.jpg


どうやら、VPNでセッションがつながると、VPN(RAS)用に一つ仮想的な内部インターフェイス(PPPアダプタRASインターフェイス)を生成するようです。
そして、このPPP RASインターフェイスにも、サーバのプロパティで指定した方法でIPを割り振るようです。
さらに、割り振られたIPをご丁寧に自身のDNSサーバに動的更新してくれます。

しかし、このPPP RASインターフェイスはRAS(VPN)用なので、実在のLAN上の各クライアントからはアクセスできないようです。(ただし、そのIPは見える)

途方にくれてると、アンの開発日記 : Small Business Server 2003 上の SQL Server 2005 との通信が不安定にという記事にヒントが。。

どうやら、RRASサーバとDNS,WINSサーバが共存している時におこるようです。
MS:ルーティングとリモート アクセス サーバーで DNS または WINS を実行する場合の名前解決と接続の問題で解決方法と現象の原因が説明されてるみたいです。

上のサポートページは Windows Server 2000,2003用ですが、 2008 でも問題なく解決しました。
要は下記のレジストリを設定することで、PPP RASインターフェイスのIPアドレスを自身のDNSサーバに登録できないように出来るようです。

・下記の場所に新しい値作成
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
値の名前 : PublishAddresses
データ型 : REG_SZ
値のデータ :サーバの IP アドレス。複数の場合はスペースで区切る。

・下記の場所に新しい値作成
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
値の名前 : RegisterDnsARecords
データ型 : REG_DWORD
値のデータ : 0

これで、DNS と Netlogon サービスを再起動すればいいようです。

結果、nslookup で引いても 192.168.1.10 しか出ないようになりました。
ただ、PublishAddresses の値に IPv6 アドレスを入れようとしたら、ダメでした。
どうやら IPv4 の値しか受け付けてくれないようです。

まあ、まだ社内ではIPv6使ってるクライアントいないからかまわないんですけどね。。。
PublishAddresses に無効な値入れると、再度 PPP RAS インターフェイスのIPアドレスがDNSに登録されちゃうので要注意です。
[PR]
by jehoshaphat | 2009-07-05 22:26 | ネットワーク | Trackback | Comments(0)
(WindowsServer2008)会社と自宅間で L2TP/IPSec VPNを構築してみた
MCP70-642の勉強中で出てきたリモートアクセス用のVPNを会社~自宅間でテスト構築してみることにしました。

VPNサーバは Windows Server 2008 で、NAPTによりインターネットにアクセス可能です。
ネットワーク図は下記のような感じです。
e0091163_1243425.jpg


VPNサーバ側の設定
まずは Windows Server 2008 で役割の追加で「ネットワークポリシーとアクセスサービス」から「リモートアクセスサービス」をインストールします。
e0091163_12537.jpg


管理ツール「ルーティングとリモートアクセス」から、サーバを右クリックし「ルーティングとリモートアクセスの構成と有効化」を押下します。
e0091163_1251935.jpg


これで「ルーティングとリモートアクセスサーバーのセットアップウィザード」が開始します。

●ネットワークカード(NIC)が2枚以上ある場合
構成 は「リモートアクセス(ダイヤルアップまたはVPN)」にします。
e0091163_1255271.jpg

「リモートアクセス」では「VPN」にチェック。
VPN接続 で、ネット側のNICを選択します。その際、「静的パケットフィルタをセットアップしてセキュリティを有効にする」のチェックは外します。
(このチェックがついていると、VPN以外のパケットは通さなくなるため、LAN内からサーバへの通常アクセスもできなくなります。VPNサーバをルータ替わりで使うときに使うオプションだと思われます。このチェックはNICのプロパティの「入力フィルタ」、「出力フィルタ」に反映されます。)
IPアドレスの割り当て で「自動」にしとくとDHCPを使ってアドレスを割り当てることができ、「指定したアドレス範囲」にしとくと次の画面で払いだすIPを設定することができるようです。


●NICが1枚しかない場合
構成 は「カスタム構成」→「VPNアクセス」にします。(「リモートアクセス」にしてもNICが1枚しかないとダメだと怒られます)
e0091163_1261965.jpg

e0091163_1263268.jpg

今回はNAT内部にリモートアクセスサーバを置いているので、特別なフィルタリングはしません。
なので、NICのプロパティで全ての通信を許可するようになっていることを確認します。(最初は「静的パケットフィルタをセットアップしてセキュリティを有効にする」のチェックを入れてせってしたため、フィルタが生成され通常通信できずにかなりハマりました。)
e0091163_1265437.jpg

e0091163_127945.jpg



ルーティングとリモートアクセスサーバーの役割インストール後、「リモートアクセスのログとポリシー」を右クリックし「NPSの起動」を押下します。
e0091163_1274025.jpg


すると「ネットワークポリシーサーバー」が起動するので、ここでリモートアクセスを許可するポリシーを作成していきます。
e0091163_1275793.jpg


「ネットワーク接続の方法」には「リモートアクセスサーバー」を指定。
e0091163_1281614.jpg


条件の選択で指定したWindowsグループのアカウントに許可を与えます。
e0091163_1285911.jpg

e0091163_1291264.jpg

続けて認証の方式(今回は MS-CHAPv2 のみ許可)や制約(セッション時間や時刻など)、暗号化のポリシーを決めていきます。

今回は L2TP/IPSec を用いるので、それ以外のVPNプロトコルは無効しておきます。
管理ツール「ルーティングとリモートアクセス」の「ポート」のプロパティから各VPNの構成でセッション数や有効無効が設定できます。
e0091163_1293480.jpg


本来 IPSec では証明書を使ったコンピュータ認証をするのがセキュリティ的に望ましいのですが、今回はテスト接続ということで、キー文字列による暗号化をするように設定します。
e0091163_1295233.jpg


L2TP/IPSecでは L2TP を IPSec でカプセル化しているため、IPSecで使うポートを開放する必要があります。
開放する必要があるのは
 UDP 500 (IKE:鍵交換で必要)
 IPプロトコル番号 50 (ESPプロトコル)

です。
しかし、IPSecには NAT や NAPT を介するとその際のプロトコルやポート変換を、IPSecが改ざんとみなすため、正常に通信ができません。
これを回避するための方法が NAT-T (NATトラバーサル)というもので、IPSec のパケットをさらにUDPのパケットでカプセル化するというものです。
使う UDP は 4500 ポートです。
Windows Server 2008ではもともとNAT-Tにも対応済みなので、サーバ側OSの設定で特にすることはありません。

ということで、ルータ側でポートフォワーディングするのは下記のような設定になります。
 UDP 500 → 192.168.1.10へ
 UDP 4500 → 192.168.1.10へ

(ルータでファイアウォールの設定してる場合は、UDP 500,4500 の外向き通信も許可しないといけません。またサーバのファイアウォールでも上記ポートを開放しておきます。)

各VPNプロトコルで必要なポートはTechNet:VPN およびファイアウォールで参照できます。
NAT-Tの概要はIPsec - NAT Traversalでわかりやすく解説されています。




ここからはクライアントの設定です。
●Vistaの場合
コンパネの「ネットワークと共有センター」のタスクから「接続またはネットワークのセットアップ」を押下します。
「職場に接続します」を選択します。
e0091163_1302544.jpg


「インターネット接続(VPN)を使用ます」を選択します。
e0091163_1304151.jpg


ここで、接続するルータのダイナミックDNS名を入れます。(固定IP持ってるならそっちのほうがいい)
そして、「今は接続しない」にチェックを入れます。
e0091163_131065.jpg


VPNサーバ上でVPN接続が許可されているグループに所属するユーザアカウントを入力します。
e0091163_13121100.jpg


接続の使用準備ができました 画面では、「閉じる」を押下します。
e0091163_1314685.jpg


後は、暗号化や認証等の細かい設定が必要なので、コンパネの「ネットワーク接続」より、先ほど作成した接続のプロパティを表示します。
「ネットワーク」タブで、VPNの種類を「L2TP IPsec VPN」にします。
e0091163_132626.jpg

そして、「IPsec 設定」ボタンを押下し、「認証に事前共有キー」を使うをチェックし、サーバ側と同じキーを入力します。
e0091163_1322872.jpg


これで、設定を保存し、ダイアログを閉じます。

●XP の場合(SP2以上必須)
コンパネの「ネットワーク接続」からネットワークタスクの「新しい接続を作成する」を押下します。
「職場のネットワークへ接続する」を選択します。
e0091163_1325334.jpg

「仮想プライベートネットワークに接続」を選択します。
e0091163_133865.jpg

「接続名」は適当で、「ホスト名またIPアドレス」に接続するルータのダイナミックDNS名を入れます。(固定IP持ってるならそっちのほうがいい)

ウィザードが完了するとすぐに接続用ダイアログボックスが開くみたいなので、「プロパティ」を押下します。
このプロパティで IPSec の事前共有キーの設定をするんですが、Vistaと押下するボタンが違うので注意が必要です。
「セキュリティ」タブの「IPSec 設定」を押下します。
e0091163_1333444.jpg

そしたら、事前共有キー入れるダイアログボックスが開くのキーを入力します。
e0091163_1335423.jpg

「ネットワーク」タブで、VPNの種類を「L2TP IPsec VPN」にします。
e0091163_1341984.jpg


これで、設定を保存し、ダイアログを閉じます。



これで済めば楽なんですが、例の NAPT 絡みでこれだけではつながりません。
クライアント側で NAT-T を使えるように設定してやらないといけません。初期設定では NAT-T つかない設定らしいのです。
これがどうやらレジストリ使うしか方法がなさそうなのです。。(しかもXPとVistaじゃ場所違うし、XPはどうやらSP2以上が必要)

追加するレジストリのキーと値は下記の通りです。

・キー
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec (XPの場合)
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent(Windows Vistaの場合)
・値の名前
 AssumeUDPEncapsulationContextOnSendRule
・値の種類
 REG_DWORD
・値
 0 (NAT-T無効。デフォルト)
 1 (片一方がNATの背後)
 2 (サーバ、クライアント共にNATの背後)

このクライアントのNAT-T対応は、MS:ネットワーク アドレス変換 (NAT) の使用に関する問題や、第2回 VPNを使って安全・簡単なリモート接続 その2で詳しく解説されてます。

レジストリ設定後、クライアントPCを再起動します。

これでネットワーク接続で、作成したVPNを接続すればつながります。


自宅も会社も同じフレッツIPv6網なので、試しにその網を使ってIPv6通信してみました。
クライアント側は接続先をVPNサーバが持っている IPv6 アドレス(NTTから払いだされる 2001:xxx に変更するだけでOKです。
サーバ側も特に何もしなくてもOKでした。(ルータやFWでIPv6のUDPを許可する必要はありますが。。)
ルーティングとリモートアクセスのサーバのプロパティで「IPv6リモートアクセスサーバー」や「IPv6転送を有効にする」にチェックを入れないといけないのかと思ってましたが、なくても行けます。(チェック入れるとクライアントの PPP のアダプタに IPv6 アドレスが振られるようです。ただ、今回はVPNのトンネルさえIPv6でつなげれば、中はIPv4でもかまわないのでチェックなしにしてます)


ちなみに、TinyVPNとL2TP/IPsecとで会社~自宅間のVPNのベンチ結果です。
TinyVPN 1.3MB/s
L2TP/IPSec 2.4MB/s


追記:
VPNサーバとDNSサーバ同じ場合、問題が生じるようです。
詳しくは(WindowsServer2008)会社と自宅間で L2TP/IPSec VPNを構築してみた (その2)を参照。
[PR]
by jehoshaphat | 2009-07-02 01:36 | ネットワーク | Trackback | Comments(19)
(MCP70-642)3.1 リモートアクセスを構成する
MCP70-642 Windows Server 2008 Network Infrastructure, Configuring のメモです。
参考書は下記を使用。
MCP教科書 Windows Server 2008 Network編(試験番号:70-642) (MCP教科書)


ここから第3章のネットワークアクセスの構成に入ります。Windows Serverが提供している各種ネットワーク関連の構成方法ですが、覚えれるかどうか。。

■3.1.1 リモートアクセスとは
リモートアクセスにはダイアルアップとVPNがある。
リモートアクセスサーバをインストールには、サーバの役割「ネットワークポリシーとアクセスサービス」→「ルーティングとリモートアクセスサービス」で行う。


■3.1.2 ルーティングとリモートアクセスサービス(RRAS)の有効化
RRAS はインストール直後は無効なので、有効化しないといけない。(DHCPサービスも同じ)

インストールの手順のポイントだけ。。
・「IPアドレスの割り当て」 
 「自動」 : RRASサーバがDHCPサーバーからIPを取得し、リモートクライアントに割り当てる。
     この際、10個分のアドレスブロックをリースして、クライアントに割り当てる。
 「指定したアドレス範囲」 : RRASサーバ自体がクライアントにIPを割り振る。

・DHCPリレーエージェント
 RRASがIPアドレスの割り当てを「自動」(他のDHCP使用)にした時、DHCPリレーエージェントを入れるかどうか聞いてくる。
 リレーエージェントインストールした:DNSやWINSの値もDHCPからクライアントに割り当てられる。
 リレーエージェントインストールしない:RRASサーバ自身のTCP/IP設定がクライアントに割り当て。



■3.1.3 リモートアクセスの認証
ユーザ認証のとき、
 ・RRASサーバのローカルユーザ
 ・Active Directory のドメインユーザ
のどちらでも認証できる。

認証の方式は下記の手順で構成。
 管理ツール「ルーティングとリモートアクセスサービス」
 サーバ名のプロパティ→「セキュリティ」タブ。
 「認証プロバイダ」で「Windows認証」を選択し、「認証方式」ボタンより、認証プロトコルを選ぶ。

ユーザー名とパスワードの認証プロトコル
PAP
 ユーザ名、パスワードをクリアテキストで送信する。脆弱な認証方式なので普通使わない。
CHAP
 チャレンジレスポンス方式で認証するが、暗号化レベルが高くないのでこれも推奨されない。
MS-CHAP
 MSがCHAPを拡張したもの。 MS-CHAP v2 がよりセキュリティが確保されている。

証明書による認証プロトコル
EAP-TLS
 EAPの一種。サーバ認証、クライアント認証ともに証明書を使う。
PEAP
 サーバ、クライアント間の暗号化行い、他の認証プロトコルを補う。無線LANクライアント認証なで使用。
 PEAP-EAP-MS-CHAP v2
  サーバ認証はサーバ側の証明書を利用。ユーザ認証はユーザ名とパスワードを使う。
 PEAP-EAP-TLS
  EAP-TLSを利用するPEAP。標準では最強らしい。

※サーバ、クライアント間で複数の認証方式が使えるときは、最もセキュリティレベルが高いものが自動的に選択。
 よって必要ない認証プロトコルはサーバ側で無効化しておくとよい。


■3.1.4 リモートアクセスプロトコル
ダイアルアップは定番のPPPを使用。以下のVPN用プロトコルも、PPPをカプセル化してるのが多い。

PPTP
 制御用コネクション TCP 1723 を使用。
 暗号化の機能はない。(MSの拡張として MPPE と MS-CHAP を組み合わせて暗号化)
 Win2k以前の古いOSでもOK。特に設定もなくお手軽。

L2TP
 Win2k以降から標準搭載。
 暗号化の機能がないため、IPSecと組み合わせて使う。
 L2TP/IPSec の場合、IPSecのコンピュータ認証方式として、事前共有キーコンピュータ証明書(クライアント、サーバ共にインストール)がある。

SSTP
 Server 2008 で新しくサポート。クライアントは Vista SP1 以降。
 HTTPS(443ポート)を使う。
 ファイアウィールやNATやプロキシを越えやすい。
 サーバにサーバー証明書が必要。クライアントにもルートCAの証明書が必要。
 拠点間VPNには使えない。標準化されていない。


■3.1.5 リモートアクセスポリシー
管理ツール「ネットワークポリシーサーバー」から設定可能。(これは、管理ツール「ルーティングとリモートアクセスサービス」から「NPSの起動」で起動させないといけない)
時間帯、アクセス許可するグループ、接続最大時間、暗号化強度などが制限できる。

ポリシー作成ウィザード
・条件
・制約(アイドルタイムアウト、セッションタイムアウト(接続時間)、日付と時刻の制限などができる)
・アクセス許可(許可、拒否の指定)
・認証方法


Windowsのユーザアカウントプロパティにも「ダイヤルイン」にてリモートアクセス許可が設定できるが、リモートアクセスポリシーとどちらを優先するかは、ポリシー作成ウィザード中の「ユーザダイヤルインプロパティ(NPSポリシーよりも優先される)によってアクセスを判断する」で決定できる。

複数のポリシーを作った場合、「処理順序」の値の小さいものから順に適用される。条件に完全一致すれば、次のポリシーは評価されない。

なんかポリシーの適用順というか条件がややこしいけど、本文の図3.33を見ればなんとなくわかる。

また、「条件の指定」と「制約の構成」をうまく使い分けること。


■3.1.6 VPNサーバーへの接続
「接続またはネットワークのセットアップ」ウィザードから実行。
「接続に使用するインターネットアドレスを入力してください」で、VPNサーバのIPアドレスを入れる。(IPアドレスということは、接続先が動的IPならこの方法は難しいということ? と思ったら、URLでもOKらしい。)


■3.1.7 RADIUSサーバーの構成
RADIUSとは?
・認証(ユーザの識別)
・承認(アクセスの可否判断)
・アカウンティング(ログのこと)
の機能を有している。ダイヤルアップ接続時代のもの。

Windows Server 2008では「ネットワークポリシーサーバー」(NPS)が RADIUS サーバ機能を提供してる。
(Windows Server 2002ではインターネット認証サービスで提供されてた)

RDIUSサーバを使った認証はこんな感じ。

クライアント<------>RRAS<------------>NPS<-------->ActiveDirectoryドメコン
(リモート (RADIUSサーバ) (ActiveDirectory使う場合)
アクセスサーバ)


RADIUS認証に UDP 1812 RADIUS アカウンティングに UDP 1813 を使う。
構成として、RRAS(VPNサーバ)をDMZに配置し、NPS(RADIUSサーバー),ActiveDirectoryを内部におくという構成もあり。

RADIUSのインストール
「ネットワークポリシーとアクセスサービス」の役割から、「ネットワークポリシーサーバー」でOK。
ActiveDirectoryドメインのユーザ認証するには、ActiveDirectory にある RAS and IAS Servers セキュリティグループに NPS コンピュータアカウントを追加しないとダメ。


RADIUSサーバー(NPS)側でRADIUSクライアントを指定
管理ツール「ネットワークポリシーサーバ」を起動。
「RADIUSクライアント」を右クリで、「新規RADIUSクライアント」。
設定項目は下記。
・フレンドリ名(項目識別のタイトル)
・アドレス(クライアントのIPかDNS名)
・共有シークレット(クライアント、サーバ間でのパスワード文字列)

RADIUSクライアント(RRAS)側でRADIUSサーバーを指定
管理ツール「ルーティングとリモートアクセスサービス」を起動。
サーバープロパティの「セキュリティタブ」で、「認証プロバイダ」を「RADIUS認証」にする。
後は構成で、サーバ名や共有シークレットを追加していく。


RADIUSプロキシ
RADIUSプロキシを使うと、認証先の振り分けができる。
[PR]
by jehoshaphat | 2009-06-24 17:39 | サーバがらみ | Trackback | Comments(0)