VPN利用者のためにdelegateでSOCKSサーバーを立ててみました

VPN利用者のためにdelegateでSOCKSサーバーを立ててみました

Clock Icon2017.09.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは植木和樹@上越妙高オフィスです。クラスメソッドではリモートワーカーや、海外出張する方が多いため出先でも安全に社内外にアクセスできるための仕組みを準備しています。

【Sophos】AWSに構築したVPNサーバ経由で社内PCにリモートアクセスするにはIPマスカレードを有効にする

SophosUTMをActive Directory連携させて特定ADグループのユーザーにのみSSL-VPNを許可する

リモートから社内へのアクセスはこれで問題ないのですが「本社のグローバルIPで制限されたサイトに接続したい」という要望を受けました。

これまでVPN装置は本社サーバー室にあったためVPN接続できればそのまま本社グローバルIPでインターネットに出て行けましたが、新しいVPN装置(SophosUTM)はAWSにあります。さてどうしたものか・・・というのが今回の課題です。

20170904_socks001

リモートアクセスのためのプロキシーサーバー

解決方法は簡単で「本社にプロキシーサーバーをたてる」です。VPN接続後にプロキシーを経由することで、あたかも本社からインターネットに出ていくようにみせることができます。 ここで検討しなければならないのは「どのアプリケーション用プロキシーを立てるか?」です。これまで社内ではブラウザ(HTTP/HTTPS)用にApacheで構築したプロキシーサーバーを用意していました。

要望として「sshしたい」「Windowsのリモートデスクトップ(RDP)を使いたい」という意見が多いようです。Windows(RDP)はRemoteDesktop Gatewayを構築すればいいんでしょうが、アプリケーション毎にプロキシーサーバーを用意するのは構築の手間的にも、保守的にも、コスト的にも回避したいところです。

SOCKSサーバーをたてる

要は「プロトコルに依らずクライアントから受け取った通信を透過的に」通してくれれば良いわけです。というわけでSOCKSサーバーというのをdelegateで立ててみました。

20170904_socks002

プロキシーといえばdelegateだよね、という20世紀的発想で選択していますが、21世紀の今ならもっとエレガントな解法があるのかもしれません。(きたれ若人)

環境

本社サーバー室にはVMWare環境があり、先述のHTTPプロキシーサーバーはそこで動いています。今回はそこにdelegateを同居させてみましょう。

$ cat /etc/centos-release
CentOS release 6.5 (Final)

$ uname -r
2.6.32-431.el6.x86_64

バイナリーファイルのダウンロード

公式サイトからバイナリーをダウンロードします。

FTP Directory delegate.hpcc.jp pub/DeleGate/bin/linux/9.9.13/

先述の通り今回はサーバーのOSやカーネルバージョンが古いので最近のLinuxではそのままバイナリーは動かないかもしれません。yum, aptで提供されていればそれを、なければソースからビルドしてください。

ファイル展開

ダウンロードしたファイルを展開します。

$ sudo -s
# mkdir -p /opt
# cd /opt
# tar xzf linux2.6-dg9_9_13.tar.gz

dg9_9_13/DGROOT というディレクトリが作成されます。以降このディレクトリを $DGROOT と記載します。

起動

起動プログラムは $DGROOT/bin/dg9_9_13 になります。このコマンドラインオプションを付けて起動することでSOCKSサーバーとして動作します。

# $DGROOT/bin/dg9_9_13 -P1080 SERVER=socks [email protected] RELIABLE="192.168.0.0/24,10.0.0.0/16"

# lsof -nPi TCP:1080
COMMAND   PID     USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
dg9_9_13 9758 delegate   11u  IPv4 2306802      0t0  TCP *:1080 (LISTEN)

TCP/1080 はSOCSサーバーのWellKnownポートです。RELIABLEを指定するとSOCKSサーバーを利用できるクライアントのネットワークを限定することができます。

接続確認

openssh (macOS)

接続時にProxyCommandncコマンドを実行しSOCKSサーバーを指定してください。nc-xオプションを付けると proxy.example.com をプロキシーとして利用してくれるようになります。

ssh yourserver -o ProxyCommand='nc -x proxy.example.com %h %p'

Teraterm (Windows)

TeraTerm は[設定]-[プロキシ]でプロキシーサーバーの設定ができます。SOCKSのバージョンは4を指定してください。

20170904_socks003_teraterm

TeraTermのウィンドウを閉じると設定がリセットされてしまいますので、常にプロキシー経由で接続する場合は[設定]-[設定の保存]しておきましょう。

Chrome/Firefox

Chrome(macOS)の場合は [設定] - [詳細設定] - [システム] - [プロキシ設定を開く] をクリックすると、システム設定が開いてSOCKSサーバーを設定することができます。

20170904_socks003_chrome

社内ではFoxyProxyなどの機能拡張をいれて手軽にプロキシーのオン/オフを切り替えられるようにしている人が多いようです。

Firefoxは[設定] - [詳細] - [ネットワーク] - [接続設定] で設定できます。

20170904_socks003_firefox

RDP (macOS, Paralles Client)

macOSのParallels Clientであれば、SOCKS経由でRDPが可能です。

20170904_socks003_parallels

残念ながら、Windows標準の「リモートデスクトップ接続」や「Microsoft Remote Desktop (beta)」での設定は見つかりませんでした。ローカルにopensshでポートフォワーディング設定してSOCKSを通すようにすればできるかも・・・

Git (2017/10/11 追記)

git を使いたい場合は http.proxy を設定します。

$ git config http.proxy 'socks://proxy.example.com:1080'
$ git config --local --list | grep proxy
http.proxy=socks://proxy.example.com:1080

VPN経由でない環境で http.proxy 設定を解除したい場合は次のコマンドを実行してください。

$ git config --unset http.proxy
$ git config --local --list | grep proxy
(設定が削除されていれば何も表示されません)

もしうまく繋がらない場合は GIT_CURL_VERBOSE=1 をつけてコマンドを実行すると、トレースログを見ることができます。

$ GIT_CURL_VERBOSE=1 git pull -v
* Couldn't find host github.com in the .netrc file; using defaults
*   Trying 192.168.xxx.xxx...
* TCP_NODELAY set
* SOCKS4 communication to github.com:443
* SOCKS4 connect to IPv4 192.30.255.113 (locally resolved) (← これはgithub.comのグローバルIPアドレスです)
* SOCKS4 request granted.
* Connected to proxy.classmethod.jp (192.168.xxx.xxx) port 1080 (#0) (← ここでProxyに繋ぎにいっていることが分かります)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: github.com
* Server certificate: DigiCert SHA2 Extended Validation Server CA
* Server certificate: DigiCert High Assurance EV Root CA
:
:

まとめ

delegateによるSOCKSサーバーの設定と、クライアントの設定について書きました。

なお実際は init.d でdelegateデーモンが自動起動する設定になってますし、ansibleを使って構築できるようにしてあります。自動起動については手順が非常にわかりやすく書かれたサイトがありますので、こちらを参考にしてください。DeleGate 9.9.0のインストールと設定 - yuhei.kagaya

クライアントの設定で「puttyは?」「Poderosaは?」という質問があるかもしれませんが、全部のsshクライアントを試してられないので各自で確認して社内Wikiに書いていただけると助かります。

今後について

今後は社内から利用する際にも、IP制限がかかったサイトには常にプロキシーを経由するようのが良いかもしれないと考えてます。

  1. 本社(の回線)に依存しないグローバルIPを1つ持っておく
  2. 上記グローバルIPをIP制限の許可対象に含めておく(セキュリティグループ等)
  3. プロキシーは上記グローバルIPから出ていくようにする
  4. 今後本社移転(?)した時にも影響小さい

全社のすべてのトラフィックを単一ゲートウェイに通すという手もあるんでしょうが、ネットワーク通信量やレイテンシ、冗長性の課題がありそうです。Webレピュテーションはやりやすそうですが。

会社規模の(急)拡大に対して、利便性を損なわず、クラウドを利用してなるべく運用に人手をかけず、セキュリティ的にも安全で、2〜3年先を見つめた社内ITインフラの設定ってのは難しいものですね。「楽しそうなことやってるじゃ〜ん」と腕に覚えのある方は是非植木までお声かけください。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.