vyattaのOpenVPN (bridge)でおはまり。。

現在の自宅構成は、OpenVPNを別サーバ(VM)で仕立てているのですが、これをvyattaでやっちまおうと思ったのがおはまり街道へ。。。
※vyatta本など買ってません。このあたりも書いてるのかな?

・DHCP(v4)は別サーバ (mac address縛り)
・vyatta上でdhcp relay
・vyatta上でDHCPv6
・bridgeは今まで未使用
・全てVM上
・無線LAN AP
・vyatta上でfirewall
・vyatta上IPv6のトンネル

こんな環境だったので、テストも調査も面倒。。。無線をWiMaxに切り替えたり、戻したり。。。1台のクライアントPCで作業をしてたのがよくなかったかも。。準備不足もあった。。。
まあ、結局のところは、一旦ペンディングで構成をもとに戻してしまったという落ち。。。
時間ができたときの再トライとバグ情報まわりを追うためにメモ程度に残しておく。

routing modeでopenvpnするにはおそらく問題は出なかったと思うのですが、OpenVPN用の新セグメントにfirewall記述したり、変更したりするのが嫌だったので、bridgeモードを使えば、自宅と同じ環境ができてうれしいという
ことで実施。

bridgeの方法など全く調べず、さらっとドキュメントを読んで取りかかった。

interface openvpn vtun0
  mode server
  server {
    subnet 192.168.xx.0/24
  }
  tls {
   ca-cert-file /config/auth/ca.crt
   cert-file /config/auth/server.crt
   dh-file /config/auth/dh1024.pem
   key-file /config/auth/server.key
  }

こんな感じで、subnetをeth2と同じセグメントで記載してやれば、勝手にvyatta君がよきにはからい、bridgeしてくれるんだろうと思ったら、
そうでなかった。。。ToT
テストしたら、192.168.xx.1とか2とか勝手に割り振りしてIPはバッティングするわで大変だった。。。

そこからbridge系を調べ始め、別ドキュメントに記載されてる。。。
eth2(IPv6およびIPv4)に既にアドレスを振っていたので、いざbridgeでbridge-groupにbindしようとしたら、commit時点で無理と。。。
一度ここで心が折れかかった。なぜなら、無線LAN経由のeth2経由という状況で作業をしていたから。。。
動かなくなってもいいと思って、とりあえず設定だけ変えて、一度にcommitを実施したら刺さることなくうまくいった。
vyattaってそこまで優秀だったけ?しばし呆然。

変更を上から順番に実施してるだけだと思っていたので、確実にそんなの無理!ってcommitで拒否されると思っていたのだが。
以前のvyattaはそんな感じでよく拒否られてた気がしたのだが。。。気のせい?

bridge br2 {
  address 192.168.xx.yy/24
  address 192.168.xx.zz/24
  address 2001:470:xxx:yyy::2/64
}
ethernet eth2 {
  bridge-group {
    bridge br2
  }
  ipv6 ...
}

openvpn vtun0 {
  device-type {
   tap
  }
  bridge-group {
   bridge br2
  }
  mode server
  server {
    subnet 192.168.xx.0/24
  }
  tls ...
}

brdigeとtapでL2にできるわけですね。レイヤ考えたらそうだよな。。。

外部接続に切り替えするも。。。firewallの変更をし忘れていて時間ロス。
昔の設定のまま別サーバにforwardしていた。。。vyatta上のpppoe側の直接portで受けるように変更してトライするもDHCPからアドレス割り振られねぇーーー。。
PCに直接IP振って経路追加したらできたので、bridgeとopenvpnが張れていることは確認できた。

これで、vyattaのOpenVPNの設定とDHCPあたりが問題だろうということでログを調査。。。openvpn-optionでWarning系を対処したが、IPが未だに振られない。。
DHCPの調査にとりかかって気づく。mac addressで縛っていた。。
PC側のtapのmac addressが登録されていない。。でもtapのmac addressって
毎回変わるみたい。。。
PCはマックなのでtapでmac address固定する方法などを調べるも簡単にはたどりつけず。。。誰か教えて!

DHCPの縛りをなしにして、テストするもダメ。。。
で、一番やりたくないパケットダンプを開始。。。vpn経由では調査できないので、外部からssh経由でdhcpサーバに入って、かつvpn起動とかしながら、悪戦苦闘。。。
経路間違って追加してsshだめになったり。。完全にお馬鹿モード。

パケットダンプをしていると、DHCPサーバまでTAPのmac addressでRequestが届いてるし、Replyも返している。ここでDHCPサーバは無罪放免。
詳しくないvyattaで調査。。。
eth2, br2, vtun0などでパケキャプを見るも、Replyがない。。。
eth2側にいるiPhone君はdhcpとれてるので、dhcp-relayの設定でもなさそうだが、念のため、interfaceをeth2,br2といろいろ変更。やはりダメ。。。

なぜDHCP replyパケットをbridgeしてくれない! そんなバグってあり?
そんなことはなさそうだけど。。。たぶんオイラの設定ミスがあるはず。

vyattaのLAN系のドキュメントのbridgeを見ていると、dhcpサーバをvyattaで記載している。。。でもDHCPサーバをvyattaで起動させなきゃならない理由がわからんので、ここは問題ではないだろう。

bridgeまわり、DHCP relayなんてあたりは興味もないので、これ以上この段階で調べる気にはならず。

ふと、OpenVPN側の設定でserver-bridgeのことを思い出す。別のOpenVPNサーバはそれで設定していたよな。。。

# set interface openvpn vtun0 ¥
   openvpn-option "--server-bridge 192.168.xx.2 255.255.255.0 ¥
      192.168.xx.xx 192.168.xx.zz"

おーー。アドレス割り振られた。。
と思ったら、なんか自宅のLANが不安定になってLAN自体の接続がダメになっちまった。。。無線APなのかもしれないが、つながらないことには調査のしようもない。。。
せっかくアドレスが割り当てられたと思ったのに、ここで断念。運が悪い一日となった。。。
結局、全ての設定を戻して撤退。

時間ができたときには、もう少し準備をして作業をしよう。端末1台では調査に限界。。

1.どうしてDHCP Replyパケットをforwardしてくれないvyatta!
2.bridgeとは関係ないでしょ?
3.openvpnの設定の問題?

1があやしいんだよね。。。以前も似た現象があった。
vyattaの問題なのか、ESX側の問題なのか。。。

 

route-upを使ってopenvpn カスタマイズ

OpenVPNをMACで使って職場のVPNにアクセスしています。OpenVPNのフロントエンドGUIはTunnelblickを使っています。
職場に接続する際に、全てのトラフィックが職場経由になってしまうのが非常に困ります。
アクセスするところはほぼ決まっているので特定のネットワークだけVPN経由になるように変更。
server側の設定変更依頼は面倒なのです。

0.0.0.0/1および128.0.0.0/1なる経路がvpnのdefault route側に向くように設定されています。
これを削除して、必要な経路のみ追加することにしました。

以下にvpn接続先のconfigファイルにて。

route xxx.xxx.yyy.0 255.255.255.0
route xxx.yyy.zzz.0 255.255.255.0

こんな感じでrouteで経路を追加します。
次に、route-upでscriptを追加します。

route-up /Users/user-name/Library/openvpn/接続先/route-change.sh

スクリプトはわかりやすいように設定ファイルのあるディレクトリに置いてます。

 #!/bin/sh
 /sbin/route delete -net 0.0.0.0/1 vpn_gateway_ip
 /sbin/route delete -net 128.0.0.0/1 vpn_gateway_ip

vpn gatewayが変わらないのでベタで記載している。。。
なんかいい方法ないかの〜。

とりあえず、これで問題がでてないのでよしとしましょう。

 

VMインスタンスのバックアップ

自宅のサーバということもあり、バックアップは簡易的にホームディレクトリのみUSBストレージに定期的にとる程度でした。
ESXi上のストレージも1本しかなかったこともありますが。。。

サーバを変えてからディスクも2本となり、容量的にも余裕ができたので、たまに手動でとることにしました。
(ディスクでRAIDがくめれば面倒なバックアップなどはとるつもりはないのですが。。。)

google先生で調べていると、無料で便利そうなスクリプトが見つかりました。
ghettoVCB.sh – Free alternative for backing up VM’s for ESX(i)
NFSのdatastoreにも対応しているそうでなんか、応用も効きそうです。
自宅のサーバは単純にlocalディスクが2本(datastoreが2つ)あるだけの簡単構成なので、簡単にインプリできそうです。

  1. 上記URLの最下部にghettoVCB.tar.gzファイルがあるのでダウンロード。
  2. ESXi上の/vmfs/volumes/datastore1にscpでコピー
  3. 展開するとghettoVCBディレクトリが作成される
  4. ディレクトリ内のghettoVCB.confを編集
  5. バックアップ対象となるvm instanceのリストファイルを作成
  6. 実行

付属のghettoVCB.confを下記のみ変更。(ディレクトリは自動で作成される)

VM_BACKUP_VOLUME=/vmfs/volumes/datastore2/BACKUPS

使い方メモ。

###############################################################
#
# ghettoVCB for ESX/ESXi 3.5, 4.x+ and 5.0
# Author: William Lam
# http://www.virtuallyghetto.com/
# Created: 11/17/2008
# Last modified: 2011_06_28 Version 1
#
###############################################################

Usage: ./ghettoVCB.sh -f [VM_BACKUP_UP_LIST] -c [VM_CONFIG_DIR] -l [LOG_FILE] -d [DEBUG_LEVEL] -g [GLOBAL_CONF] -e [VM_EXCLUSION_LIST]

OPTIONS:
   -a     Backup all VMs on host
   -f     List of VMs to backup
   -c     VM configuration directory for VM backups
   -g     Path to global ghettoVCB configuration file
   -l     File to output logging
   -d     Debug level [info|debug|dryrun] (default: info)

こんな感じで実行

./ghettoVCB.sh -f vm_backup_list.txt -g ./ghettoVCB.conf -l backup.log

これをmacからsshでリモート実行しています。

リストアについてはまだ、実験してませんが、メモのみ。

 

再来か!? iTunes 10.5 でfirefly上の曲が表示されない。。

iOS5およびiCloud対応でiTunes 10.5へバージョンしたら。。。。
iTunes 10へバージョンアップしたときと、同じような現象に。。曲が表示されないよ〜。

すでに、同様の報告があがっているが、困ったもんだ。。
また、以前のパッチをfireflyに適用すればいいのだろうか?。。。
それともAppleのiTunesの修正を待つべきか。

 

vyatta 6.3

vyatta 6.3へバージョンアップしました。バージョンアップも安定してきた感じです。

% add sysmte image http://www.vyatta.com/downloads/vc6.3/vyatta-livecd_VC6.3-2011.07.21_adm64.iso

後は質問に答えて完了。(設定を引き継ぐってだけですね)
reboot後、

% show system image

で確認して、以前のimageを削除して終了。

バージョンアップ後、DHCPv6のバグが修正されているかを確認。
vyatta::Bug 6732
うんうん。確かにfixされている。
ってな訳で、設定を変更。

    dhcpv6-server {
        shared-network-name homev6 {
            subnet 2001:470:xxx:yyy::/64 {
                address-range {
                    start 2001:470:xxx:yyy:beef::100 {
                        stop 2001:470:xxx:yyy:beef::200
                    }
                }
                domain-search pman.biz
                name-server 2001:470:aaa:bbb::ccc
            }
        }
    }

windows7で確かめたら、確かにbeef::100のアドレスが割当られてた。