オリジナル:
ルーターを古いLinuxインストール(Debian squeeze)から新しいインストール(Linux Mint 17.3)に切り替えました(ルーターとしてLinuxインストールを備えたフルデスクトップPCを使用しています)。 Linux PCはDSLモデムに直接接続し、PPPoE接続をネゴシエートしてから、他のすべてのデバイスのインターネット接続をルーティングします。
私の知る限り、前回のDebianインストールと同じように設定しました。私は単純なrc.local
スクリプトを使用してiptablesを設定しました。これは新しいボックスでも同じであり、実行されています(ルートコンソールから/etc/rc.local
を実行してこれを確認しました)。新しいボックスにもDNSを設定しました。
ほとんどの機能は同じように動作しますが、問題が1つあります。WindowsボックスのVPNが接続できなくなっています。 Wiresharkを見ると、最初のPPTP=パケットが正常に送受信されているように見えますが、Windowsボックスから送信された「Set-Link-Info」パケットがあり、 Windowsボックスが「PPP LCP構成要求」パケットの設定を開始します。この時点で、応答は受信されません。私の古いDebianセットアップを経由するWiresharkキャプチャは、その時点で応答があり、最終的には「PPP LCP構成確認」が発生することを示しました。
他に何をチェックすべきか本当にわかりません。 PPTP接続がここで新しい設定で止まっている理由がわかりません。トラブルシューティングの方法に関するアイデアはありますか?
注:iptables構成全体をセットアップする/etc/rc.local
は次のとおりです(両方のインストールで同じです)。
#!/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
UPDATE:
私はこれについてさらに調査を行っており、私のLinuxルーターによって何が出力されているかをWiresharkで分析したところ、非常に大きな違いが1つ明らかになっています。 2つのスクリーンショットがあります。1つはルーティングが機能する古いDebianボックスから、もう1つは機能しない新しいミントボックスからです。
LinuxルーターのパブリックIPアドレス、およびPPTPプロトコルを介してVPN接続を確立するために通信しているリモートアドレスを示すために、IPアドレスを赤と青のストライプに置き換えましたまた、ローカルネットワーク上のWindowsマシンのIPアドレスは緑色で示されています。
PPTPプロトコルが終了し、PPP LCPパケットに切り替えた後、何が起こるかがわかります。Debianボックスでは、ソースアドレスの変換が続行されます。これらのパケットをパブリックインターネットに送信する前に、パブリックIPアドレスに送信します。ただし、Linux Mintボックスでは、送信されるパケットの送信元アドレスは、接続を確立しようとしているWindowsマシンのローカルネットワークアドレスのままです。 。ローカルのクラスC送信元アドレスでインターネットにパケットを送信しています-もちろんそれらはルーティングされていません!
問題は、NATここに私のLinux MintボックスではDebianボックスでは発生しない)の内訳を引き起こしているものは何ですか?iptablesは同じですが、/etc/network/interfaces
は同じです。わかりません...しかし、この発見は、ここの誰かが問題を解決するのに役立つでしょう:-)
NATが機能するためには、プロトコル固有のヘルパーモジュールをロードする必要があります。デフォルトでは、TCPおよびUDPがロードされました。
PPTPトラフィック(実際にはPPP))がNATなしでエスケープするのはこのためです。そのモジュールは、少なくとも_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
_に追加します。
(いいえ、これがどこに文書化されているのかわかりません。申し訳ありません!)
デロベルトの答えは正しいです。しかし、新しいバージョンのカーネルでは、別の問題があります。net.netfilter.nf_conntrack_helperのデフォルト値は、セキュリティ上の理由から0に変更されています。
関連を参照してください:
簡単な修正は、もう一度1にすることです。 /etc/sysctl.confの下部に追加します
net.netfilter.nf_conntrack_helper = 1
その後、再起動します。