web-dev-qa-db-ja.com

手動IPルートが無効になる（ネットワークマネージャーによって？）

Debian JessieサーバーでIPルートを手動で作成している状況があり、最初に使用した後、動作を停止します。

私のネットワークには、192.168.2.0/24と192.168.1.0/24のサブネットがあります。これらはほとんど分離されています。ただし、Cisco RV325ルータでは、192.168.1。*ホストへの192.168.2。*トラフィックの例外を許可しています（ただし、その逆は許可していません）。これは、追加の構成なしで、192.168.2。*サブネット上の他のすべてのクライアント（MacOS、Win10）で正常に機能します。

しかし、192.168.2。* Debianサーバーでは、192.168.1。*ホストに到達できません。だから、私は手動で（Debianボックスに）ルートを追加してみました

root@debian$ route -v 
Kernel IP routing table 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
default         router          0.0.0.0         UG    1024   0        0 eth1
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

root@debian$ route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.1 metric 1

root@debian$ route -v
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         router          0.0.0.0         UG    1024   0        0 eth1
192.168.1.0     router          255.255.255.0   UG    1      0        0 eth1
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

この時点で、他の仮想LAN上のHTTPホストに正常に接続できます。

root@debian$ telnet 192.168.1.24 80
Trying 192.168.1.24...
Connected to 192.168.1.24.
Escape character is '^]'.

たとえば、手動でWebページを要求すると、コンテンツが返されます。その後、接続が閉じられ、以降の試行は失敗します。

Trying 192.168.1.24...
telnet: Unable to connect to remote Host: No route to Host

route -vはまだ追加したルートを示していますが、基本的に使用できません。ここで何が問題になっていますか？他のソフトウェアが、不正なルートであると考えているものを積極的にシャットダウンしている可能性がありますか？

私は この関連する質問 を見て、現在の3つの答えすべてを試しましたが、どれもうまくいきませんでした。

Network Managerを完全に無効にしようとしましたが、デフォルトルートが壊れてしまい、はるかに深刻な問題になりました。だから、私はこの質問を「Network Managerを備えたシステム上の別のサブネットにルートを追加する方法」として提起していますか？手動で、または起動時に自動的に、どちらも問題ありません。

更新

以下の質問ごとに、iptablesは次のことを示しています。

root@debian$ iptables -vnL
Chain INPUT (policy ACCEPT 5376 packets, 1052K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2490  184K fail2ban-ssh  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 22

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

Chain OUTPUT (policy ACCEPT 3041 packets, 1187K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain fail2ban-ssh (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   13  1016 REJECT     all  --  *      *       154.8.139.43         0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       192.99.122.172       0.0.0.0/0            reject-with icmp-port-unreachable
 2477  183K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

これらのIPはどれも関連性がないようです。質問をする前に、fail2banサービスを無効にしてみましたが効果はありませんでした。

ip addr debianホストのショー：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope Host lo
       valid_lft forever preferred_lft forever
2: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:26:55:db:36:fa brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:26:55:db:36:fb brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.34/24 brd 192.168.2.255 scope global eth1
       valid_lft forever preferred_lft forever

注：マシンに2番目のNIC（eth2）がありますが、プラグが抜かれ、ダウンしています。ルーティングテーブルに存在しません。

debianroutingdebian-jessienetworkmanager
1
Nate

これは、クライアントのルーティングの問題ではなく、ファイアウォールの問題またはサーバーの問題である可能性があります。

私の推測では、サーバーでのネットマスクが正しくないため（おそらく255.255.0.0で、かなり一般的です）、サーバーでのルーティングが正しくなく、クライアントでのリバースパスフィルタリングと組み合わされています。これを確認するには、たとえば、echo "1">/proc/sys/net/ipv4/conf/default/rp_filterのようなコマンドを使用して、クライアントでリバースパスフィルタリングを無効にします。ただし、解決策は、パケットがルーターに返送されていないため、サーバー。 （これには、「RELATED」トラフィックをルーターに戻すことを許可することも含まれる場合があります）。

それが失敗した場合は、iptablesルールを調べて、そこでブロックされているかどうかを確認します。iptables-vnLと入力すると、これらを確認できます。 （私たちが見るためにこれらを投稿することをお勧めします）。また、ルーターに関連している可能性もあり、おそらくNAT関連の問題ですらあります。

一般に、可能であれば、次のステップは、パケットスニッフィングを実行して、コンピューターから何が出て、Webサーバーとvvが何を受信して​​いるかを確認することです。次のようなコマンドでtcpdumpを使用できます（別のウィンドウでリクエストを行う）

tcpdump -n -i eth1 tcp src or dst 192.168.1.24

（追加したrouteコマンドは冗長であり、その目的を誤解していると思われます。これは問題の原因ではありません。問題がリバースパスフィルタリングに関連している場合は、ルーターを一緒にバイパスできる可能性があります。 route add -net 192.168.1.0 netmask 255.255.255.0 eth1）のようなコマンド

1
davidgo