ざっくり言うと、pfsenseのSSHログインを有効化+ProxyCommand+nc、といった具合。

[localhost(on the Internet)] -->[pfsense server] -->[target server(on the private network)]

参考にしたサイト

• HOWTO enable SSH access

  …しかしここの説明だとWAN側からのログインを有効にする方法が分からず手間取ったさ。

• How to Access pfSense Remotely Using SSH

  上記サイトと説明がかぶるのだけど、ここでFirewallのRule設定に言及があったので。まぁpfsenseの説明をよく読めば分かったことかも知れんけど。

• ２段階SSH接続を，ProxyCommandを使って一度のsshコマンドで接続する

• 多段 ssh / rsync するために ProxyCommand を使ってみる

• SSH_CONFIG (5)

やりかた

pfsenseの設定

1. pfsenseの管理画面にログイン、System >Advanced >Admin Access >Secure Shellに移動
2. [Enable Secure Shell]をOnに
3. 安全のため[Disable password login for Secure Shell (RSA/DSA key only)]をOnに
4. [SSH port]を適当に指定(仮に114114とでもしておこうか)
5. 以上でSave
6. System >User Managerへ移動、Add Userを実行
7. 冒頭のイメージ図で[localhost(on the Internet)]から[prsense server]へ接続するためのユーザを作成、Save
8. 作成したユーザの編集画面を開き、[Effective Privileges]に[User - System - Shell account access]を追加
9. [Authorized keys]にの公開鍵を追記
10. 以上でSave
11. Firewall >Rulesに移動、Rule追加を実行
12. [Destination]を[WAN]に、[Destination port range]に114114を指定
13. 以上をSaveし、さらにApply change実行

pfsenseの設定は以上で完了。必要に応じ[localhost(on the Internet)]から[pfsense server]にsshログインできることを確認。

クライアント・サーバー(接続先)の設定

1. [localhost(on the Internet)]の公開鍵を[target server(on the private network)]の.ssh/authorized_keysに登録
2. .ssh/configを以下のように記述

   Host gateway
   HostName pfsense_server
   Port 114114
   Host target
   HostName target_server
   ProxyCommand /usr/bin/ssh gateway /usr/bin/nc %h %p
   

.ssh/authorized_keys、.ssh/configのパーミッションには注意すること。

以上を実施のうえ、次のようにsshコマンドを実行することで[pfsense server]を介して[target server(on the private network)]に接続できるようになる。sshの他scp、sftpも使用可能。

[localhost(on the Internet)]$ ssh target_server

特にたくさんの --slave を指定していた場合、一度削除して再登録するのがめんどうくさい。

alternativesシステムの構造を調べて、手動で対策できたのでメモ。

例： ソースコードからインストールしたPostgreSQLを /usr/bin に配置したい。が、pg_ctlを --slave に含め忘れてしまい、postmasterが止まらなくなった orz

(やだなぁ、あくまで例ですよ？)

一連のコマンド群を配置した際の実行パラメータは、次のようになっていた(可読性優先のためコマンドラインオプションごとに改行しています)。

alternatives
 --install /usr/bin/postgres postgresql /usr/local/postgresql-9_3_4/bin/postgres 100
 --slave /usr/bin/postmaster postgresql-postmaster /usr/local/postgresql-9_3_4/bin/postmaster
 --slave /usr/bin/psql postgresql-psql /usr/local/postgresql-9_3_4/bin/psql
 --slave /usr/bin/pg_config postgresql-pg_config /usr/local/postgresql-9_3_4/bin/pg_config
 --slave /usr/bin/pg_dump postgresql-pg_dump /usr/local/postgresql-9_3_4/bin/pg_dump
 --slave /usr/bin/createdb postgresql-createdb /usr/local/postgresql-9_3_4/bin/createdb
 --slave /usr/bin/dropdb postgresql-dropdb /usr/local/postgresql-9_3_4/bin/dropdb
 --slave /usr/bin/initdb postgresql-initdb /usr/local/postgresql-9_3_4/bin/initdb
 --slave /usr/bin/vacuumdb postgresql-vacuumdb /usr/local/postgresql-9_3_4/bin/vacuumdb
 --slave /usr/lib64/postgresql postgresql-lib /usr/local/postgresql-9_3_4/lib

当初はねー、主に使うのはこのあたりのコマンドだけかなー、と思ってたですよ。

この場合のalternativesシステムデータの構造は次のようになっていた。

1. /usr/bin/postgres (シンボリックリンク) は /etc/alternatives/postgresql を示す
2. /etc/alternatives/postgresql (シンボリックリンク) は /usr/local/postgresql-9_3_4/bin/postgres (実体) を示す
3. --slave 指定した /usr/bin/postmaster (シンボリックリンク) は /etc/alternatives/postgresql-postmaster (シンボリックリンク) を示す
4. /etc/alternatives/postgresql-postmaster (シンボリックリンク) は /usr/local/postgresql-9_3_4/bin/postmaster (実体) を示す
5. 以後、 --slave 指定のものは同様に /usr/bin (リンク) → /etc/alternatives/<名前> → <パス> のようになる

ここで問題なのが、 --install と --slave の関係性、リンクに指定した優先度の情報はどこに行ったのか?、という点。特に優先度の情報が見えていない。

これらは /var/lib/alternatives に --install に指定した <名前> というファイル名で保存されていた。

/var/lib/alternatives/postgresql の内容は次のようになっている。

$ cat /var/lib/alternatives/postgresql 
auto
/usr/bin/postgres
postgresql-postmaster
/usr/bin/postmaster
postgresql-psql
/usr/bin/psql
postgresql-pg_config
/usr/bin/pg_config
postgresql-pg_dump
/usr/bin/pg_dump
postgresql-createdb
/usr/bin/createdb
postgresql-dropdb
/usr/bin/dropdb
postgresql-initdb
/usr/bin/initdb
postgresql-vacuumdb
/usr/bin/vacuumdb
postgresql-lib
/usr/lib64/postgresql

/usr/local/postgresql-9_3_4/bin/postgres
100
/usr/local/postgresql-9_3_4/bin/postmaster
/usr/local/postgresql-9_3_4/bin/psql
/usr/local/postgresql-9_3_4/bin/pg_config
/usr/local/postgresql-9_3_4/bin/pg_dump
/usr/local/postgresql-9_3_4/bin/createdb
/usr/local/postgresql-9_3_4/bin/dropdb
/usr/local/postgresql-9_3_4/bin/initdb
/usr/local/postgresql-9_3_4/bin/vacuumdb
/usr/local/postgresql-9_3_4/lib

1行目の auto …はまあ今回無視するとして、2行目に --install で指定した<リンク>、3行目以降に --slave で指定した <リンク>と<名前>が1行ずつ列挙されている。

また、一連の列挙の後1行空けて、 --install で指定した <パス>、<優先度>、 --slave で指定した <パス> が1行ずつ列挙されている。

ということで、指定し忘れた項目(この場合 pg_ctl )を手動で追加するには、次の手順となる。

1. /var/lib/alternatives/postgresql の上段(1行目～空行まで)の末尾に以下を追記
   

   postgresql-pg_ctl
   /usr/local/postgresql-9_3_4/bin/pg_ctl
   

2. /etc/alternatives/postgresql-pg_ctl という名前で usr/local/postgresql-9_3_4/bin/pg_ctl へのシンボリックリンクを作成
3. /usr/bin/pg_ctl という名前で /etc/alternatives/postgresql-pg_ctl へのシンボリックリンクを作成
4. alternatives —display postgresql で手動追加が反映されたことを確認(以下、結果)
   

   $ alternatives --display postgresql
   postgresql -ステータスは自動です。
   リンクは現在 /usr/local/postgresql-9_3_4/bin/postgres を指しています。
   /usr/local/postgresql-9_3_4/bin/postgres - 優先項目 100
    スレーブ postgresql-postmaster: /usr/local/postgresql-9_3_4/bin/postmaster
    スレーブ postgresql-psql: /usr/local/postgresql-9_3_4/bin/psql
    スレーブ postgresql-pg_config: /usr/local/postgresql-9_3_4/bin/pg_config
    スレーブ postgresql-pg_dump: /usr/local/postgresql-9_3_4/bin/pg_dump
    スレーブ postgresql-createdb: /usr/local/postgresql-9_3_4/bin/createdb
    スレーブ postgresql-dropdb: /usr/local/postgresql-9_3_4/bin/dropdb
    スレーブ postgresql-initdb: /usr/local/postgresql-9_3_4/bin/initdb
    スレーブ postgresql-vacuumdb: /usr/local/postgresql-9_3_4/bin/vacuumdb
    スレーブ postgresql-lib: /usr/local/postgresql-9_3_4/lib
    スレーブ postgresql-pg_ctl: /usr/local/postgresql-9_3_4/bin/pg_ctl
   現在の「最適」バージョンは /usr/local/postgresql-9_3_4/bin/postgres です。
   

…いやぁ、あくまで例デスよ？(汗)

xhci-hcd モジュールをアンロードしてからロードすれば回復するっぽい。ちぃ覚えた。

具体的には CentOS 6.5 でのお話。USB3.0 は後付けの玄人志向 USB3.0R-P2H2-PCIE。Groovyの UD-3000SA でHDDを繋いだあたりで期限を損ねてしまい、以後は他の接続実績のあるUSB HDDを接続しても認識しない状態に。

OSリセットすべし、という情報もあったけど、それは何か負けのような気がする…というか別のプロセスで長時間かかる md5sum チェックをしていたのでリセットするわけにもいかず。どーせ何かを再起動すればいけるんじゃね?　と色々あさった結論。

最初は usb_storage を再読み込みさせたけど、反応が変わらなかった。dmesgのエラーログを見ると、どうやらHUBあたりがエラーを起こしているっぽい。ていうかM/BのUSB2.0ポートは普通にUSBメモリとか認識するので、 usb_storage は悪くない、らしい。

usb_storage より下層の(ハード寄りの)部分ってなんだっけ？　と漁った結果、uhciとかohciとかそのあたりよね、と。それっぽい名前を lsmod で探したところ、 xhci-hcd が見つかった。

"xhci-hcd" の正体を確認すべくググると、正体どころか "Bug 717633 - USB3.0 harddisk not working with xhci_hcd module " なんて記事が出てきたので、内容読むまでもなくあぁこれぢゃね、等と。

再読み込みにあたり念のためアンロードしたけど、USBまわりなのでアンロードと同時にUSBキーボードとか色々使用不能に陥る可能性を危惧(作業はssh接続してたけど)。予め sudo -v で認証も突破した上で、連続実行するように仕向ける。

$ sudo modprobe -r xhci-hcd ; sudo modprobe xhci-hcd

その後 dmesg 見たら認識しなかったUSB HDDも無事認識してマウントできるようになってた。