質問: 手動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)がありますが、プラグが抜かれ、ダウンしています。ルーティングテーブルに存在しません。
回答: これは、クライアントのルーティングの問題ではなく、ファイアウォールの問題またはサーバーの問題である可能性があります。私の推測では、サーバーでのネットマスクが正しくないため(おそらく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)のようなコマンド