一部のLinux VM(クラウドベース、複数のプロバイダ、主にUbuntu 14.04および16.04)で奇妙なネットワーク動作が発生しています。間にStrongswanゲートウェイを持つ2つの異なるネットワークがあります。
サイトA:ネットワーク - プライマリルータに設定されている10.104.16.0/20 VPNゲートウェイとルーティング(VMには設定は不要)
サイトB:ネットワーク - 10.240.132.0/25 Strongswan Gateway - 10.240.132.15サイトAと通信するために、必要に応じて各仮想マシンへのパスを設定します。
サイトA仮想マシンと通信する必要があるサイトBの仮想マシンの1つにあるカーネルルーティングテーブル:
# route -vn
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.240.132.1 0.0.0.0 UG 0 0 0 eth0
10.104.16.0 10.240.132.15 255.255.240.0 UG 0 0 0 eth0
10.240.132.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
これで問題は次のとおりです。すべてが正常な場合、VMはサイトAのVMにpingを送信し、これはTracerouteコマンドの出力です。
# traceroute 10.104.19.4
traceroute to 10.104.19.4 (10.104.19.4), 30 hops max, 60 byte packets
1 10.240.132.15 (10.240.132.15) 0.248 ms 0.228 ms 0.220 ms
2 * * *
3 10.104.19.4 (10.104.19.4) 15.048 ms 15.042 ms 15.028 ms
その後、突然仮想マシンはサイトAリソースをpingできなくなり、Tracerouteの出力は次のようになります。
# traceroute 10.104.19.4
traceroute to 10.104.19.4 (10.104.19.4), 30 hops max, 60 byte packets
1 10.104.19.4 (10.104.19.4) 0.552 ms 0.567 ms 0.616 ms
2 * 10.104.19.4 (10.104.19.4) 0.659 ms 0.707 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *^C
完全にランダムに見えます。結局のところ、これが起こった場合は、パスを削除してもう一度追加します。
# route del -net 10.104.16.0 gw 10.240.132.15 netmask 255.255.240.0
# route add -net 10.104.16.0 gw 10.240.132.15 netmask 255.255.240.0
もちろん、これは問題を一時的に解決しますが、長続きしません。何が間違っているのか、何が間違っているのか知っていますか?
ありがとうございます;)
答え1
わかりました、気にしないでください...正確に5分ごとに午前9時、午前9時5分、午前9時10分に接続が切断されることに気づいた後... 。サービスを再開するには:指定された時間(プロセスはSIGKILLコマンドを受け取ります)
私たちは船長と話を交わし、彼は言った。
さて、Strongswanサーバーには、リモートIPをpingしてリモートIPが見つからない場合は、サービスを再起動するcronジョブがあるかもしれません。
もちろん。そして、そのリモートIPはずっと前に消え、この文書化されていない操作を無効にしたり更新したりする人がいなかったため、サービスは最初から再開されました。 Postgresデータベースをコピーするときにこの問題を発見するまでです。