ConoHaとSoftEther VPNで遊んでみる(設定編-1)
ConoHa VPS上へインストールしたSoftEther VPN Serverを設定する。
設定は基本Windows端末上のSoftEther VPN Server Manager for WindowsからGUIで実施する。
VPNサーバへの接続はCisco1812JからのL2TPoverIPsecを想定。
参考にしたサイト
Cisco ルータからの L2TPv3 を用いた VPN 接続方法 - SoftEther VPN プロジェクト
手順
- SoftEther VPN Server Manager for Windowsのダウンロード
- VPS上のiptablesでポート開放
- SoftEther VPN Server Manager for WindowsによるGUI設定
- 簡易セットアップでの初期設定
- 不要サービスの停止
- tapデバイスの作成
- VPS上のtapデバイス(仮想IF)へのIPアドレス設定
- VPS上のiptablesでVPN経由の通信許可設定追加
- VPS上でStaticルートの設定
ConoHaとSoftEther VPNで遊んでみる(インストール編)
ConoHa VPS上へSoftEther VPN Serverをインストール。
VPSの初期OS(CentOS 6.4 64-bit)だと依存関係もなくコマンド一撃でインストールできた。
最新版のVer 4.06, Build 9437, beta、外部認証とかLog保存設定とか機能が増えている感じ。
参考にしたサイト(そのまま指示通りにしただけ...)
7.3 Linux へのインストールと初期設定 - SoftEther VPN プロジェクト
手順
- SoftEther VPN ServerをDownload
- VPS上へUp Load
- 展開
- make
- ディレクトリーを移動
- パーミッション変更
- 動作チェック
- スタートアップスクリプトへの登録
- 起動および停止
ConoHaとSoftEther VPNで遊んでみる（形態3型）
形態3型
ConoHaから各拠点向け(192.168.1.0/24と192.168.3.0/24宛て)のStaticルート設定をなくしたい！
ConoHaのローカルネットワーク(192.168.0.0/24)への直アクセスが不可。NATしたらアクセスでけるけど接続元アドレスが隠蔽されてしまう。
上記の問題を解決すべく以下実施
- ルーティングをEIGRPからOSPFへ変更
- ConoHa VPS上のサーバへQuaggaをインストールしてOSPFによるルーティング化
- ローカルネットワーク上のVPSへもSoftEther VPN ClientをインストールしてVPN化
- 良い点
- ほぼStaticルートの設定がなくなった。(一部都合で残っているが...)
- ConoHaのローカルネットワーク上のサーバ(192.168.2.11)へアクセス時に接続元アドレスが確認できる。
- 悪い点
- ConoHaのローカルネットワーク上のサーバ(192.168.2.11)へアクセス時に暗号化→復号化→暗号化→復号化と2回処理が発生。
インストール手順とかスループットとかは、おいおい書いていこうと思う。
ConoHaとSoftEther VPNで遊んでみる（形態2型）
形態2型
実家に帰る予定ができたので、ついでにWANルータへ物理作業を実施。
こんな感じでFa1〜Fa9をUTPケーブルで直結(アドレスが違うけど...)
WANルータ間でEIGRPによるルーティングを設定
玄箱の利用および仮想レイヤ 3 スイッチ機能は廃止
- 良い点
- ちょっとだけStaticルートの設定が減った。
- 悪い点
- 相変わらずStaticルートの設定が必要(ConoHaから各拠点向け)→192.168.1.0/24と192.168.3.0/24宛て
- ConoHaのローカルネットワーク(192.168.0.0/24)への直アクセスが不可。NATしたらアクセスでけるけど。
ConoHaとSoftEther VPNで遊んでみる（形態1型）
radikoで阪神戦を聴きたーい。ConoHaの楽しい使い道を探していたとかetc
VPSをConoHaにしたのは、「清楚かわいい」にダマされた。でもかわいいですね。
VPNだって、まだまだ楽しくなるはず。。。
環境
形態1型
実家のWANルータに物理的な作業ができなかったため、玄箱にSoftEther VPN Bridgeをインストール
ConoHaにインストールしたSoftEther VPN Server上で仮想レイヤ 3 スイッチ機能を利用
- 良い点
- 悪い点
Linux オペレーティングシステム内部での制限事項により、VPN 側 (仮想 HUB 側) からローカルブリッジしている LAN カードに割り当てられる IP アドレスに対して通信を行うことはできません。この制限は SoftEther VPN が原因ではなく、Linux の内部構造に原因があります。*1
Cisco ルータへNTP monlistをためしてみた
昨年末からNTPのDDoSが問題になっている。
NTPのモニタリング機能のmonlistでのパケット増幅によるDDoS攻撃とのこと。
Cisco機器だと時刻同期にNTPを設定すると、勝手にNTP サーバになる機種がほとんど。（一部APとかルータを除く）
インターネット接続用にCisco1812Jを家では利用している。NTPサーバの設定には外部のNTPサーバ(福岡大学)を利用させて頂いている。
恥ずかしながらNTPに関してはフィルター設定は入れていない状態で運用中。
ご指摘がありましたので、NTPサーバはプロバイダー提供のサーバへ変更し
UDP/123 に関してACLを設定済み。(2014/06/30追記)
外部（グローバル）サーバからntpdcコマンドにて試験実施
$ntpdc -c monlist xxx.xxx.xxx.xxx
xxx.xxx.xxx.xxx: timed out, nothing receivedRequest timed out
その時にNTPに関してdebug実施
Feb 13 22:11:24: NTP: rcv packet from xxx.xxx.xxx.xxx to xxx.xxx.xxx.xxx on Dialer0:
Feb 13 22:11:24: leap 0, mode 7, version 2, stratum 0, ppoll 8
Feb 13 22:11:24: rtdel 0000 (0.000), rtdsp 0000 (0.000), refid 00000000 (0.0.0.0)
Feb 13 22:11:24: ref 00000000.00000000 (09:00:00.000 JST Mon Jan 1 1900)
Feb 13 22:11:24: org 00000000.00000000 (09:00:00.000 JST Mon Jan 1 1900)
Feb 13 22:11:24: rec 00000000.00000000 (09:00:00.000 JST Mon Jan 1 1900)
Feb 13 22:11:24: xmt 00000000.00000000 (09:00:00.000 JST Mon Jan 1 1900)
Feb 13 22:11:24: inp D6A742FC.E00EA47F (22:11:24.875 JST Thu Feb 13 2014)
Feb 13 22:11:24: NTP: Received NTP private mode packet. 7
Feb 13 22:11:24: NTP: Receive: dropping message: Received NTP private mode packet. 7
いちおう、IOSが12.4(15)T17のCisco1812JはNTP monlistには返答していない様子。
調べてみると
Cisco IOS Release 12.2(33)SXH7 よりも後のリリースでは、NTP モード 7 パケットは処理されません。
と記載あり。じゃ、それ以前のIOSは？？？（ちょっと怖い）
でも早く、フィルター設定を入れなくては。
Sorce Distが同じポート番号を使うプロトコルには困ったものだ…
めんどくさいがWindows端末のために、NTPプロトコルのみCBAC ( Context-Based Access Control )の設定を入れてます。
Cisco2600で試してみたのですが古いIOSも応答してない様子です。
(2014/06/30追記)
Net::SNMPをつかってCisco機器からCDP情報を収集(4)
1.3.6.1.4.1.9.9.23.1.2.1.1.3.1.2 1 1.3.6.1.4.1.9.9.23.1.2.1.1.4.1.2 0xc0a801fc 1.3.6.1.4.1.9.9.23.1.2.1.1.9.1.2 ) 1.3.6.1.4.1.9.9.23.1.2.1.1.12.1.2 3
今回は
cdpCacheCapabilities OCTET STRING
cdpCacheDuplex INTEGER,
についてCISCO-CDP-MIBファイルから確認していく。
- cdpCacheDuplex
cdpCacheDuplex OBJECT-TYPE SYNTAX INTEGER { unknown(1), halfduplex(2), fullduplex(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The remote device's interface's duplex mode, as reported in the most recent CDP message. The value unknown(1) indicates no duplex mode field (TLV) was reported in the most recent CDP message." ::= { cdpCacheEntry 12 }
1.3.6.1.4.1.9.9.23.1.2.1.1.12.1.2 3 ⇒ (3)なのでfullduplex
と読み解ける。
- cdpCacheCapabilities
cdpCacheCapabilities OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..4)) MAX-ACCESS read-only STATUS current DESCRIPTION "The Device's Functional Capabilities as reported in the most recent CDP message. For latest set of specific values, see the latest version of the CDP specification. The zero-length string indicates no Capabilities field (TLV) was reported in the most recent CDP message." REFERENCE "Cisco Discovery Protocol Specification, 10/19/94." ::= { cdpCacheEntry 9 }
問題なのはcdpCacheCapabilities
これについてはOCTET STRING(SIZE (0..4)) の内容について記載がない。
正直これ以上MIBファイルからは確認できない。しかし、実際のCDPパケットの内部にヒントがあった。
「Wireshark」にてCDPパケットをキャプチャwikipedia:Wireshark
Capabilities
Type: Capabilities (0x0004)
Length: 8
Capabilities: 0x00000029
.... .... .... .... .... .... .... ...1 = Is a Router
.... .... .... .... .... .... .... ..0. = Not a Transparent Bridge
.... .... .... .... .... .... .... .0.. = Not a Source Route Bridge
.... .... .... .... .... .... .... 1... = Is a Switch
.... .... .... .... .... .... ...0 .... = Not a Host
.... .... .... .... .... .... ..1. .... = Is IGMP capable
.... .... .... .... .... .... .0.. .... = Not a Repeater
32ビット(4octets)中どのビットが何を意味しているかがわかる
1.3.6.1.4.1.9.9.23.1.2.1.1.9.1.2 ) " )"=0x00000029
" )"が0x00000029なのはNet::SNMPモジュールが無理やり変換してしまっているため
Router
Switch
IGMP capable
上記の3つのビットが立っており R S I の表記になる。
ちなみに
1.3.6.1.4.1.9.9.23.1.2.1.1.9.3.1 0x00000001
これはRouterのビットしか立ってないので
R のみの表記となる。
