私はついにサーバーを手に入れました。 彼は彼の「会社」のサイトをその上に投稿し、隣はVPNを上げることに決めました。 このために、2番目のIPが注文されました。 最初はWeb、メール、sshがあり、2番目はVPNトラフィックが流れます。 アイデアは単純ですが、そのような構成の適切な説明は見つかりませんでした。 カットの下で、VPNトラフィックがインターネットのみに行き、近隣のIPに自由に通過できないようにShorewallを構成する方法を示します。
この投稿では、すべてのプログラムのインストールではなく、Habrを含む何度も説明されていますが、すべてのネットワークインターフェイスが同じカード上にある場合のファイアウォールのセットアップに焦点を当てたいと思います。 ファイアウォールを制御するには、Shorewallパッケージを使用します。 shorewallサイトには非常に多くのドキュメントがありますが、基本的には分割されたネットワークカードを使用した構成とその背後のサブネットについて説明しています。
最初にifconfigを見てみましょう。 そこには、2つのIPシュニック「1.1.1.1」と「2.2.2.2」があります。 どちらもインターネットに直接アクセスします。 現在、これらは「双子」です。つまり、最初のサービスでいくつかのサービスが回転している場合、2番目のIPで表示されます。
このケースをカバーして、1.1.1.1がwebに渡され、email、ssh、2.2.2.2がvpnをリッスンするようにします。 設定は次のとおりです。
これは標準構成であり、VPS-aからインターネットへのすべてのトラフィックの通過を許可し、ルールに記述されているものを除き、何も戻すことを許可しません。 ゾーン$ FWは、両方がeth0の一部であるため、両方のIPを意味します（2.2.2.2には独自の名前eth0：0があるにもかかわらず）。 明確にするために、$ FW：[ip]タイプのkostructionが使用されます。 すべてがうまくいくようです。 次に、VPNサーバーを起動し、ifconfigを確認します。 すでにそこにあったものに加えて、新しいインターフェースtun0が登場しました：
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.1 PtP:10.1.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:3261 errors:0 dropped:0 overruns:0 frame:0 TX packets:2624 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:351155 (351.1 KB) TX bytes:1043254 (1.0 MB)
tun0インターフェイスはeth0との「ツイン」ではなく、より完全なインターフェイスであることに注意してください。 VPNクライアントはこのサブネットの背後に配置されます。 今すぐ接続しましょう。 別のコンピューターで：承認を行い、接続を確立し、ターミナルに移動して、少なくともvpnゲートウェイ（10.8.0.1）に接続してメールを読み取ります。pingが受け入れられると、pingを実行できます（/etc/sysctl.confを参照）。
$telnet 10.8.0.1 25 $sudo tail /var/log/syslog ... Shorewall:INPUT:REJECT:IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 ... PROTO=TCP SPT=36879 DPT=25 ...
メールサーバーへのアクセス試行は拒否されました。これは、「ツイン」のeth0ではないため、tun0は次のルールによりeth0（およびeth0：0）と通信できないためです。
all all REJECT info
/ etc / shorewall / policyの最後。 これまでのところ良い。 次に、tun0を海岸壁に追加します。
新しい構成：
何が変わった？ tun0インターフェイスに対応するvpn4というゾーンを作成しました。 vpn4をIPv4として宣言しました。 tun0からファイアウォールおよびインターネット（eth0 / net4）へのトラフィックを許可しました。 奇妙なことに、firewall-aのみを許可することはできず、既存の規則$ fw-> net4に従っています。 両方の行を追加する必要があります。 そして、完全なインターネット接続に必要な最後のものはSNAT（送信者のアドレスがインターネット上で見ている人のアドレスに置き換えられたときのソースアドレス変換、この場合は2.2.2.2）です。 masqファイルを作成し、eth0（およびeth0：0）を終了するときに、すべての10.8.0.xアドレスを2.2.2.2に置き換えることを要求します。
私たちは...すべてがうまくいきます！ それでも... 10.8.0.xのアドレスを使用すると、1.1.1.1：1194に移動できますが、これは望ましくありません。 最初にvpnトラフィックをオンラインにしてから、ファイアウォールを介して反撃することを望みました。 代わりに、サーバーを後ろから見るクライアントVPNがあります。 なんで？ 次のような通信を有効にしたとき：
$ FW（1.1.1.1および2.2.2.2）の下に2つのIPがあるため、どのIPを指定しませんでした。 さて、書き留めましょう。 ただし、次のような構文：$ FW：[ip]はポリシーファイルでは受け入れられません。 この時点で、私は多くのことを試してみましたが、ほとんどアイデアをあきらめ、そのままにしておきました。 終わりまでの道はほとんどありませんでしたが。 したがって、洞察：ポリシーに記述されているすべてのものは同じ方法でルールに記述でき、ルールではファイアウォールeで特定のIPを指定できます。 最後の設定を書き直しましょう：
私たちがしたこと：ポリシーから古いパーミッションを削除し、ルールにパーミッションを追加しました。 VPNからインターネットへのすべてのトラフィックを許可し、1.1.1.1への直接のトラフィックを選択的に許可します。 インターネット経由で1.1.1.1に通話を送信できませんか？ いいえ、私たちがいくら好きであろうと、それらはサーバーの中に入ります。そのため、できることはvpnトラフィックのインターネットのルールを複製することです-> 1.1.1.1。 しかし、2.2.2.2のトラフィックはどうでしょうか？ このトラフィックは直接vpnトラフィックであり、内部から来ることはできません（これはクライアントマシン上のルートによって保護されています）。 つまり、vpn-aクライアントは10.8.0.1（vpn4）-> 2.2.2.2（$ fw：2.2.2.2）の方向にトラフィックを送信しません。
まあ、それは基本的にそれです。 これで、「コンパニオン」サイトにつながるIP-shnikを使用することなく、「稼働中の」VPN-aから安全に閲覧でき、通常のvpnユーザーを使用してファイアウォールaをバイパスすることを恐れません。