ESXi::IPv6 promiscuousモード

Posted on by
Reply

最近いろいろ変更してわからなくなってきたのですが、メモ。

先日まで、VyattaでOpenVPNではまっていました。結局ESXのvswitch上でpromiscuous mode(無差別モード）を拒否で問題なかったので拒否にしていました。。。

すると。。。なんだか通常のIPv6の通信に異変が。。
MacやWindows7は2001:470:xxx:yyy::/64にいるのですが、他のIPv6セグメントには問題なく通信できるのですが、MacやWindows7から2001:470:xxx:yyy::/64のgatewayへping6が通らなくなりました。。。
パケットをみていると、33:33:ffなんちゃらをDesitinationにしてEthernetフレームがvyattaに届いてない感じ。
で、ESXiのvswitch上でこのvlan上でのみpromiscuousモードを承認したところvyattaに届くようになりました。
何これ？
いままで問題なく通信できていたと思ったのだけど。。

1. ESXi 4.1だから？
2. vyatta 6.3だから？
3. Mac OS Lionにしたから？

パケットがvyatta に届いてないので、2はない。。。
1or3が怪しいけど、昔はパケット見てなかったので何かが変わっても比較できない。。
Windows7でも同じ現象だったので、IPv6使う時はpromiscuousモードは有効にしておくほうがいいってことか？

 

Lion::IPv6 temporary address

Posted on by
Reply

OS X LionにてIPv6のtemporary addressが標準になったようです。
今までは、/etc/sysctrl.confに記載してました。

net.inet6.ip6.use_tempaddr=1

このファイルを削除してrebootしても1が設定されるようになりました。

$ sysctl -a | grep use_tempadd
net.inet6.ip6.use_tempaddr: 1
 

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

Posted on by
Reply

先日はWifiの挙動がおかしくなり断念したのですが、再挑戦です。
先日の投稿にコメント頂き、vswitchの設定を変更等してないことに気づきました。

promiscuousモードに変更したがダメでした。。。ダメというのは、やはりDHCPのreplyが飛ばなくなります。
パケットキャプチャしながらテストをし、１回だけDHCP replyが飛んだのを確認できたのですが、MACにIPが割り当てられることはありませんでした。
vyattaで飛んだことは確認できたのですが、MACに届いたかまでは不明。
その後、何回かやったのですが、二度とDHCP replyは飛ぶことはありませんでした。。

Vyatta CommunityのDHCP Relayにも怪しげな記事があります。。。（さらっとしか見てません。。。）
Bug3168と関係があるんでしょうか。。。かなり昔からみたいです。。。
またBugにヒットしたのかな。。。Orz.

だから、ドキュメントはvyatta上でDHCP定義するサンプルになっているのか？？？
まあ、何か怪しげなことがあるってことでメモ程度に。

となると、vswitchのpromiscuousモードとvyattaの関係はどうなるんだ。。。
先日、はまったときは、クライアント側でIP直接設定すれば通信できていたぞ。。
別でOpenVPNサーバを立ち上げたときは確かに、promiscuousモードに変更しないとダメだった。。
そんな疑問はさておき、とりあえず、promiscuousモードに変更して、server-bridgeの続きを実施。

先日と同様の設定を下記のような感じにしてテスト。。。

bridge br2 {
  address 192.168.xx.yy/24
  address 192.168.xx.zz/24
  address 2001:470:xxx::yy/64
  ...
}
ethernet eth2 {
  bridge-group {
    bridge br2
  }
  ...
}
openvpn vtun0 {
  bridge-group {
    bridge br2
  }
  device-type tap
  mode server
  openvpn-option "--server-bridge 192.168.xx.yy 255.255.255.0 ¥
   192.168.xx.aa 192.168.xx.bb"
  openvpn-option "--push redirect-gateway def1"
  openvpn-option ...
  server {
    subnet 192.168.xx.0/24
  }
  tls {
    ...
  }
}

結果から言うと、うまく動作しました。

vswitch上のpromiscuousモードがどうも不思議なので、一度、設定をもどし、
拒否にしてみました。うまく動作しています。。なぜ？なぜ？
このあたりも詳しくないので、とりあえず放置。無差別モードもとりあえず拒否。
いわゆるdefault設定に戻しました。
何か問題が発生したらacceptにして、このあたりをお勉強します。
しかしな〜。openvpnでserver-bridge設定をやめてDHCPを純粋に使いたいよ〜。

さて、次なる疑問は、Macにv6アドレスが割り当てられない！。。。
また今度。。。

 

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

Posted on by
2

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

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

こんな環境だったので、テストも調査も面倒。。。無線をWiMaxに切り替えたり、戻したり。。。１台のクライアント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台では調査に限界。。

１.どうしてDHCP Replyパケットをforwardしてくれないvyatta！
２.bridgeとは関係ないでしょ？
３.openvpnの設定の問題？

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