VyOSとLinuxでGREトンネルを掘る

訳あって外部VPSと自宅内ネットワークの間でトンネルを掘ることになった。

構成はこんな感じ。太字のところが今回のブログの対象。

外部: VPS( <-- GRE Tunnel --> VyOS <-- Private Network --> Server :内部

スペック等:

• VPS:
  Cloudn : vQプラン CentOS release 6.7 (Linux rice 2.6.32-431.el6.x86_64)
• VyOS: Version: VyOS 1.1.5

Configuration / 手順

せっかちな人向けにConfig/手順を晒す。

VPS：

1. ip_greモジュールを有効に:

# modprobe ip_gre



2. ネットワークConfigを作成:
/etc/sysconfig/network-scripts/ifcfg-tun0 : #Interfaceの設定


DEVICE=tun0
BOOTPROTO=none
ONBOOT=yes
TYPE=GRE
PEER_OUTER_IPADDR=203.0.113.16    #相手側のGlobalIP
PEER_INNER_IPADDR=192.168.0.250   #相手側のPrivateIP
MY_INNER_IPADDR=192.168.0.251     #自分側のPrivateIP
MTU=1400


/etc/sysconfig/network-scripts/route-tun0: #ルーティングの設定 (必要な環境のみ)


192.168.0.0/16 via 192.168.0.251



3. Interface をUP

# ifup tun0

VyOS：

1. 下記Configを投入:

interface {
    tunnel tun0 {
        address 192.168.0.250/24
        encapsulation gre
        local-ip 203.0.113.16
        mtu 1400
        remote-ip 198.51.100.8
    }
}



2. 設定を有効に(Commit):

# commit

解説：

特にコツなどはなく、上記設定がそのもの。実際私が調べてから接続まで試行錯誤もそれほどなく、すんなりと接続ができています。

注意点はルーティングとMTU。

上記構成ではルーティグは特に不要ですが、Private Network側に複数セグメントある場合は、VPS側、VyOS側、両方に書かないと適切に通信ができません。

MTUも"ping -s <size> destination" 等で適切に計測して設定を行います。
これもVPS側、Server側と両方から計測をしないとMTUブラックホール問題にぶち当たります。

接続試験時にはMTUを上回るパケットサイズでの通信をおこなう必要がありそうです。

尚、セキュリティに関しては一切考慮していません。
一般的に使う場合はIPSec等で経路の保護が必要です。

参考：

How to configure a GRE Tunnel in CentOSGRE over IPSec Tunnel Between Cisco and VyOS

Windows7のiSCSI boot

世間はすでにWindows8.1の話題ですね。
そんな中、約1年くらいずっと悩んでたWindows7のiSCSI Bootに成功したので、その話をしてみます。
今更感たっぷりですがお付き合いください。

環境

今回使用した機材は次のとおり

iSCSI Target :
 Server: DELL PowerEdge R410
 OS : Scientific Linux release 6.2  (2.6.32-220.17.1.el6.x86_64)

Client: Intel DC3217IYE  
 OS: Windows 7 Home Edition

基本的にはWindowsの iSCSI Boot の方法を参照してください。
このBlogでは苦労した点について中心に記述します。

iPXEとgPXEの違い

iPXEとgPXEの両方がやる方として出てくるので、どちらを使うか迷いました。
google先生で聞くところ、iPXEのほうが開発が活発であるとのこと。

今回の環境ではiPXEを使いましたが、違いはあまりないと思われます。

＃ちなみにgPXEではカーソルキーの↑でコマンドヒストリが出てきませんが、iPXEではコマンドヒストリが出てくるようです。

sanboot コマンドパラメータ

検索する情報現ほとんどがLUNの記述がありませんでしたが、今回の環境ではLUNを設定しないと、iSCSIDriveとして正しく認識をされませんでした。

sanboot --drive 0x80 --keep iscsi:192.168.1.10:::1:iqn.2011-10.local.home:windows7

--driveオプションと--keepオプションはおまじないです。実際にはこのコマンドの前に「set keep-san 1」を入れています。

WindowsインストーラにNICが認識されない

今回利用したクライアントはNICが新しすぎて標準のWindowsインストーラから認識されませんでした。
KVM上Windows7をインストールしたイメージをBootしようと試みたりしましたがうまくいきいかなかったので、正攻法でNICドライバをインストーラ起動時に入れることで認識し、あっさり解決しました。

通常はDiskドライバを入れて認識させる機能にNICドライバをインストールすることでiSCSIドライブが認識するというのはなかなか想像が結びつかないですが、同様な問題が発生した場合はやってみる価値がありそうです。

chainを使って試行錯誤

今回iPXEはUSBメモリに入れて実行しました。
iPXEの対話モードで毎回コマンドを入れるのが面倒だったので、iSCSI TargetにApacheをインストールし、boot.ipxeファイルを作成して、chainコマンドをつかうことで試行錯誤のスピードが上がります。

> dhcp net0
> chain http://192.168.1.10/boot.ipxe

iPXEイメージにスクリプトを埋め込む

自動起動をさせる場合にスクリプトをiPXEのイメージに入れる必要がありますが、めんどくさいなと思ってたら便利なサイトが見つかりました。

Generate iPXE images - http://rom-o-matic.eu/

USBイメージの場合は「Choose an output format:」をUSBKeyImageを選択し、「Embedded script:」に起動したいスクリプトを書きます。
今回は以下のように書きました。

#!ipxe

dhcp net0
set keep-san 1
sanboot --drive 0x80 --keep iscsi:192.168.1.10:::1:iqn.2011-10.local.home:windows7

参考：

• Windows7をディスクレスで使う

WOL (Wake On Lan) - Linuxの場合

WOL (Wake On Lan)について。Linuxでどうマジックパケットを発行するのか、わからなかったので調べてみた。
調べるとwolのパッケージをインストールしたり、wakeonlanパッケージを入れたりしているみたいだが、今使っている、Scientific Linux 6.2 では、 ether-wake というコマンドあったので、使い方もろもろ、まとめた。

使い方(root権で実行):

# ether-wake -i (NIC) (bootしたいmac address)

注意事項:
事前に相手サーバでWOLを有効にする必要あり。（BIOSレベル）
（もしくは？）WOLしたい先で以下のコマンドを事前に実行しておく。

# sudo ethtool -s (NIC) wol g

参考URL:
http://a23187.yorozuyah.com/blog/?p=261 - CentOをWOLで起こす : yorozuyah.com

Linux cache,buffersのflush(clear)する方法。

とりあえずコマンドのみ。
echo の後ろの数字の意味は下記参考URLからの抜粋だと

1: ページキャッシュ,
2: dentry,inode
3: ページキャッシュ,dentry,inode

だそうだ。
先にsyncしておくとさらにバッファが掃けるらしい。
---
# sync ; echo 3 > /proc/sys/vm/drop_caches ; hdparm -f /dev/sda
---

参考URL: http://www.math.kobe-u.ac.jp/~kodama/tips-disk-cache-flush.html

時間を少しずつずらす。

たまに、ntpdをかけ忘れたりとかで時間がかなり狂うことがありますが、それを「チョコっとずつ修正」する方法です。
adjtimexというパッケージを使います。

※CentOS (5.4)では adjtimex.(arch)というパッケージがありました。

　# yum install adjtimex

　でインストールできそうです。

使い方ですが、せっかちは人は以下のとおり。タブンrootユーザじゃないとダメです。

# adjtimex --tick (値)

現在の値を確認するときは次のとおり。

# adjtimex --print

値はデフォルト値が10000ですが、この値から大きくすると早く進んで、小さくすると遅れます。

早くしたい場合　：　10001以上
通常　　　　　　　 ：　10000
遅くしたい場合　：　9999以下

考え方は前の記事のURLを参照となりますが、Linuxの場合0.1μ秒毎に1回割り込みが発生し、この割り込みが10000回で1秒とカウントします。
ですので、上の値を+10とすれば、1ms/1secすすみ、+100とすれば10ms/1sec進ませることができます。
ただしこの割り込みの精度はあまりよくなさそうで、ロードアベレージが高かったりすると途端に狂いだします。
なので、調整するコマンドがあるんですかねぇ。

ハードウェアクロックはJST?UTC?

日本語のBlogなのでローカルタイムの基準はJSTでもいいでしょう(笑)
ハードウェアクロックについてLocalTimeがいいのかUTCがいいのかわからなかったのですが、LinuxのDocumentに書いてありました。

#電化製品のマニュアルは後で読む派なので。

http://www.linux.or.jp/JF/JFdocs/Clock/time-tracking.html

大まかにまとめると
・RTCにローカルタイムを求めるOSとデュアルブートしていればローカルタイム
・Linuxは基本はUTCにしたほうがいい。
・RTCにローカルタイム(上記URLだとDST:サマータイム)を設定すると1時間ずれる。

ふむふむ、OSがローカルタイムのRTCを見る必要があれば、RTCにする、Linuxしか乗っからない場合は、UTCにする。。。というようにとれますね。

上のURLのドキュメントを見ると、UTCが推奨だそうですが、実際のところハードウェアログを見るときに簡略化するために、ローカルタイムを設定していたりしていますかねぇ。。。

どちらにあわせる・・・というのはいろいろポリシーが分かれますが、やはり基本はUTCにあわせたほうがいい気がします。