はてなブックマーク

はじめに Kubernetes を触り始めて困惑したのは、クラスタの外からどうやってアクセスするのか？ということでした。 GKE なら提供されているロードバランサを使えば良いですが、GKE に頼れない環境でも良い方法が欲しいものです。 ClusterIP はクラスタ内部からアクセスする際に使用するもので、外部からアクセスすることは意図されていませんが、 これをそのまま利用できればとても楽ができそうです。 ClusterIP へのアクセスは複数の Pod に対して振り分けられるので、Ingress や Service Load Balancer が無くてもクラスタの外に対してロードバランサを提供することができます。 調べたところ Project Calico と kube-proxy を利用するとクラスタの外から ClusterIP にアクセスできたので、やり方をまとめておきます。 テスト環

↓ のニュースを見て面白そうだったので遊んでみました。 GoogleがロードバランサーSeesawをオープンソース化（Go言語で書かれている） まだドキュメントが心もとないので、ソースを斜め読みしながら設定しました。 https://github.com/google/seesaw 試した環境は CentOS 7.2 on vSphere ESXi です。せっかくなのでメモとして残しておきます。 構成 既存のテスト環境に入れているので、アドレスは適当です。 * Seesaw は node01 にインストール * node01 のインタフェースは IPアドレスを振った方が Node用で、無い方が LB の VIP用 * Requirement には Node のインタフェースは2つで、いずれも同じ L2 セグメントにするように書かれている * VIP は 192.168.37.200 * c

ソースは CentOS 7.0.1406 (3.10.0-123.el7.x86_64) で private モードの流れを確認した。 macvlan とは 実 NIC の上に仮想的な NIC 作る機能。 作成した仮想 NIC には任意の MAC アドレスを設定できる。 keepalived の仮想 MAC アドレス機能の実現に使われている。 LXC でもコンテナ用の仮想 NIC として使われている。 Kernel Documentation で触れられていないようだがマイナーな存在なのだろうか？ Virtual switching technologies and Linux bridge の 6-10 ページあたりが参考になる。 4つのモードがあるが、private か bridge を使うことが多そう。 private vepa bridge passthru 使い方 設定によっては

テスト用ファイル ちょうど手元にあった PPPoE の pcap ファイルから CHAP の部分を抜粋したもの PPPoE のユーザ名 (hogehoge@one.ocn.ne.jp) をマスクする目的で書き換えてみる。 hogehoge の部分を xxxxxxxx のようにどうでもいい文字列で埋める。 編集したいファイルが大きい場合、Vim を使う方法ではメモリ消費が激しいので避ける。 dd でバイナリ編集 編集する場所を確認するため、一度 hexdump で中身を調べる $ hexdump -C pppoe.cap 00000000 0a 0d 0d 0a 34 00 00 00 4d 3c 2b 1a 01 00 00 00 |....4...M<+.....| 00000010 ff ff ff ff ff ff ff ff 04 00 0e 00 45 64 69 74 |...

仮想マシンのコンソールが欲しい 久々に VirtualBox を触ったのでメモ。ついでに VMware Player もまとめておく。 KVM コンソールのような大げさな画面はいらないし headless で VM を起動したいけど、いざって時のためにコンソールを触れるようにしておきたい。 ゲストOS 側の設定も必要だが、ここはやはりシリアルコンソールで。 VirtualBox でシリアル出力設定する Linux なら unix domain socket を置くディレクトリを用意しておき、 VirtualBox を起動して下記のように設定する socket は Create Pipe にチェックを入れておけば VM 起動時に自動的に作成される。 ホストOS が Windows なら \\.\pipe\mypipename のようにする。 VMware Player でシリアル出力設定する

久々にクロスルート証明書を触ったら忘れていたのでメモ。 一行で言うと verify する時は -trusted_first を忘れずつける、というだけ。 Symantec のサイトを利用してテストする。 4階層 (クロスルート) は Class 3 Public Primary Certification Authority がルートになる。 あらかじめルート証明書を入手しておく。 $ echo | openssl s_client -connect www.jp.websecurity.symantec.com:443 -CAfile RootCA_1.cer -verify 3 | tail -n 5 verify depth is 3 depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certifica

やりたいこと 以前調べた時に、stunnel を使えば SSH over SSL が出来ることは分かった。 stunnel で SSH over SSL する (forward proxy 経由も可) しかし今度は HTTPS も同じサーバで使いたくなった。 アドレスを分けてそれぞれで tcp/443 を listen させれば当然できるが、 追加で IP アドレスを調達するのは面倒だったりお金がかかったりする。 サーバ側の都合としてはポートを分けてもいいのだが、クライアント側の環境が特定ポート宛てしか通信できない場合は困る。 そこで、1つの IP アドレス・ポート番号 のペアで対応する方法を検討した。 解決方法 1. Name based Virtual Host で対応する？ 簡単に名前ベースな Virtual Host を HTTPS で使うなら、 多分サーバ証明書に Subject

SSH したいのにできない、そんな時 Firewall で制限されているなどの理由で外部に ssh できない場合がある。 直接通信は NG で HTTP プロキシサーバ (forward proxy) 経由の通信しか通らない場合などもある。 多くの環境では HTTPS を通す意図で tcp/443 の SSL は通る。 その場合は stunnel を使えば SSL の上で SSH できる。(forward proxy 経由にすることもできる) 注意点 SSH は TCP ハンドシェイク後にサーバ側から開始するプロトコルなので、スキャンされるとその先で SSH を待ち受けていることがすぐに分かる。 ここでは オレオレCAライクな証明書とその配下にサーバ証明書・クライアント証明書を用意し、クライアント証明書検証を必須にすることでスキャンしても普通の SSL であることしか分からないようにする。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?