【体験談】本社のメイン回線切替をおこなってみた！

この記事は アイソルート Advent Calendar 3日目の記事です。

こんにちはこんばんは、

プラットフォームソリューショングループでネットワークエンジニアをしているtahara.hです。

最近、わたしたちアイソルート本社のメイン回線を切り替えました！

企業のメイン回線を切り替えるのは色々と大変で

今回はその際におこなった手順や考慮点を紹介したいと思います。

アジェンダ

1. 背景と既存構成と問題点
2. 切り替え方式
3. PPPoEとIPoEのお話
4. いざっ！切り替え
5. 切り替え後は？
6. あとがき

背景と既存構成と問題点

弊社では、とあるプロバイダーを長年利用していたのですが、

オフィス移転などで環境が変わり、ピーク時のスループット低下が問題となっていました。

そのため今回、スループットに定評のあるプロバイダーへメイン回線の切り替えを実施するプロジェクトが発足しました。

既存のネットワーク構成概要としては、

本社と各拠点をインターネットVPNとして接続し、ハブ＆スポーク型での構成をとっています。

今回の回線切替において一番の問題は、

プロバイダーが変更になるためグローバルIPが必ず変更になり、

その結果、「インターネットVPNのハブ側（本社）のグローバルIPが変わる」ことでした。

各拠点へのVPNルータに対しては、VPN経由でのみしかアクセスができないため

グローバルIPが変更となるとVPNルーターへアクセスができません。

切り替え当日、各拠点それぞれにVPNルータの設定変更要員を準備できれば安全に切り替えることは可能ですが、

人とお金と時間の観点から現実的では無いプランでした。

• 補足
  • 「グローバルIPアドレス」とは、インターネット上の住所の事
  • 「プロバイダーが変更になる」とは、インターネット上の地域が別の地域へ移動するようなイメージ（利便性のいい地域の方がいいよねという感じ）
  • 今いる地域から引っ越しをする訳なので、プロバイダー変更が伴う回線切替は大変なのです！（力強）

切り替え方式

上記のため、安全性を考慮して方式としては以下のような方式を取りました。

1. 各拠点のVPNルータの管理アクセスを、旧本社のグローバルIPアドレスから”のみ”SSH接続許可設定とする
2. 本社メイン回線切り替え後、旧回線に対して暫定ブロードバンドルータを設置し、旧本社グローバルIPアドレスから各拠点のVPNルータを設定変更をおこなう
3. 各拠点のVPN設定変更完了後、各拠点のVPNルーターに設定されている旧本社グローバルIPアドレス”のみ”SSH接続許可設定を削除する

一時的にインターネット上から各拠点へ接続を可能とし、

接続をおこなえるグローバルIPアドレスとしては、

切り替え前の旧本社のグローバルIPと絞ることで

セキュア且つ切替時も各拠点への管理アクセスが可能とする状況を取るようにしました。

• 補足
  • 弊社ではVPNルーターにSRXを用いているのですが、SRXの管理アクセスの制限は以下のような形で制御が可能です
    例） 「10.0.0.0/8」を許可する場合

    set policy-options prefix-list manager-ip 10.0.0.0/8
    set firewall filter manager-ip term block_non_manager from source-address 0.0.0.0/0
    set firewall filter manager-ip term block_non_manager from source-prefix-list manager-ip except
    set firewall filter manager-ip term block_non_manager from protocol tcp
    set firewall filter manager-ip term block_non_manager from destination-port ssh
    set firewall filter manager-ip term block_non_manager from destination-port https
    set firewall filter manager-ip term block_non_manager from destination-port telnet
    set firewall filter manager-ip term block_non_manager from destination-port http
    set firewall filter manager-ip term block_non_manager then discard
    set firewall filter manager-ip term accept_everything_else then accept
    set interfaces lo0 unit 0 family inet filter input manager-ip
    

    https://www.juniper.net/documentation/en_US/junos/topics/example/permitted-ip-configuring.html

PPPoEとIPoEのお話

ここでインターネットへ接続する時のお話をしておきます。

インターネットへ接続する場合「PPPoE」というプロバイダーから払い出される認証情報の設定をおこないます。

ただし、最近はPPPoEではなく「IPoE」を利用できるプロバイダーも増えており

今回切り替えをおこなったプロバイダーもPPPoEではなくIPoEを利用して接続を行う仕様となっています。

PPPoEの問題点としては、

プロバイダー内で利用ユーザが増えてくると、PPPoEを終端する機器で輻輳が発生し速度低下を引き起こす要因の一つとなることがあります。

今回、新規プロバイダーに切り替えることによってIPoEとなり、速度低下を引き起こす要因の一つが回避されることとなります。

いざっ！切り替え

っといきたいところですが、メイン回線ですのでもう少し考慮が必要です。

1つ目は「DNSサーバ」についてです。

社内にDNSキャッシュサーバ（フォワーダ）がいる場合、そのDNSフォワード先はプロバイダーのフルサービスリゾルバに向いていることが多いのではないでしょうか。

プロバイダーのDNSの多くは、自分のプロバイダー内からのDNSリクエストは受け付けますが、別のプロバイダーからのDNSリクエストはドロップすることが多いです。

今回の切り替えのケースもプロバイダーのDNSとなっていたため、これを機にDNSフォワード先をパブリックDNSへの変更をおこないました。

＃パブリックDNSについては、セキュリティリスクや利用用途によっては不具合を生むケースがありますので、導入の際は慎重に検討をしましょう。

2つ目は「グローバルIPを利用したアクセス制限をかけている」点についてです。

以下の様なケースがあります。

• クラウドサービスの管理アクセスを許可するソースグローバルIP制限
• 取引先のお客様システムへ接続をおこなうソースグローバルIP制限 　etc…

この問題は「棚卸し」「追加登録調整」と時間と労力がかかります。地道にがんばりましょう。。。。

今回の切り替えでは、切り替え後も旧本社グローバルIPを利用できる環境を準備し、移行に時間がかかるものはそちらで対応する方針を取りました。

ここまできたら、回線切替です！

実際の作業はスムーズに切り替えを実施し、ノントラブルで切り替え作業は無事完了致しました。

切り替え後は？

速度測定は、Netflixが提供している「Fast.com」を切り替え前後で測定し確認を行いました。

https://fast.com

結果としては、

切り替え前と比べて「323% 」（約3倍）のスループット向上を確認致しました！

”早”！

あとがき

今回は、プロバイダー変更を伴う回線切り替えのお話をしました。

本記事が少しでも参考になればと思います。

”早”く携帯番号のナンバーポータビリティーの様にキャリア間のグローバルIPの付け替えが出来ない様にならないものかと思いを馳せながら、

”早”くなった回線でサクサクAWSのイベント動画を見てるけど、

”早”く家に帰らなきゃと思う今日この頃のtaharaでした。

おしまい

明日は、hikone.kさんの「バックオフィスから信頼されるエンジニアは多分エンジニアからも信頼される」です。

お楽しみに！

クラウドインテグレーション・インフラ構築/運用のご相談は「アイソルート」へ