☰

リモートSSHログインが機能しない

tag-icon • tag-icon ssh iptables openvpn
リモートSSHログインが機能しない

SSHポート22へのポート転送が設定されているルータの背後にコンピュータがあり、完全に動作します。ログインしてすべての操作を実行できます。私が望むのは、このコンピュータをVPNに接続し、ローカルネットワークまたはVPN接続（インターネットアクセス用）を介したトラフィックのみを許可することです。これも素晴らしい作品です。 VPN 接続が失われると、PC をインターネットに接続できません。これでIPTABLESを使用してこれを行っています。問題は、ルータポート転送を介して外部ソースから着信SSHを取得できないことです。ローカルネットワーク内からコンピュータにSSH経由で接続できます。

私が試したことは次のとおりです。

# Allow traffic to VPN SERVER
sudo iptables -A INPUT -s $REMOTE_IP -j ACCEPT

# Allow ssh traffic
iptables -A INPUT -i eth1 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT    
iptables -A OUTPUT -o eth1 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

# Allow local traffic.
sudo iptables -A INPUT -s 10.0.0.0/8 -j ACCEPT
sudo iptables -A INPUT -s 172.16.0.0/12 -j ACCEPT
sudo iptables -A INPUT -s 192.168.0.0/16 -j ACCEPT

# Disallow everything else.
sudo iptables -A INPUT ! -i tun+ -j DROP

# Allow traffic from VPN SERVER.
sudo iptables -A OUTPUT -d $REMOTE_IP -j ACCEPT

# Allow local traffic.
sudo iptables -A OUTPUT -d 10.0.0.0/8 -j ACCEPT
sudo iptables -A OUTPUT -d 172.16.0.0/12 -j ACCEPT
sudo iptables -A OUTPUT -d 192.168.0.0/16 -j ACCEPT

# Disallow everything else.
sudo iptables -A OUTPUT ! -o tun+ -j DROP

sudo openvpn --config client.cfg --auth-user-pass client.cred --daemon

これは私のiptables -vL -n出力です。 （VPNサーバーをXX.XX.XX.XXに交換）

Chain INPUT (policy ACCEPT 25674 packets, 4792K bytes)
 pkts bytes target     prot opt in     out     source               destination         
78848   11M ACCEPT     all  --  *      *       XXX.XXX.XXX.XXX      0.0.0.0/0           
 3176  318K ACCEPT     tcp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 state NEW,ESTABLISHED 
    0     0 ACCEPT     all  --  *      *       10.0.0.0/8           0.0.0.0/0           
    0     0 ACCEPT     all  --  *      *       172.16.0.0/12        0.0.0.0/0           
 2517  231K ACCEPT     all  --  *      *       192.168.0.0/16       0.0.0.0/0           
   35 12374 DROP       all  --  !tun+  *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 32187 packets, 4374K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 3681 2443K ACCEPT     tcp  --  *      eth1    0.0.0.0/0            0.0.0.0/0           tcp spt:22 state ESTABLISHED 
70697   10M ACCEPT     all  --  *      *       0.0.0.0/0            XXX.XXX.XXX.XXX      
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            10.0.0.0/8          
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            172.16.0.0/12       
   27  5787 ACCEPT     all  --  *      *       0.0.0.0/0            192.168.0.0/16      
 2265  150K DROP       all  --  *      !tun+   0.0.0.0/0            0.0.0.0/0

はい、ifconfigを実行すると、eth1のみがあり、eth0はないため、そうではありません。

これもnetstat -rnの出力です。

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         XX.XXX.242.128  128.0.0.0       UG        0 0          0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth1
XX.XXX.193.107  192.168.1.1     255.255.255.255 UGH       0 0          0 eth1
XX.XXX.242.0    0.0.0.0         255.255.255.0   U         0 0          0 tun0
128.0.0.0       XX.XXX.242.128  128.0.0.0       UG        0 0          0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1

答え1

Penguin359が正しく言ったように、問題はリターンパケットがローカルルータを経由せずにVPNを介してルーティングされることです（受信接続はローカルルータから来ます）。ルータのSNATが1つのソリューションですが、これが可能でない場合は、PCで高度なルーティングを使用できます。

既存のiptablesルールに加えて、次の高度なルーティングルールを追加する必要があります。

ip rule add from 192.168.1.X table 128
ip route add table 128 to 192.168.1.0/24 dev eth1
ip route add table 128 default via 192.168.1.1

192.168.1.XをPCのLAN IPアドレスに置き換えます。 192.168.1.1 は LAN のルータ、192.168.1.0/24 は LAN のサブネットです。

最初のコマンドは、ソースアドレスが192.168.1.Xのすべてのパケットが次を使用するようにルールを作成します。特別なルーティングテーブル番号は128です。次の2つのコマンドは、デフォルトゲートウェイがルーター（デフォルトのルーティングテーブルのVPNサーバーではない）であるルーティングテーブル128を作成します。

送信元アドレスが192.168.1.Xの唯一のパケットは、ルータからの着信接続（つまり、ポート転送SSH接続）とLAN宛てのパケットに応答するパケットです。これは VPN で不要なパケットです。他のすべての発信パケットは異なる送信元アドレスを持ち、VPN を介してルーティングするデフォルトのルーティングテーブルを使用します。

答え2

明確に言えば、VPNの実行中に外部ソースのSSHは中断されますが、VPNが実行される前にすべてのソースのSSHが正常に動作します。問題はルーティングテーブルにあります。上記のように、デフォルトパス（0.0.0.0）はに移動しますtun0。私は興味深いネットマスクが何をしているのかわかりませんが、これは128.0.0.01-126で始まる外部アドレスを使用しますtun0。 SSH を使用すると、着信パケットがどこから来るかは重要ではなく、発信パケットはルーティング テーブルの一致する場所からのみ出ます。私はこの奇妙な構成を直接試しました。この種の問題に対する標準的な解決策は、着信SNATルールを使用して、着信パケットの送信元アドレスをルータの内部IPv4アドレスに変更することです。これはPCへの内部接続として表示され、上記のルーティングテーブルのローカル宛先に存在するため、ルータに再ルーティングされます。その後、ルータはSNATを逆転させ、すべての邪悪なハッカーが匂いを嗅ぎ、刺すように野生に送り返します。規制に従って、SNATはiptablesネットワーク内のPCではなくルーターに存在する必要があります。通常のLinksys WRTルーターなどを使用している場合は、ファイアウォール/ NATルールを制御するためにOpenWRTまたは同様のルーターをインストールする必要があります。

関連情報