オリジナル:
私は以前のLinuxインストール(Debian squeeze)から私のルーター用の新しいLinuxインストール(Linux Mint 17.3)に切り替えました(Linuxがインストールされているデスクトップコンピュータ全体を私のルーターとして使用します)。 Linux PCは私のDSLモデムに直接接続し、PPPoE接続をネゴシエートし、他のすべてのデバイスへのインターネット接続をルーティングします。
私が知る限り、私の設定は以前のDebianインストールと同じです。rc.local
新しいコンピュータでも同じで動作しているiptablesを設定する簡単なスクリプトがあります(/etc/rc.local
rootコンソールで実行してこれを保証しました)。新しいボックスにもDNSを設定しました。
ほとんどの機能は同じでしたが、問題が発生しました。 Windows コンピュータの VPN が接続されなくなりました。 Wiresharkを見てみると、最初のPPTPパケットが正常に送受信されたように見えますが、Windowsコンピュータから送信された「Set-Link-Info」パケットがあり、Windowsコンピュータで「PPP LCP設定を開始します。設定要求」パケット。この時点では何の応答もありません。以前のDebian設定をWiresharkでキャプチャした結果、この時点で応答が発生し、最終的に「PPP LCP設定の確認」が生成されることがわかりました。
私はもっと確認する必要があるかどうかは本当にわかりません。新しい設定でなぜPPTP接続が停止したのかわかりません。この問題を解決する方法についてのアイデアはありますか?
/etc/rc.local
注:完全なiptables設定を設定する方法は次のとおりです(両方のインストールと同じ)。
#!/bin/sh -e
echo "*** Running rc.local ***"
# First up, make sure 'net.ipv4.ip_forward=1' exists, uncommented, in /etc/sysctl.conf (just do this manually)
echo "MAKE SURE net.ipv4.ip_forward=1 EXISTS, UNCOMMENTED, IN /etc/sysctl.conf OR NAT WILL NOT WORK!!!"
echo ""
# Firewall variables
#WAN_IFACE="eth0" # At the time of writing, this is the NIC built into the mobo
WAN_IFACE="ppp0" # Virtual PPP interface when using PPPoE
LAN_IFACE="eth1" # At the time of writing, this is the extension NIC card
LAN_IP="192.168.1.1/24" # Class-C internal network
# Setup iptables... flush existing rules
iptables -F
iptables -t nat -F
set +e
# Set +e here to continue on error; iptables may give an error if this chain doesn't currently exist and we try to delete it
iptables -X LOGGING
set -e
# Set default policies for chains
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
# Allow all local loopback access
iptables -A INPUT -i lo -p all -j ACCEPT
iptables -A OUTPUT -o lo -p all -j ACCEPT
# Allow incoming traffic for established connections
iptables -A INPUT -i $WAN_IFACE -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $WAN_IFACE -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $LAN_IFACE -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $LAN_IFACE -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT
# Allow incoming ICMP traffic
iptables -A INPUT -p icmp -j ACCEPT
###
# Uncomment lines in this section to allow unsolicited incoming traffic on ports
## Open common service ports
## SSH
#iptables -A INPUT -i $WAN_IFACE -p tcp --destination-port 22 -j ACCEPT
## HTTP (8080 + 8081)
#iptables -A INPUT -i $WAN_IFACE -p tcp --destination-port 8080 -j ACCEPT
#iptables -A INPUT -i $WAN_IFACE -p tcp --destination-port 8081 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --destination-port 8080 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --destination-port 8081 -j ACCEPT
# DNS
iptables -A INPUT -i eth1 -p tcp --destination-port 53 -j ACCEPT
iptables -A INPUT -i eth1 -p udp --destination-port 53 -j ACCEPT
# Local Samba connections
iptables -A INPUT -p tcp --syn -s $LAN_IP --destination-port 139 -j ACCEPT
iptables -A INPUT -p tcp --syn -s $LAN_IP --destination-port 445 -j ACCEPT
###
# NAT setup - allow the NAT masquerading
iptables -t nat -A POSTROUTING -o $WAN_IFACE -j MASQUERADE
# Allow forwarding of packets between the Internet and local network interface(s)
iptables -A FORWARD -i $WAN_IFACE -o $LAN_IFACE -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $LAN_IFACE -o $WAN_IFACE -j ACCEPT
# Logging setup
iptables -N LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix="IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP
# Logging; uncomment the below to log dropped input packets to syslog (verbose; only use for debugging!)
echo "Uncomment the necessary lines in rc.local to enable iptables logging..."
#iptables -A INPUT -j LOGGING
echo "*** Finished running rc.local ***"
exit 0
修正する:
私はこれをさらに調査し、Linuxルーターの出力のWireshark分析で非常に重要な違いを明らかにしました。ここに2つのスクリーンショットがあります。 1つ目は、ルーティングが正常に動作する古いDebianボックスからのもので、2つ目は、ルーティングが機能しない新しいMintボックスからのものです。
私のLinuxルーターのパブリックIPアドレスとPPTPプロトコルを介してVPN接続を確立するために通信するリモートアドレスを示すために、IPアドレスを赤と青のストライプに置き換えました。また、ローカルネットワーク上のWindowsコンピュータのIPアドレスが緑色で強調表示されます。
注目すべきは、PPTPプロトコルが完了してPPP LCPパケットに切り替えられた後に何が起こるかです。 Debianシステムは、パケットをパブリックインターネットに送信する前に、これらのパケットの送信元アドレスを自分のパブリックIPアドレスに変換します。しかし、私のLinux Mintボックスでは、送信されたパケットのソースアドレスはまだ接続を試みるWindowsシステムのローカルネットワークアドレスのままです。ローカルクラスCソースアドレスを使用してパケットをインターネットに送信します。もちろん、パケットはルーティングされません!
問題は、私のLinux MintコンピュータではNATがクラッシュするが、Debianコンピュータではクラッシュしない原因は何ですか? iptablesは同じで、すべて/etc/network/interfaces
同じです。わかりません...しかし、おそらく、この発見はここで誰かが私がこれを見つけるのを助けるかもしれません。 :-)
答え1
NATが正しく機能するためには、プロトコル固有のヘルパーモジュールをロードする必要があります。デフォルトではTCPとUDPのみがロードされます。
これがNATなしでエスケープするPPTPトラフィック(実際にはGRE経由のPPP)を見る理由です。nf_nat_proto_gre
少なくともLinux 4.4以降、このモジュールがあります。
同様の状況が接続トレースに適用されます(この機能がないと、GREパケットは確立または関連付けられた接続の一部と見なされません)。それはnf_conntrack_proto_gre
。
PPTPにも特別な処理が必要であることがわかりました(PPPネゴシエーションにIPアドレスが含まれているようですが確認していません)。この特別な処理はで提供され、nf_nat_pptp
PPTP接続追跡はで提供されていますnf_conntrack_pptp
。
modprobe ip_nat_pptp
VPNが正しく機能するようにする必要があります。モジュール間の依存関係は、最終的に4つのモジュールすべてをロードします。起動時に動作をnf_nat_pptp
続けるには/etc/modules
。
(いいえ、この内容がどこで録音されたのかわかりません。申し訳ありません!)
答え2
DeRobertの答えは正しいです。しかし、最新のカーネルバージョンには別の問題があります。セキュリティ上の理由から、net.netfilter.nf_conntrack_helperのデフォルト値が0に変更されました。
関連トピックを参照してください。
- https://bugzilla.redhat.com/show_bug.cgi?id=1369489
- https://forum.configserver.com/viewtopic.php?t=10475
簡単な修正方法は、もう一度1に設定することです。 /etc/sysctl.confの下部に追加
net.netfilter.nf_conntrack_helper = 1
その後、再起動または実行します。sysctl -p