3
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【戒め】インターネット無料賃貸でサーバ運用するときは個別にLANを分けてください。

Last updated at Posted at 2024-05-16

はじめに

タイトルの通りではありますが、
自宅でサーバーを運用している人、これから運用しようと思っている人に向けて、これだけは言わせてください。
インターネット無料賃貸で自宅サーバを飼う場合は、必ず個別にLANを分けてください。

本記事は私の実体験に基づき、LANを分けないことの危険性を伝えるものです。
既にお伝えしたい意図が分かった方は、読まなくてもたぶん大丈夫です…。

なお、筆者のネットワークに関する知識が乏しいため、
専門のネットワークエンジニアの方々からは「常識やろ…」とか「え?これ違くない?」と思われるような内容が含まれる可能性があります。
そのため内容に不備があれば、暖かくご指摘いただけると幸いです。

1.事件発生前のネットワーク構成について

まず、筆者は23年末頃まで以下のような構成で自宅サーバーを運用していました。
初学者にありがちな、足りないLANポートをとりあえずハブで増やして補っている感じですね。

local-network.png

LANのCIDRは共有ルーター側で設定されており、172.16.XX.XX/XXで、いわゆるクラスBの範囲で設定されていました。
また、ローカルIPは共有ルーターのDHCP機能で管理されており、サーバーのIPを固定したいからといって、当然ながら共有ルーターをいじることはできません。

そのためLAN内から適当に空いているIPアドレスを見繕って、
以下のようにサーバー側の設定ファイルでIPアドレスを固定していました。
さらに今考えるとマジであり得ないですが、この状態でkubernetesクラスタを構築していました。

ローカルIP 設定ファイル (/etc/netplan/xx-netcfg.yaml)
network:
  version: 2
    ethernets:
      enp2s0:                         // NIC名 
        addresses: [172.16.XX.XX/24]  // サーバのIPアドレス
        gateway4: 172.16.XX.XX        // ゲートウェイ
        nameservers:
          addresses: [172.16.XX.XX]   // DNSサーバ
          search: []
        optional: true

はい、もうお気づきの方もいるかと思いますが、
この状態ではローカルIPが自動的に変わる可能性があります。

何故ならLAN内のCIDR/IPは共有ルーター側で管理されているのですから...。

2.何が起きたか

そして23年末頃、事件は起きました。

いつものようにノートPCからkubernetesのお世話をしようとしたところ、
kubectlコマンドがエラーになります。

kubectl エラー
$ kubectl get node
Unable to connect to the server: dial tcp 172.16.XX.XX:6443: connect: no route to host

そしてサーバーにSSHで繋ぐこともできません。

ssh エラー
$ ssh -i ~/.ssh/id_rsa ubuntu@172.16.XX.XX
ssh: connect to host 172.16.XX.XX port 22: Connection timed out

仕方なく各サーバーにモニターをつないで直接ログインしたところ、ローカルIPアドレスが変わっていることに気づきました。
さらにLAN自体のCIDRが10.XX.XX.XX/XXとなっておりクラス単位で変更されていました、そりゃ疎通できないっすよね...。

変更前:172.16.XX.XX/XX
変更後:10.XX.XX.XX/XX

なお、CIDR単位で変更が入った理由は未だに謎のままですが、
今思えば当時賃貸の管理会社が変わっていたので、それに起因するのかもしれません…。

3.事件発生後のネットワーク構成について

こうして今更ながら、LANを分けて個別にローカルIPを管理する必要性に気づきました。
方法はいくつか考えられますが、大まかに以下のどちらかになるでしょう。

  • DHCPサーバを共有ルーターの間に挟む
  • DHCP機能付きのルーターを共有ルーターの間に挟む

DHCP用にサーバーを立てるのはリソース的にもったいないし、そもそもサーバー空きがないなぁ。
と思った筆者はDHCP機能付きのルーターをしぶしぶ購入しました。
別に筆者と同じ製品を買う必要はないですが、念のため買ったものを載せておきます。
VPNを使う予定がないのに何故VPNルーターを買ったのかは謎です...。

そして結果的に以下の構成に変更しました。
Myルーターは共有ルーターの管理下に置き、
個別にLANを192.168.XX.XX/XXで切り、この中をMyルーターのDHCP機能で個別にIP管理をしています。
またMyルーター側でMACアドレスを指定してIPを固定化できたため、各サーバー側での設定は不要となりました。
local-network-after.png

これでとりあえず共有ルーター側でLANのCIDRが変更になっても、
Myルーター内のLANのCIDRと被らない限りは、たぶん大丈夫な状態になりました。
100%安全なわけではないですが、これ以上の確実性を求めると個別に回線を引くことになるので、いったんはこれで大丈夫でしょう...。たぶん...。

4.最後に

記事は以上になります、お読みいただきありがとうございました。
きっと皆さんにもインターネット無料賃貸でサーバー運用する際にLANを分ける重要性が分かっていただけたかと思います。

また全然関係ない話ですが、本記事の画像はいらすとやを利用しており、
記事作成の過程で笑えるものを見つけたので共有します。
こういうどこに需要があるかわからない画像があるのがいいですよねぇ…。

3
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?