構成
今回試した構成はこうです。
pfSense 2.0-BETA2評価機@PenDC E2160 Mem2G(上のやつ)
pfSense 1.2.3@Cel E3300 Mem2G
もはやRADIUS oneの皮を着た別物ですw
RADIUS oneのソフトウェア中身はともかく、ガワと電源は中々いい出来です。何よりネットワークアプライアンスっぽくていいです。今度LCDproc用のLCD買ってこようかな…
さて、邪魔なものを省き単純な図にするとこうです。
RADIUS oneが似てないのは気にしないとして、上のやつが今回RADIUSサーバになる1.2.3で下のCaptivePortalをする方が2.0Betaです。2.0の方から見ると青線がWAN側で緑線側がLANです。
RADIUSサーバのセットアップ
PackageからFreeRADIUSを追加したら、Services→FreeRADIUSでユーザーを追加します。必要なのはUsername、Password、Number of Multiple connectionです。IPの割り当てなどはVPNの認証をRADIUSサーバにした際に必要になるようで、CaptivePortalに関して言えばIPは関係ありません。これに関しては特に難しいことはないと思います。
次に、Clientsのタブを設定をします。これをしないと認証できません。
Clientには繋ぎに来るクライアントのIP、この場合には10.0.0.2を入れます。
Shared Secretには認証パスワード、Shortnameにはログを見た際にわかりやすい名前を適当に入れます。
ここではSharedkeyをsecretとします。
その他セッティングに関してはデフォルトのままでいいと思いますが、トラブルシューティングのためにLogは有効にしておいた方がいいかもしれません。
ログを見るにはSSHなりシリアルコンソールなりAnytermなりで
cat /var/log/radius.log
すれば見れます。
Captive portalのセットアップ
まずはCaptivePortalが使える状態にします。
pfSenseでCaptive Portalを始めるにはここを参照するのが手っ取り早いと思います。
注意する点として、最初は認証ページを持っていないので例に沿ったHTMLページを作って下の方にあるPortal page contentsという項目にアップロードする必要があります。
例
<html>
<body>
<form method="post" action="$PORTAL_ACTION$">
ログイン名:<input name="auth_user" type="text"><br>
パスワード:<input name="auth_pass" type="password"><br>
<input name="redirurl" type="hidden" value="$PORTAL_REDIRURL$">
<input name="accept" type="submit" value="Continue">
</form>
</body>
</html>
そして敢えてここでRADIUS認証をしてみます。需要があるのかどうか知りませんがw
変わる手順としてはAuthの所をRADIUSにするだけです。
あとは、SharedkeyにFreeRADIUSのClientsで設定したパス(ここではsecret)を入れておきます。
そうしたらあとはCaptivePortalが有効になっているインターフェースに繋げば、ブラウザでどのページを開いても認証ページへ強制リダイレクトされるので「FreeRADIUSのユーザーとパスワード」を入れれば通信が開始されると思います。
ね?簡単でしょ?
しかし本当に遊べますねpfSenseは…。
[ 4 コメント ] ( 2007 回表示 ) | このエントリーのURL | ( 2.9 / 1802 ) | ツイート
(´・ω・)
[ コメントを書く ] ( 1499 回表示 ) | このエントリーのURL | ( 3 / 1885 ) | ツイート
時間に余裕があったので久々にpfSenseを弄ってみました。
長くなるので結論から先に言うと
・64ビット版パッケージはまだ開発段階
・32ビット版は使えるけど一部パッケージが対応していない
・地味にStunnelが使えないのが痛い
・OpenVPNやSSLのCert管理機能が大幅によくなってる
・その他追加されたパッケージがいくつかある他は1.2.3と大差はない
アップデート編
http://snapshots.pfsense.org/ に64ビット版のパッケージがあったのでLiveCD installerの pfSense-2.0-BETA1-20100525-1645.iso.gzを入れてみようと思いCDに焼いてみたのですが、Installerを立ち上げようとするとWating backend....から先に進みませんでした。i386版も同じく無理でした。HW構成は以前RADIUS oneにASUS M/B入れたときの構成のままです。
次に1.2.3を入れてSystem→Firm →Manual updateからファームを上げようと思ったのですが、pfSense-Full-Update-2.0-BETA1-20100525-1645.tgzをアップロードしてもファームがアップロード完了してから先に進まないという状況になってしまいました。仕事してるのかとコンソールからTOPを実行してみましたが1時間待っても0.0.0のまま変化無しです。
ダメ元でコンソール(D-sub9ピン)からXModemでのアップデートをしようと思ったのですが、13) Upgrade from consoleからHTTPでアップデート出来るようだったので
http://snapshots.pfsense.org/FreeBSD_RE ... 5-1645.tgz
を指定して実行したところ、「サインされてないけどいいの?オフィシャルじゃないからどんなことが起きても知らないよ?」といわれましたがyで実行。
するとファームのアップデートが開始されました。
しかし64ビット版パッケージだとファームのアップデートに3時間くらいかかりました。@Mem2G,CelDC E3300 カーネルをビルドしてる?
そしてコンソールからIPを設定してWebUIにアクセスするといつもと変わらぬインターフェースが待っていました。
しかし64ビットはBetaだけあってまだいくつかバグがあるようです。
・コンソールでDateを打つとJSTの時刻で帰ってくるのに設定してもトップのCurrent date/timeがUTCになってログの日付もUTCになる
・DNSを指定してると何故かNSLOOKUP/Pingが出来てもwww.pfsense.orgに繋がらないと言われる
・同じくパッケージをインスコしようとしてもパッケージサーバーに繋がらないと言われる
・DNSを指定せずにPPPoE接続時/DHCP設定時にわたされるDNSを使うと解決する
・アドオンパッケージが2つしかない(バグなのかまだパッケージを作ってる途中なのか)
パッケージに関しては本当に2つしかなかったのか不通なせいで2しかリストアップされなかったのか…。
しかし、これらの問題はi386のパッケージでは起こらなかったためi386版を使用することにしました。1xから2.0へのファームのアップデートも386だとUpdate settingsから2.0-Alpha snapshotを選ぶことにより10分くらいで終わったという。
UI編
UIに関して言えば、デザインがモダンになった他は1.2.3でDashboardパッケージを入れている場合大きく変わりません。
まあRSSを表示できるウィジットが追加されたのはいいとして、画像を表示できるウィジットはいまいち使い道が。。
というか強制的に350*350で表示しないで大きさを選ばさせてください。。
ソフトウェア編
追加されたパッケージ
portsentry
全てのポートで待ち受けて、実際に使われている以外のポートにセッションが来た瞬間にiptablesにDropが追加されるという対ポートスキャンソフト。
ただしパッケージを追加しても
Executing custom_php_install_command()...done.
Writing configuration...
から先に進まないです。pkg_addで追加すればシェルから設定できますがWebUIからだとうまくいきませんでした。惜しい。
vnstat2
ネットワーク帯域などのグラフ化をしてくれます。ntopより軽いですかntopの方が詳細にグラフ化してくれるのでマシンスペックによって選択するのがいいと思います。
OpenVPN Client Export Utility
OpenVPNの設定に必要な.key .ovpn .crtファイルを一括で固めてエクスポートしてくれます。クライアントの設定がかなり楽になります。ovpnファイルを実行するだけで繋がります。
OpenVPNの拡張
まず設定ウィザードが使えるようになりました。そしてpfSense内部で複数のユーザーをもてるので以前まで不便だと思っていた点がかなり改善されました。Free RADIUSを入れておけばそこを認証にも使えます。
また、SSLに使う証明書も簡単に設定、追加ができるようになったのでこの点もかなりよくなったと思います。
しかし残念な点があります。
Stunnelを追加すると
Downloading package configuration file... done.
Saving updated package information... done.
Downloading stunnel and its dependencies... done.
Checking for successful package installation... of stunnel-4.25 failed!
Installation aborted.
と出てパッケージの削除も再インストールも出来なくなるのです。
ライブラリの更新が関係しているらしいのですがこれは解決できませんでした。
代替策としてpkg_add -r stunnelでシェルから一から設定すれば一応動かせます。
パフォーマンスの変化については…目に見えた変化はあまりないように見えます。
もっとも、そこまで高負荷な環境で使っていないので負荷をかけ続けてどうなるかだと思います。内側からセッション張りまくってみますかねぇ。
64ビットがまともに動けばメモリの領域だとかセッション数だとかでかなり違ってくるとは思うのですが…。
パフォーマンスの測定でiperfを走らせて気がついたのですが、iperfを実行するとService->Stop iperfを実行してもシェルでpsすると何故かプロセスが残っているのでkillallしないとならなくなります。
やっぱりまだ実験段階ですね…。Stable待ちです。
[ 1 コメント ] ( 2039 回表示 ) | このエントリーのURL | ( 3 / 1894 ) | ツイート
問題です。この中でProcurveでつかるSFPはどれでしょう?
正解はFTRJ8519P1BNLで、下の2つです。
それ以外はNot a Prcurve transceiverと言われてFaultLEDが点灯します。
なんと紛らわしい
ちなみにCentreCom 9424SPとFirebox 8500-FではPingの疎通のみの確認ですが全部使えました
…何が違うの?
[ 1 コメント ] ( 2089 回表示 ) | このエントリーのURL | ( 3.1 / 2075 ) | ツイート
今この鯖はFortigateの裏にあるわけですが、Fortigateが表にあると接続がNATされてしまうので接続のログが全てFGからの接続として記録されてしまいます。
例
192.168.1.1(FGのアドレス) - xmms.jp [17/May/2010:02:24:52 +0900] "GET / HTTP/1.1" 200 5218
など。いちいちFGのログとあわせてみるのもめんどいなーと思いつつ放置していたのですが、やってみると意外に簡単に解決できました。
方法としては外部からの接続インターフェースにURLフィルタリングを適用するだけです。
時間も時間なので手順だけ簡単にまとめると
UTM→WEB filer→URL Filer で適当な名前でポリシーを作成する
↓
URLに*を入れてTypeでWildcardを選択しAllowする
↓
UTM→WEB filer→Profileで適当なのを選んで(最初からWebというのがあるので今回はこれを利用する)Web URL FilterでHTTPとLogingにチェックを入れてOptionで一番最初に作ったポリシーを選択する
↓
適用したらFirewall→Policy→Policyで外部インターフェース→内部のポリシーを作成または選択し、UTMにチェックを入れWEB filerで3番目に作ったProfileを選択する(この場合はWebというポリシー名)
↓
後はLogの所にずらずらとアドレスが流れてきます。
いやー、FGおもしろいわーw
[ コメントを書く ] ( 2308 回表示 ) | このエントリーのURL | ( 3 / 1917 ) | ツイート
<<最初へ <戻る | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 進む> 最後へ>>