Archive for the ‘Network’ Category

    はてなブックマーク - RTX810とWindows7の標準VPNクライアントでL2TP/IPSecを利用する
    このエントリーをはてなブックマークに追加

    Fusic 平田です。
    ルータ買い換えの夏、というわけではないんですが。
    YAMAHA RTX810でL2TP/IPSecを試してみました、という話です。
    一旦社内ネットワークでオレオレVPNを組んで、接続できるかどうかを実験。

    YAMAHAの公式に
    > ※Microsoft社製Windows OSのL2TP/IPsec接続はサポートしません。
    と書かれててどうしたもんかと思ったのですが、なんとか接続できました。

    参考にしたのは以下。

    www.rtpro.yamaha.co.jp/RT/docs/l2tp_ipsec/index.html#setting3

    shirangana.info/115/?page_id=174

    support.microsoft.com/kb/926179/ja

    とりあえずルータ側の設定晒し。
    上位ルータ: 172.16.0.1
    WAN側ルータIPアドレス: 172.16.0.101/16
    LAN側ルータIPアドレス: 192.168.100.1

    # RTX810 Rev.11.01.06 (Tue Apr 10 07:09:02 2012)
    # MAC Address : 00:a0:de:80:a0:0e, 00:a0:de:80:a0:0f
    # Memory 128Mbytes, 2LAN
    # main:  RTX810 ver=00 serial=S3K013283 MAC-Address=00:a0:de:80:a0:0e MAC-Addre
    ss=00:a0:de:80:a0:0f
    # Reporting Date: Aug 9 11:46:20 2012
    administrator password *
    login user sshuser *
    ip route default gateway 172.16.0.1
    ip keepalive 1 icmp-echo 10 5 192.168.100.1
    ip lan1 address 192.168.100.1/24
    ip lan1 proxyarp on
    ip lan2 address 172.16.0.101/16
    ip lan2 secure filter out 101099
    ip lan2 nat descriptor 200
    provider lan1 name LAN:
    provider lan2 name PRV/0/1/0/0/0/0:
    pp select anonymous
     pp bind tunnel1
     pp auth request mschap-v2
     pp auth username l2tp_user *
     ppp ipcp ipaddress on
     ppp ipcp msext on
     ip pp remote address pool dhcp
     ip pp mtu 1258
     pp enable anonymous
    tunnel select 1
     tunnel encapsulation l2tp
     ipsec tunnel 1
      ipsec sa policy 1 1 esp aes-cbc sha-hmac
      ipsec ike keepalive log 1 off
      ipsec ike keepalive use 1 off
      ipsec ike nat-traversal 1 on
      ipsec ike pre-shared-key 1 *
      ipsec ike remote address 1 any
     l2tp tunnel auth off
     l2tp tunnel disconnect time off
     l2tp keepalive use on
     ip tunnel tcp mss limit auto
     tunnel enable 1
    nat descriptor type 200 masquerade
    nat descriptor address outer 200 primary
    nat descriptor masquerade static 200 1 192.168.100.1 udp 1701
    nat descriptor masquerade static 200 2 192.168.100.1 udp 500
    nat descriptor masquerade static 200 3 192.168.100.1 esp
    nat descriptor masquerade static 200 4 192.168.100.1 udp 4500
    ipsec auto refresh on
    ipsec transport 1 1 udp 1701
    dhcp service server
    dhcp server rfc2131 compliant except remain-silent
    dhcp scope 1 192.168.100.2-192.168.100.191/24
    dns server 172.16.0.1
    dns private address spoof on
    l2tp service on
    httpd host lan1
    sshd service on
    sshd host key generate *

    ルータ側設定の要点は以下の通り。

    # RTX810 Rev.11.01.06 (Tue Apr 10 07:09:02 2012)

    ファーム上げないとNATトラバーサル使えないので。

    ipsec ike nat-traversal 1 on

    NATトラバーサルを有効に。
    # GUIの管理画面では設定できないので、コマンドで。

    nat descriptor masquerade static 200 4 192.168.100.1 udp 4500

    NATトラバーサルではESPの代わりにUDPの4500番を使用するので、IKEで使われるUDPの500番と同時にUDPの4500番を静的IPマスカレードで設定。

    クライアント(Win7)側も、NATトラバーサルを有効に。

    support.microsoft.com/kb/926179/ja

    を参考にして、「AssumeUDPEncapsulationContextOnSendRule」を2としたレジストリを追加して再起動。

    あとは普通にWin7のVPN接続設定でL2TP/IPSecを選んだらうまくいきました。



    ついでにiPhoneも。



    まだこれからいろいろ手を加えていく予定ですが、とりあえず何かの参考になれば幸いです。まる。

      はてなブックマーク - iptablesを利用してVPN接続を共有(?)してみる話
      このエントリーをはてなブックマークに追加

      Fusic 平田です。

      前提

      VPN越しでサーバに接続することがままあるのですが。
      接続先VPNルータの設定の問題で、Windows7での接続がどうにも失敗するという事態に。
      VPNルータの設定を変えたいものの、設置先が遠方なのですぐには対応できず。

      で、Linux(確認したのはUbuntu)だったら接続できるようなので、このLinuxのVPN接続を間借り共有すればいいんじゃないかなという話に。
      図で書くと↓のような想定ビフォーアフター。



      というわけで、iptablesを使ってさくっとやってみます。

      ネットワーク情報

      Linux(VPN接続済)
      eth0: 192.168.11.100
      ppp0: 192.168.100.200
      ※LinuxでのVPN接続方法については、今回は割愛。
      サーバ
      eth0: 192.168.100.100
      クライアント(Windows7)
      eth0: 192.168.11.101

      いろいろ設定

      まずはLinuxの設定をいくつか。

      $ cat /etc/sysctl.conf | grep net\.ipv4\.ip_forward
      net.ipv4.ip_forward=1

      net.ipv4.ip_forward=1にすることで、IPv4転送が有効になります。
      書き換えた後は

      $ sudo sysctl -p
      net.ipv4.ip_forward = 1

      として設定を反映。

      あとはiptablesでIPマスカレードを設定。

      $ sudo iptables -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE

      これでLinux側は準備完了。

      Windows7側にはルーティングを追加。

      C:\Windows\System32>route add 192.168.100.0 mask 255.255.255.0 192.168.11.100
      OK!

      ※ルーティングを永続的にしたい場合は、-pを加えると再起動後も有効になります。

      で、Windows7側からpingで確認してみると

      C:\Windows\System32>ping 192.168.100.100
       
      192.168.100.100 に ping を送信しています 32 バイトのデータ:
      192.168.100.100 からの応答: バイト数 =32 時間 =34ms TTL=62
      192.168.100.100 からの応答: バイト数 =32 時間 =34ms TTL=62
      192.168.100.100 からの応答: バイト数 =32 時間 =36ms TTL=62
      192.168.100.100 からの応答: バイト数 =32 時間 =38ms TTL=62
       
      192.168.100.100 の ping 統計:
          パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
      ラウンド トリップの概算時間 (ミリ秒):
          最小 = 34ms、最大 = 38ms、平均 = 35ms

      無事見えるようになりました。:-)

      内容としては単なるIPマスカレードの話なのですが、こんな使い方もあるよってことで。

        はてなブックマーク - サービスは止まっていないのにネットワークエラーが・・・なぜ?
        このエントリーをはてなブックマークに追加

        奥さまの名前は CentOS、旦那さまの名前はしんちゃん。
        ごく普通のサーバに、ごく普通にインストールし、ごく普通の納品をしました。
        でも、ただひとつ違っていたのは、ifconfig を叩くと………エラーが発生していたのです!

        *・゜゚・*:.。..。.:*・゜゚・*:.。. (n‘∀‘)η

        はじめての人もそうでない人もはじめまして。 河野と申します。

        Advent Calendar はスタートの火蓋が切られたばかりにも関わらず、私だけが二週目に突入しました。
        マッハ号もかくやといったところです。

        さて、本日は「サービスは止まっていないのにネットワークエラーが増え続ける」という奇妙な問題を解決した際のお話を皆様にしたいと思います。

        尚、サーバはCentOS となります。

        エラーの増加

        サンプルに偏りがあるのを承知で言いますが「サービスは止まっていないのにネットワークエラーが増え続ける」。
        そういった事象はあまり無いのではないかと思われます。
        ネットワークにエラーがある場合は、サービスどころかネットワーク自体が疎通出来なくなる事が多いのではないでしょうか?

        ところが今回のエラーは以下のような特徴を持っていました。

        • リモートからサーバへのアクセスが可能
        • ローカルから外部へのアクセスが可能
        • パケットのエラーが増え続ける

        エラー発生当初、サービスに支障が出ていないので、今後の経過を見るという判断になりました。

        このサーバには Munin というサーバ動作ログを視覚的に閲覧することの出来るソフトウェアをインストールしていたのですが、見るたびにサーバのエラーは増えていきました。

        # ifconfig
        eth0      Link encap:Ethernet  HWaddr 00:03:0D:34:8F:AD
                  inet addr:10.1.0.1  Bcast:10.255.255.255  Mask:255.0.0.0
                  inet6 addr: fe80::203:dff:fe34:8fad/64 Scope:Link
                  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                  RX packets:5505120 errors:869 dropped:0 overruns:0 frame:869
                  TX packets:563000 errors:0 dropped:0 overruns:0 carrier:0
                  collisions:30 txqueuelen:1000
                  RX bytes:900322789 (858.6 MiB)  TX bytes:102707436 (97.9 MiB)
                  Interrupt:209 Base address:0xd800

        ※ ↑は執筆時に仮想サーバにてエラーを発生させてみたものです

        問題の調査

        色々と調査した結果、Auto-Negotiation 機能に問題があるのではないかという結論に至りました。

        ethtool コマンドで eth0 を調査した結果 half-duplex(半二重)になっていたからです。

        # ethtool eth0
        Settings for eth0:
                Supported ports: [ TP MII ]
                Supported link modes:   10baseT/Half 10baseT/Full
                                        100baseT/Half 100baseT/Full
                Supports auto-negotiation: Yes
                Advertised link modes:  10baseT/Half 10baseT/Full
                                        100baseT/Half 100baseT/Full
                Advertised auto-negotiation: No
                Speed: 100Mb/s
                Duplex: Half
                Port: MII
                PHYAD: 1
                Transceiver: internal
                Auto-negotiation: off
                Supports Wake-on: pg
                Wake-on: d
                Current message level: 0x000000c5 (197)
                Link detected: yes

        このサーバの eth1 はバックアップ装置と直繋ぎしておりこちらの通信モードは full-duplex(全二重)に設定されています。

        この結果から eth0 と繋がれているスイッチが full-duplex 固定に設定されており Auto-Negotiation 設定時に通信モードを返さなかった為、デフォルトの半2重設定を行ったと考えられました。

        問題の解決

        そうと分かればサーバ側の eth0 の設定を full-duplex 固定にしてしまえばいいだけの話です。

        ローカル環境で確認後、本番で行なった変更は ifcfg-eth0 の最後に以下の一文を加えるだけ。

        # vim /etc/sysconfig/network-scripts/ifcfg-eth0
        ETHTOOL_OPTS="autoneg off speed 100 duplex full"

        但し、ネットワークリスタートする必要があります。

        ちなみに eth-tool コマンドでも設定可能です。

        ● eth0 の autonegotiation を off

        # ethtool -s eth0 autoneg off

        ● eth0 の duplex を full にする

        # ethtool -s eth0 duplex full

        こちらは再起動を行なうと設定が消えますので、再起動後も設定を反映する場合は上記のようにデバイスの設定ファイルに設定を記述してください。

        最後に

        今回一番困ったのは「利用者からは問題がないように見える」点です。
        無視するわけにもいかないが、無視できる範囲のエラーなので、システムを停止することが難しいサーバや、社内システムだと止めるほどでも無いかもしれません。

        今回のエラーはサーバを設置してすぐだったため、トラフィックが増えてエラーが無視できなくなってくる前に対応する事にしました。

        どういったエラーでも対応すべきか、無視できるかは熟慮・検討する必要があるかと思いますが、今回のエラーは判断に迷う内容でした。

        結論からするとエラーは対応すべきものと私は思います。 が、技術的視点以外からの判断が加わってくると対応しないという結論もあるかもしれませんね。