habrazhitelに挨拶します。少し前に、私はシベリアに散らばった1つの大企業の支店を単一のネットワークに接続するという課題に直面しました。 主な問題は、OpenVPNを介してすべてのトラフィックを許可しながら、OpenVPNを不安定なPPPoE上で動作させる必要があることでした
最初の目標は、支店のインターネットトラフィックでお金を節約することでした。 遠隔地では、幅256kb / sの無制限のADSLの価格は約7-10t.rです。 毎月、インターネットが不可欠でした。
喜びは、ほぼすべての支店に1つのプロバイダーの接続があり、ローカルおよびピアツーピアトラフィックの概念があり、本社には専用の広範なインターネット（別のプロバイダーが、偶然にも支店プロバイダーに忠実であり、ピアツーピアトラフィック」（メガバイトあたり約6コペックの価格）。
1.プロキシ
最速のソリューションは、プロキシサーバーの通常のカスケードでした。 すべての支店が直接インターネットにモデムを配る前に、誰もがゲートウェイとして機能するシステムユニットを1つ割り当てる必要がありました。システムスペシャリストは贈り物ではなく、800番目の切り株を与えます。 7 tr あなたはまともなゲートウェイを集めることができますが、マスターはマスターです、私は費用なしで言いたいです！
これらのゲートウェイにはUbuntu 8.04がインストールされており、LTSはゲートウェイとして構成されているため、ローカルネットワーク、モデム、コンセントに接続され、すべてがすぐに機能しました。 多くのブランチでは、管理者はユーザーのキーボードの「任意のキー」のみを押すことができましたが、問題はなく、徐々に7つのブランチがモデムを再構成し、ゲートウェイをスタックしました。
彼らはすぐにプロキシをカスケードで上げ、httpトラフィックはそこでタキシングされましたが、知っているように、httpsトラフィックは総トラフィックの特定の割合に過ぎず、単純な関税への切り替えは節約でしたが、条件付きです、例えば、怠慢な管理者またはユーザーはお金のために支店を得ると約束した重要な何か...
途中で、他のタスクが中央オフィスに登場しました-比較郵便配達員、ゲートウェイ、2002年に設定されたポータルを動かし、それ以来触れられていませんが、これは別の記事に値します...
それまでの間、私たちは単にネットワークに興味を持っています...
2. OpenVPN
私はこのことを初めて見ました。最初の知り合いへのある種の恐怖があり、マニュアルやインターネットを読んで、袖をまくり、登りました:)
2.1サーバー
2つのネットワークアダプターeth1（192.168.5.x）があります-ローカルエリアネットワークとeth0（実際のip 111.111.111.111）インターネットとワイドチャネル。
apt-get install openvpn次に、サーバー構成ファイルを作成します
touch /etc/openvpn/server.confシステムの起動時に、/ etc / openvpnフォルダーに拡張子.confの対応するファイルがあるすべてのVPN接続が自動的に発生しますこのようになりました。
port 1194 #
proto udp #
dev tun #
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key # This file should be kept secret
dh /etc/openvpn/dh1024.pem
server 10.10.10.0 255.255.255.0 # vpn subnet
ifconfig-pool-persist ipp.txt # ip
push "route 192.168.5.0 255.255.255.0" # home
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 4
mute 20
client-to-client
client-config-dir /etc/openvpn/ccd #
route 192.168.0.0 255.255.255.0 # 1
route 192.168.1.0 255.255.255.0 # 2
個々のクライアント設定が保存されるディレクトリを作成します。
mkdir /etc/openvpn/ccd次に、暗号化と承認のためのキーと証明書を作成する必要があります
cd /usr/share/doc/openvpn/examples/easy-rsa/2.0
source ./vars
./clean-all
./build-ca次に、サーバーの証明書と秘密鍵を作成します。
./build-key-server serverクライアントのキーを作成します（クライアントが複数ある場合は、手順を繰り返す必要があります）。
./build-key client1各クライアントには、固有の名前（この場合はclient1）が必要です。しばらくして新しいクライアントが作成された場合、手順は次のようになります。cd /usr/share/doc/openvpn/examples/easy-rsa/2.0
source ./vars
./build-key client2
Diffie-Hellmanパラメーターを生成します。
./build-dh次のファイルをディレクトリ/ etc / openvpn /に配置します
* ca.crt
* server.crt
* dh1024.pem
* server.keyファイル/etc/openvpn/ipp.txtを作成します
クライアントマシンの構成ファイル/etc/openvpn/client.conf
remote 111.111.111.111 1194
client
dev tun
proto udp
resolv-retry infinite # this is necessary for DynDNS
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client1.crt
key /etc/openvpn/client1.key
comp-lzo
verb 4
mute 20
redirect-gateway
#show-net-up
verb 4ここで、生成されたクライアントキーとサーバーの権威証明書をサーバーから/ etc / openvpn /フォルダーにコピーする必要があります。
* ca.crt
* client1.crt
* client1.keyクライアントが192.168.1.xネットワークを非表示にしている場合、サーバーがそれを表示するには、サーバー上のルートを追加する必要があります。
サーバーで、次の内容のファイル/ etc / openvpn / ccd / client1を作成します。
iroute 192.168.1.0 255.255.255.0
# 2, 2
#push "route 192.168.100.0 255.255.255.0"
# OpenVPN
push "redirect-gateway def1"
ここで、実際、最も悪い問題が私に起こりました。
OpenVPN受信ディレクティブ
push "redirect-gateway def1"（構成に「プル」がある場合）、クライアントは古いルートを削除せず、エントリをルーティングテーブルに追加します。0.0.0.0/1 via 192.168.231.5 dev tun0
128.0.0.0/1 via 192.168.231.5 dev tun0また、openvpnがイーサネットを経由する場合、すべてが機能し、管理者とユーザーを満足させますが、偉大なpppはそのようなルートを取ることを好みます。
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0OpenVPNはこのように誓います
Jul 2 19:28:53 ino ovpn-client[14465]: NOTE: unable to redirect default gateway -- Cannot read current default gateway from systemこの問題の解決策は、表面上ではありますが、長く退屈なものでした。 この「曲線」pppルートで、実際のゲートウェイ0.0.0.0ではなくゲートウェイを指定すると、OpenVPNはこのルートを認識し、問題なく独自のルートを追加します。
だから私はファイルを作成しました
/etc/ppp/ip-up.d/routingここに小さなスクリプトを登録しました。 （足で蹴らないようにお願いします、私はとても怠け者で、ゲートウェイを決定してルートを編集するための本格的なスクリプトを書きませんでしたが、単純な松葉杖のようにしました）
誰かがその場でルートを編集するための、より論理的で信頼性の高い普遍的な方法を提供してくれたらとてもうれしいです。これまでのところ、すべてがpppブレークで100％動作するという確実性はありません。しかし、人生は、もしあれば、トピックを修正します。
#! /bin/sh
# 222...
gw1=`ip route show | grep 222 | awk '{print $1}'`
# 0.0.0.0 0.0.0.0
route del default
#
route add -net default gw ${gw1} dev ppp0実行可能にする
chmod ug+x /etc/ppp/ip-up.d/routing再起動後、しばらくしてサーバーは外部IPでのpingを停止しましたが、内部で応答し始めました-10.10.10.26
PSユーザーに重要なインターネットを提供するために、ゲートウェイとサーバーとクライアントのファイアウォールを修正する必要があることを考慮してください。
たとえば、私はこのようにしました：
-A POSTROUTING -s 192.168.0.0/255.255.0.0 -j MASQUERADE外部インターフェイスまたはIPへのバインドはありません:)
さまざまな理由でopenvpnがない場合、ユーザーは直接インターネットに接続でき、表示されるとすべてのトラフィックが通過します。
おわりに
人生では、このシステムは段階的に組み立てられ、最初にVPNサーバーとVPNクライアントが起動され、アドレス10.10.10.xで相互にpingされ、次にサーバーとクライアントの背後にあるネットワークへのルートが追加され、すべてが安定して信頼できるときにpingがチェックされ、ディレクティブが追加されます
push "redirect-gateway def1"そして再び仕事と生活を達成し、すべてがオフィスを離れることなく行われ、ブランチゲートウェイでネットワークインターフェイスが署名されたため、管理者は単にネットワークケーブルと電源を差し込んで私に電話をかけ、それからsshが機能するように構成しました。
ああ、私はほとんど最も重要なこと-利益を忘れていました
現在では、ネットワーク全体が内部IPアドレスによってブランチおよびセンターのサーバーとサービスにアクセスしているという事実に加えて、経済的な節約もあります。
以前は、各支店が平均で7,000ルーブルをインターネットに費やしていました。 月ごと、今では月ごとにそれぞれ550ルーブルを支払います。 ピアリングへのアクセスの場合、インターネットは消費されません（中央のインターネットを除く）。最初に、7つのブランチが開始されました。
古いスキームの下で1年間、同社はインターネット上で
588,000ルーブルを費やすことが判明しました
。 、現在のスキームでは、年間
46,200ルーブルが使用されます
。次は？
そして今、この全体で
...私たちは離陸しようとします！ ブランチ間の長距離電話通話のコストを最小限に抑え、softATSをブランチ内のハードウェアと接続するために、IPテレフォニーを展開しようとします。 頑張って
update1 「大企業」という用語について多くの疑問が生じました。
シベリアでは大きく、センターには200人の従業員のスタッフがおり、20〜60の支店があり、10〜20個のオブジェクトが各支店にまだ取り付けられています。 各5-15人。 30未満のブランチ。
同社はあまり機敏ではなく、主な制御は州、機器から来ており、IT開発に向けていくつかのステップを踏んでいます:)
Update2そのため、テスト後に、管理サーバーを長時間下げた場合、クライアントはvpnを開こうとせず、トラフィックは直接高価なインターネットに送られることが判明しました。
また、ADSLチャンネルが強制的に破れた場合、開いているサーバーは再び起動しようとしているように見えますが、動作しないものは輪になって動きます。
私はあらゆる種類のオプションとキープアライブとping-restartなどを試しました...助けにはなりませんでした...
したがって、状況を確認する小さなスクリプトを作成します。
touch /usr/bin/vpn_keepalive.shコンテンツ付き。
#! /bin/sh
# ,
#debug_out=/dev/null
debug_out=/dev/stdout
#NEXTHOP
# OpenVPN
NEXTHOP=192.168.5.1
#
OPEN_VPN_CMD="sudo /etc/init.d/openvpn restart"
PING=/bin/ping
logger_opts="-t $0"
if [ "$debug_out" = "/dev/stdout" ]
then
logger_opts="$logger_opts -s"
fi
pckts_rcvd=`$PING -c 8 -q -W 2 $NEXTHOP | grep transm | awk '{print $4}'`
echo "host: $NEXTHOP, pckts_rcvd: $pckts_rcvd" >$debug_out
if [ $pckts_rcvd -eq 0 ]
then
echo "Connection with $NEXTHOP lost, resetting" | logger $logopts
$OPEN_VPN_CMD > $debug_out
else
echo "Connection with $NEXTHOP up, no action" | logger $logopts
fi
実行可能にする
chmod ug+x /usr/bin/vpn_keepalive.shスクリプトはホストにpingを実行し、0パケットが返された場合、再起動コマンドを実行します。
その後、すべてが上昇することが保証され、正しいルートが流れ込み、トラフィックはVPNトラフィックを通過します
私たちはこのスクリプトを冠で投げます
crontab -eたとえば、2分ごと。
0-59/2 * * * * /usr/bin/vpn_keepalive.shデバッグが有効になっている場合、すべてログ（syslog）で次のようにマークされます。
logger: Connection with 192.168.5.1 up, no action頑張って