AWS Lightsail上でT-potは運用しないほうがいいという話
AWS Lightsail上でDebianのVMインスタンスを借りて、その上でT-potをインストールした。
最初の方はうまく動いていたのだが、１時間ぐらいするとVMが落ちる問題が発生。SSHはもちろんのことpingすら通らなくなる。AWSのWebIFからVMの再起動をかけると再び上がってくるが、また1時間ほど放置するとVMが落ちる。これでは使い物にならない。なお、AWS LightsailのWebIFはSSH経由なのでこうなってしまうとVMにアクセスする方法がなくなるので調査も面倒だった。再起動するしかない。これ使い勝手悪いよね。。。せめてシリアルポート経由にしてもらえないか？と思う。
ログやらなんやらを色々みて何が起こっているかはわかったので、誰かの役に立つかもしれないので一応書き残しておく。
まずAWS LightsailにはNATがある。VMが直接グローバルIPのセグメントにぶら下がってるわけではない。NATの後ろに隠れている。そんで、そのNATの内部のプライベートIPはDHCPで降ってくる。
で、このNAT内部のプライベートIPのリース期間が短い。3000sec前後しかないのである。したがってこのDHCPのIPリース期間が切れるとIPが剥奪されて一切の通信ができなくなるのである。これが落ちてた原因
dhclientのリース期間が切れたときは当然dhclientが再取得するはずだが、T-potインストール後の環境にはこのdhclientが常駐してない。だから再取得も行われるそのまま沈黙してしまう。
他のT-potをインストールしていないLightsailインスタンスには確かにdhclientが常駐している。T-potがインストール時にこの設定を消してしまうのだろう。
ところで、よくわかってないのだが、dhcpのリース期間を無限に設定してある自宅LAN環境のLinuxサーバではdhclientは常駐してない。リース期間が有限だとNetworkManagerあたりが自動的に立ち上げるのかしら？ここらへんは調べてもよくわからなかった。
じゃあdhclient起動すればいいんでしょ！ってんで手動でdhclientを立ち上げてみたらどうか？と思い。以下のコマンドを叩いた。
# dhclient -r -v eth0 && rm /var/lib/dhcp/dhclient.* ; dhclient -v eth0
すると、たしかに１時間たってもVMは落ちなくなった。
しかしまたもや問題発生。１時間ではVMは落ちなくなったが、今度は4時間後ぐらいにまたVMが落ちてしまう問題が発生した。時間が伸びただけでやっぱり落ちるのである。
Jul 01 01:52:45 rapidassistance dhclient[19188]: DHCPREQUEST for 172.26.3.244 on eth0 to 172.26.0.1 port 67 Jul 01 01:52:45 rapidassistance dhclient[19188]: DHCPACK of 172.26.3.244 from 172.26.0.1 Jul 01 02:18:04 rapidassistance dhclient[19188]: DHCPREQUEST for 172.26.3.244 on eth0 to 172.26.0.1 port 67 Jul 01 02:18:04 rapidassistance dhclient[19188]: DHCPACK of 172.26.3.244 from 172.26.0.1 Jul 01 02:44:37 rapidassistance dhclient[19188]: DHCPREQUEST for 172.26.3.244 on eth0 to 172.26.0.1 port 67 Jul 01 02:44:37 rapidassistance dhclient[19188]: DHCPACK of 172.26.3.244 from 172.26.0.1 Jul 01 03:08:46 rapidassistance dhclient[19188]: DHCPREQUEST for 172.26.3.244 on eth0 to 172.26.0.1 port 67 Jul 01 03:08:46 rapidassistance dhclient[19188]: DHCPACK of 172.26.3.244 from 172.26.0.1 Jul 01 03:27:39 rapidassistance dhclient[403]: Internet Systems Consortium DHCP Client 4.4.1 Jul 01 03:27:39 rapidassistance dhclient[403]: For info, please visit https://www.isc.org/software/dhcp/ Jul 01 03:27:39 rapidassistance dhclient[403]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 Jul 01 03:27:39 rapidassistance dhclient[403]: DHCPOFFER of 172.26.3.244 from 172.26.0.1 Jul 01 03:27:39 rapidassistance dhclient[403]: DHCPREQUEST for 172.26.3.244 on eth0 to 255.255.255.255 port 67 Jul 01 03:27:39 rapidassistance dhclient[403]: DHCPACK of 172.26.3.244 from 172.26.0.1 Jul 01 03:27:39 rapidassistance dhclient[428]: Internet Systems Consortium DHCP Client 4.4.1 Jul 01 03:27:39 rapidassistance sh[414]: Internet Systems Consortium DHCP Client 4.4.1 Jul 01 03:27:39 rapidassistance sh[414]: For info, please visit https://www.isc.org/software/dhcp/ Jul 01 03:27:39 rapidassistance dhclient[428]: For info, please visit https://www.isc.org/software/dhcp/ Jul 01 03:27:39 rapidassistance sh[414]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 Jul 01 03:27:39 rapidassistance sh[414]: DHCPOFFER of 172.26.3.244 from 172.26.0.1 Jul 01 03:27:39 rapidassistance sh[414]: DHCPREQUEST for 172.26.3.244 on eth0 to 255.255.255.255 port 67 Jul 01 03:27:39 rapidassistance sh[414]: DHCPACK of 172.26.3.244 from 172.26.0.1
ログをみると、Jul 01 03:27:39まではdhclientはご機嫌でIPのリースを更新してくれているようだが、それ以降ログが途切れている。誰かがNetworkManager周りに再起動をかけたのか？このとき、僕が手動で起動したdhclientも殺されてまたDHCPリースが切れたときにIPが消えて落ちているようだ。元の木阿弥である。
じゃあdhclientをsystemdで起動してWatchdogでプロセスが殺されても復活するようにすればいいのでは？とおもってsystemdのconfigを書いてdhclientを起動させた。。。
ところでどうやら何やら不味いことをやってしまったらしく、systemd start dhclient.serviceとやった瞬間VMが落ちた。すでにenableにした後だったのでAWSのWebIFから再起動をかけてもSSHにはつながらない。＼(^o^)／ｵﾜﾀ
AWSのWebIFはSSH経由での接続しかサポートしてないのでこうなってしまうとどうやってもVMにはアクセスできなくなるのでインスタンスを削除してOS再インストールからやり直しである。
ここで心が折れた。もうAWS Lightsail上でのT-pot運用は諦めることにする。。。これ以上は面倒くさいし不毛だ。。。
T-potはOSごと含めたISOイメージからのインストール手段も提供している。ので、EC2でインスタンスを借りて、ISOイメージからインストールしてみようかなと思う。
というわけでLightsailでT-potの運用は面倒くさいんでやめたほうがいいという結論になりました。
