web-dev-qa-db-ja.com

PPTP VPNを介してすべてのインターネットトラフィックを強制しながら、ローカルLANアクセスを許可するにはどうすればよいですか?

PPTP VPNに常時接続したいLinux Mint 12を実行しているサーバーがあります。VPNサーバーはかなり信頼できますが、ときどきドロップするので、それを作りたいだけですそのため、VPN接続が切断されると、すべてのインターネットアクティビティが無効になります。

自動的に再起動する方法も考えたいのですが、これはめったに発生しないため、それほど大きな問題ではありません。

また、VPNが稼働しているかどうかに関係なく、常にLANからボックスに接続できるようにしたいと考えています。

VPNが正しく接続されている場合のifconfigは次のようになります。

eth0      Link encap:Ethernet  HWaddr 00:22:15:21:59:9a  
          inet addr:192.168.0.171  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::222:15ff:fe21:599a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:37389 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29028 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:37781384 (37.7 MB)  TX bytes:19281394 (19.2 MB)
          Interrupt:41 Base address:0x8000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1446 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1446 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:472178 (472.1 KB)  TX bytes:472178 (472.1 KB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.10.11.10  P-t-P:10.10.11.9  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:1368 (1.3 KB)  TX bytes:1812 (1.8 KB)

私が解決しようとしている問題のように思われる他の場所で見つけたiptablesスクリプトは次のとおりですが、すべてのアクセスをブロックしてしまいますが、何を変更する必要があるのか​​わかりません。

#!/bin/bash

#Set variables
IPT=/sbin/iptables
VPN=`ifconfig|Perl -nE'/dr:(\S+)/&&say$1'|grep 10.`
LAN=192.168.0.0/24

#Flush rules
$IPT -F
$IPT -X

#Default policies and define chains
$IPT -P OUTPUT DROP
$IPT -P INPUT DROP
$IPT -P FORWARD DROP

#Allow input from LAN and tun0 ONLY
$IPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A INPUT -i tun0 -m conntrack --ctstate NEW -j ACCEPT
$IPT -A INPUT -s $LAN -m conntrack --ctstate NEW -j ACCEPT
$IPT -A INPUT -j DROP

#Allow output from lo and tun0 ONLY
$IPT -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
$IPT -A OUTPUT -o tun0 -m conntrack --ctstate NEW -j ACCEPT
$IPT -A OUTPUT -d $VPN -m conntrack --ctstate NEW -j ACCEPT
$IPT -A OUTPUT -j DROP
exit 0

ご協力いただきありがとうございます。

4
user126715

これらのiptablesルールはVPNサーバーへのトラフィックを許可しないため、VPNを確立できません。最後のOUTPUTルールの前にDROPチェーンに次のルールが必要です。ここで、1.2.3.4はVPNサーバーのIPアドレスです。これらにより、ポート1723(TCP制御チャネル)およびGREパケット(データチャネル)へのPPTP接続が可能になります。

iptables --append OUTPUT --destination 1.2.3.4 --protocol tcp --dport 1723 --jump ACCEPT
iptables --append OUTPUT --destination 1.2.3.4 --protocol gre --jump ACCEPT
3
mgorven

これには、ルーティングベースとファイアウォールベースの2つの方法があります。

ルーティングアプローチ

VPNに接続されていないマシンの一般的なルーティングテーブルは、次のようになります。

10.23.11.0/24 dev eth0
default via 10.23.11.1

最初のルートはLAN上のホストへのルートであり、2番目のルートは他のすべてをデフォルトゲートウェイに送信します。 VPNに接続すると、ルーティングテーブルは次のようになります(1.2.3.4はVPNサーバーのパブリックIP、10.8.0.1はVPNサーバーのプライベートIPです)。

10.23.11.0/24 dev eth0
1.2.3.4 via 10.23.11.1
default via 10.8.0.1

最初のルートは同じで、3番目のルートはVPNを介してすべてを送信するルートです。ただし、2番目のルールに注意してください。VPNサーバーのパブリックIPパケットに到達するには、デフォルトゲートウェイを介して送信する必要があるということです。これは、VPNクライアントによって作成されたトンネルパケットが実際にサーバーに到達するためです。このルートが設定されていない場合、VPNクライアントによって作成されたパケットはVPNを介して再度送信され、サーバーに到達することはありません。

これで、3番目のルートが削除された場合、VPNサーバー以外のインターネット上の任意の場所に送信されるパケットには一致するルートがないため、ホストはそれらを送信しません。したがって、VPNが接続されていない場合、ルーティングテーブルは次のようになります。

10.23.11.0/24 dev eth0
1.2.3.4 via 10.23.11.1

LAN上のホストには引き続き到達でき、VPNサーバーにも到達できます(VPNを開始できる必要があるため)が、他のすべてがルーティングされるわけではありません。ただし、特にDHCPを使用している場合は、この設定を取得するのが少し難しい場合があります。ただし、Debianの静的設定では、/etc/network/interfacesに次のものが含まれます。

auto eth0
iface eth0 inet static
    address 10.23.11.10
    netmask 255.255.255.0
    up ip route add 1.2.3.4 via 10.23.11.1

gatewayステートメントがないことに注意してください。これは、デフォルトルートをインストールするものだからです。

このアプローチの欠点は、VPNサーバーへの非VPNトラフィックが暗号化されずに許可されることです。 VPNサーバーで他のサービスを実行していて、それらが保護されていることを確認する必要がある場合は、ファイアウォールアプローチを使用する必要があります。

Edit:@JamesRyanは、デフォルトのルートが自動的または誤って追加される可能性があるため、このアプローチは脆弱であることを示唆しています。もう1つのアプローチは、ブラックホールルートを追加することです。これにより、トラフィックはどこかに送信され、それ以上ルーティングされなくなります。ただし、これは自動的に追加されたデフォルトルートでは機能しません。これは、すでに最高の優先度のメトリック0を使用しているためです。デフォルトルートは削除する必要がありますが、次のようなものを追加できます。

default via 127.255.255.255

ファイアウォールアプローチ

ここでの考え方は、VPNクライアントによって作成されたトンネルトラフィックとLAN宛てのトラフィックを除き、物理インターフェイス上のすべての発信トラフィックをブロックすることです。 VPNを許可するトラフィックは、使用されているプロトコルによって異なります。 PPTPはTCPポート1723を制御チャネルとして使用し、 [〜#〜] gre [〜#〜] を実際のチャネルとして使用しますトンネル。OpenVPNはUDPポート1194を使用します。ファイアウォールルールは次のようになります。

iptables --append OUTPUT --out-interface eth0 --destination 10.23.11.0/24 --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --destination 1.2.3.4 --protocol tcp --dport 1723 --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --destination 1.2.3.4 --protocol gre --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --jump REJECT

最初のルールは、LANのトラフィックを受け入れます。 2番目と3番目のルールは、VPNサーバーへのVPNトラフィックを受け入れます。 4番目のルールは、物理インターフェイスを出る他のすべてのトラフィックを拒否します。

LAN上にないDNSサーバーを使用する場合、受け入れる必要があるもう1つのことはDNSです。これは、VPNクライアントがVPNサーバーを見つけるためにDNSルックアップを実行する必要があるためです。 REJECTの前に次のルールを挿入すると、GoogleのパブリックDNSサービスへのDNSトラフィックが許可されます。

iptables --append OUTPUT --out-interface eth0 --destination 8.8.8.8 --protocol udp --dport 53 --jump ACCEPT
2
mgorven

Nullインターフェイスを指すより高いメトリックを持つ別のデフォルトルートを追加します。 VPNが利用できない場合、2番目のルートが開始され、トラフィックがブラックホール化されます

1
JamesRyan

これはiptablesの質問ではありません-そのためにiptablesは必要ありません。

VPNを経由するようにデフォルトルートを設定するだけで完了です。 VPNがダウンしているときに、使用するメトリックがより悪い別のデフォルトルートを追加することもできます。

LANは直接接続されているため、デフォルトゲートウェイよりも優先されます。

0
mulaz