自宅内のネットワークというか、サーバの用途変更を色々やっている中で、ルータとしている VyOS マシンで Web プロキシーを動かしてみたので、それに関して得られた知見など、メモとしてまとめておく。
なお、使用している VyOS のバージョンは 1.1.8 です。
VyOS で Web プロキシーを有効化
単純に動作させるだけだったら、
set service webproxy listen-address 172.16.0.1
commit
と、プロキシーを利用させたいクライアンが繋がっている側のインターフェースの IP アドレスを指定すれば、設定が完了して、Squid が動作を開始。
この状態では、透過プロキシーとして動作しているので、クライアント側の設定を変える必要もなく、導入自体はお手軽、なのだけど、これがちょっと曲者といえば曲者だったのよね…。
我が家のネットワーク構成
ここで、簡単に我が家のネットワーク構成を說明しておく。
自宅内には、サーバが 2 台。1 台は SMTP サーバがメイン用途で、もう 1 台(図中の内部サーバ)はローカルネット内で DNS キャッシュ兼プロキシー兼仮想環境による実験用として使用。
あと、さくらの VPS に Web サーバ、DB サーバの VPS が 1 台づつ。
実際には、各サーバ複数の用途で使っているので、 自宅側の SMTP サーバは DNS のセカンダリ兼務だし、 Web サーバは DNS 権威サーバであり、 SMTP のセカンダリでもある、いう感じ。
ちょっと前までは、 SMTP サーバに IP Masquerade 設定して外部とローカルネットのゲートウェイにしてて、更にそこに Squid でプロキシー立ててたんだけど、新しくサーバを手に入れたのを契機に用途見直ししたので、現状では上の図のようになっています。
んで、今回内部サーバ上のプロキシーの上位プロキシーとして VyOS 上で動作するプロキシーを指定したところ、ちょっとハマったというわけ…。
VyOS を Web プロキシー化する際の注意事項、とか
まずハマったのが、一部のアクセスがループしてログが爆発的に発生したために、ディクスの空き容量を食いつぶしてしまったこと。
2017/12/15 18:40:12| WARNING: Forwarding loop detected for:
GET /squid-internal-dynamic/netdb HTTP/1.1
Host: 172.16.0.1:3128
Via: 1.1 localhost (squid/3.1.6)
X-Forwarded-For: ::, unknown
Cache-Control: max-age=259200
Connection: keep-alive
2017/12/15 18:40:12| WARNING: Forwarding loop detected for:
GET /squid-internal-dynamic/netdb HTTP/1.1
Host: 172.16.0.1:3128
Via: 1.1 localhost (squid/3.1.6), 1.1 localhost (squid/3.1.6)
X-Forwarded-For: ::, unknown, unknown
Cache-Control: max-age=259200
Connection: keep-alive
2017/12/15 18:40:12| WARNING: Forwarding loop detected for:
GET /squid-internal-dynamic/netdb HTTP/1.1
Host: 172.16.0.1:3128
Via: 1.1 localhost (squid/3.1.6), 1.1 localhost (squid/3.1.6), 1.1 localhost (squid/3.1.6)
X-Forwarded-For: ::, unknown, unknown, unknown
Cache-Control: max-age=259200
Connection: keep-alive
コレに関しては、内部サーバの Squid 側での上位プロキシーの設定に "no-netdb-exchange" と "no-digest" を指定することで回避はできる。
cache_peer 172.16.0.1 parent 3128 7 no-netdb-exchange no-digest
never_direct allow all
また、上の方で「透過プロキシーとして動作しているので、クライアント側の設定を変える必要もなく、導入自体はお手軽」とは書いたのだけど、よくよくチェックしてみたら HTTP に対してしか透過プロキシーとして動作しないような設定になっているのがわかったので、昨今の HTTPS が推奨されるの流れにあってないというのがありまして…。
透過プロキシーを構成する上で、 HTTP/HTTPS を プロキシーポート(3128 とか 8080)に流し込むために iptables でポート転送を設定する必要があるのですけど、 "iptables -t nat -nL
" を実行して確認したところ、
Chain WEBPROXY (1 references)
target prot opt source destination
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 3128
しか設定されてない…。
このポート転送の設定に関しては、VyOS の内部処理になっているようで、コマンドレベルでの変更が不可能だったので、
set service webproxy listen-address 172.16.0.1 disable-transparent
commit
として、透過モードではない形で運用するように変更。おそらく、 WEBPROXY チェーンに 443 → 3128 のポート転送設定をいれてやれば、HTTPS も透過モードで使えるようになると思うのだけど、その点については未確認。
透過モードにしておければ、クライアント側で明示的にプロキシーの設定ができない機器が Web アクセスしているのとか、子供たちがノート PC の設定をいじってプロキシー使わずに Web アクセスされても、ゲートウェイ部分で記録が取れるよね、と考えてたりするんですけどねぇ…。
で、今回あれこれやっている中で、 VyOS の Rolling Version の最新版を試してみたりしていたわけですが、そちらは Squid が 3.4.8 だったりするのもあって「そっちが使えたら…」というのもあったんですが、何故かプロバイダとの PPPoE 接続が出来ないという状況になりまして、利用を断念しました。(何故、接続できなかったのかまでは、追いきれていない…。)
Squid 、 Ver 3.2 以降だとマルチコア対応が強化されてる( workers というディレクティブが追加されている)ので、パフォーマンス出しやすかったりしますし。
さて、もう少し、対応策を考えてみますかね…。
トラックバック(2)
VyOS を Rolling Version へとバージョンアップしてみた。 Rolling Verison は、いわゆる開発版、ベータ版とも言えるもので... 続きを読む
ということで、前エントリーからの続き。 我が家のネットワーク環境については、さらにちょっと前のエントリーで既出なわけですが 概略としては上の図の通りで、 ... 続きを読む
コメントする