DigiLoog

続きを読む »

Webカメラは様々なメーカーから出ているが、
ATOM Camの良いところは値段が安い割に多機能で様々な使い方が出来る点。
今回購入したのはSwingなのでカメラを上下左右に動かす事が出来るのだが、
同等の物を海外製品で探すと怪しいWebカメラしか対応している物が無かったりする。

ATOM CamシリーズもWYZE CAMのOEMではあるが、
出所がはっきりしているので有象無象の怪しい中国製よりは安心できるのもメリットの一つ。

開封直後の状態はこんな感じになっている。
外箱も驚くほど小さくWebカメラ本体がみっちりと詰まっていた。

電源はUSBポートから取る形式で専用ケーブルを利用する事となる。
カメラ本体は電源が詰まった部分とカメラを格納した部分の2つをダブルヒンジで接続している。

初代・二代目のATOM Camを縦に連結したような形で縦設置する事となる。
電源はmicro USB形式だが、防水と電圧確保の為に同梱ケーブルを使うように注意書きがあった。
筆者も同梱USBケーブルを接続しているが、流石にカッチリ嵌る様に作られていた。

ATOM Camなので録画用SDカードを入れる事が出来るが、
この部分もゴムパッキンで覆われており防水対策がちゃんとしていた。

左のRESETボタンは初期セットアップしたりカメラを初期化する時に使う物だが、
コレが結構深い所まで押す必要があり爪を立てないと反応しなかったりする。
また、セットアップ時の音声ガイド音量が大きく夜中だと近所迷惑になりそうだった。
この辺りはATOM Cam初代でも同様だったので直して欲しかったが、直っていなかった (´・ω・｀)

動画撮影時のネットワーク帯域は100～200KB程度で他のWebカメラと大差無かった。
モバイルルータでは流石に不安だが、普通の固定回線を使っているなら問題なく使える帯域だった。
野外利用するなら無線接続は必須になると思うが、
ネットワーク帯域や解像度のバランスが上手く、どの利用シーンでも処理できるようになっている。

心残りなのはAPI操作に対応していない所。
この値段でAPIに対応するのは無理だと思うが、
ラズパイと組み合わせてAPIを叩けると一気に利用用途が広がるので実装して欲しいと感じた。

実稼働させて一週間も使っていないので実利用を元にしたレビューは出来ないが、
Webカメラとしてのポテンシャルは高い様に感じる。
暫くの間は起動させっぱなしにさせつつ実際の利用シーンを模索しようと思う。

« 続きを隠す

続きを読む »

最初に結論を書くと、Proxmoxの機能として実装されているファイアウォールのうち、
ホスト・ゲストのファイアウォールが無効化していても、
ゲストの仮想NICに適用するファイアウォールが全許可でも適用している状態では、
3ウェイハンドシェイクが出来ずTCP通信が遮断されてしまう事象だった。

………

通常状態は次の様に経路制御しており、
HSRPでActiveになるルータは対にさせつつMEDを使って実トラフィックを迂回させていた。
つまり、ルータ間の渡りを使う事で迂回させるオーソドックスな構成となる。

その状態でHSRPのActiveでeBGPピアをダウンさせたら、Server-AからServer-BへのSSHは出来た。
HSPRのActive・Standbyが切り替わっていないが、
eBGPピアダウンでは切り替わらない様にしているのでNW設計上は正常動作となる。

この状態でServer-BからServer-Aに対してSSHしようとした所、SSHの応答が返ってこなかった。
pingは問題なく返って来るのでARPは問題なく、NW経路の観点では問題無い事が確定。
そうなると、L4以上の何処かが問題になるのでファイアウォールあたりが怪しいと踏んだ。

そもそも、ファイアウォールは全許可に設定していたので一旦置いときつつ、
切り分けの為にHSRPのActive・Standbyを切り替えてみたが通信が出来なかった。
仮想・物理を経由しているのでMTUに問題があるかと思い設定変更も試したのだが解決出来ず、
Proxmox上で何か起きていると判断してパケットキャプチャしてみた。

その時、Proxmoxで不思議な事が起きた―――

Proxmoxをインストールしている物理サーバのNICまでは通信が正常に来ているのだが、
ゲストOSの仮想NICにパケットが転送されておらず、物理NICで通信が破棄されていた。
しかし、上の方に書いた通りゲストOS宛のProxmoxファイアウォールは全部許可しており、
通信破棄されている理由がわからなかった。

………

という事で、Proxmoxでtcpdumpやstraceして挙動を確認しつつ、
コミュニティーに情報があるか確認したらProxmoxのNIC挙動について書かれていた。

ProxmoxでゲストOSを起動すると “tap100i0” の様にIDに紐づく仮想NICがホストOSで作成され、
物理NICのパケットをゲストOSの仮想NICにブリッジして通信させる挙動らしい。
という事は、ゲストOSや仮想NICのファイアウォールが紐づくならこの部分なのと、
物理NICから仮想NICにパケット転送出来ていない所が鍵になると考えた。

• Proxmox Support Forum > TAP interface created automatically

NWの話となるが今回は意図的に非対称ルーティングになっている都合上、
3ウェイハンドシェイクでは “SYN+ACK” がいきなりProxmoxに投げつけられる形となる。

Cisco ASAなどファイアウォールアプライアンスでは、
SYNフラッド攻撃やSYN/ACKリフレクション攻撃の対策として、
通信許可しているのに “SYN+ACK” だけのパケットに応答しないモードがあるのだが、
まさにコレと同様の事象が今回のProxmoxでも起きているのでは無いかと予想した。

という事で、ゲストOSの設定を全て確認した所、
ゲストOS本体のファイアウォールは無効化されているが、
ゲストOSの仮想NICでファイアウォールが全許可状態だが有効である事を確認。
コレを試しに無効化してみた所、Proxmox経由の非対称ルーティングも出来る様になった。

非対称ルーティングをしている時にSSHが繋がらない事例は聞いたことがあり、
事例としてもアプリケーション問題が大半だった。
そんな中、ルータで通信を遮断している今回の状態は想定外だった…

そもそも、インターネットの世界だと非対称ルーティングは日常茶飯事な事もあり、
同様の環境でSSHしても繋がっていたので、
『L4が問題になっている事は無いだろう』と、先入観から後回しにしたので時間がかかった。

今回はProxmoxのファイアウォールを全許可で有効化していたのが原因だが、
同様の事は他の仮想サーバやAWSの様なIaaSでも起こりうると思う。
非対称ルーティングはNW設計次第で起こりうるからこそ、
通信出来ない時は低レイヤーを切り分けつつ、セオリー通りL4は見るべきと再認識した。

« 続きを隠す