ラベル Network の投稿を表示しています。 すべての投稿を表示
ラベル Network の投稿を表示しています。 すべての投稿を表示

2021年10月19日火曜日

要塞(Bastion)を使ってプライベート・ネットワーク上のコンピュート・インスタンスに接続する

 要塞(Bastion)を使って、プライベート・ネットワークにあるコンピュート・インスタンスに接続する方法を記述します。

以下の記述では、コンパートメント名MyAPEXDomain、仮想クラウド・ネットワークの名前もコンパートメント名と同じくMyAPEXDomain、その中に作成されているプライベート・ネットワークの名前がPrivate Subnet-MyAPEXDomainであると仮定します。記事中のそれらの名称は、それぞれの環境に合わせて読み直す必要があります。接続先となるコンピュート・インスタンスの名前はCMORDS1としています。

コンパートメント名と仮想クラウド・ネットワークに同じ名前MyAPEXDomainが付けられています。そのため、説明が若干わかりにくくなってしまいました。

要塞(Bastion)を作成する


Identity & Security要塞を開きます。要塞の作成をクリックします。

要塞名Bastion1とします。ネットワーキングの構成MyAPEXDomainのターゲット仮想クラウド・ネットワーク(このMyAPEXDomainはコンパートメント名)としてMyAPEXDomain(このMyAPEXDomainはVCNの名前)、MyAPEXDomainのターゲット・サブネットとして、接続するコンピュート・インスタンスが配置されているサブネットを選択します。ここではPrivate Subnet-MyAPEXDomainを選択しています。CIDRブロック許可リストには0.0.0.0/0を指定します。とりあえず、ネットワークのどこからでも要塞に接続できるようにしています。

CIDRブロック許可リストとして0.0.0.0/0を入力した後にEnterを入力すると0.0.0.0/0の入力が確定します。

要塞の作成をクリックします。

Bastion1状態アクティブになると、要塞の完成です。


コンピュート・インスタンスへファイルをアップロードする


要塞(Bastion)を通して、ファイルをコンピュート・インスタンスへアップロードします。そのために、要塞にてSSHポート転送セッションを作成します。

Identity & Security要塞のページを開きます。作成済みの要塞Bastion1を開きます。


Bastion1にて、セッションの作成をクリックします。


 ドロワーが開きます。セッション・タイプとしてSSHポート転送セッションを選びます。セッション名Session-年月日-時刻となるので、それはそのまま使います。作成したセッションの有効期間はデフォルトで3時間なので、セッション名から有効期間が分かります。ターゲット・ホストに接続する指定としてインスタンス名を使うように選択し、接続先となるコンピュート・インスタンスを指定します。今回はCMORDS1を指定しています。SSHのポート番号である22を転送先に選択します。

SSHキーの追加としてSSHキー・ファイルの選択を選び、コンピュート・インスタンスCMORDS1を指定または生成した公開鍵ファイル(スクリーンショットではssh-key-cmords1.key.pubというファイルを指定しています)をSSHキーとして指定します。

以上を設定して、セッションの作成をクリックします。


作成されたセッションが要塞の画面に一覧されます。


セッションの右端にあるハンバーガー・メニューを開き、SSHコマンドの表示を実行します。


SSH接続を確立するためのSSHコマンドが表示されます。クリップ・ボードにコピーし、ダイアログを閉じます


コピーしたsshコマンドは以下のような形式になります。

ssh -i <privateKey> -N -L <localPort>:10.0.1.82:22 -p 22 ocid1.bastionsession.oc1.ap-tokyo-1.amaaaaaawzoefcia4dtbwg5kixkgv3ixgsupn2625puytgcsvk6dyrch27bq@host.bastion.ap-tokyo-1.oci.oraclecloud.com


このコマンドに含まれる<privateKey><localPort>の部分を置き換えます。要塞のOCIDやホスト名は適切な値が入っているので変更はしません。秘密キーのファイルは、セッションの作成時に与えた証明書(公開鍵)と対になる秘密キーになります(ここではssh-key-cmords1.keyとしています)。ローカル・ポートとして10022を使うことにすると、上記のコマンドは次のようになります。

ssh -i ssh-key-cmords1.key -N -L 10022:10.0.1.82:22 -p 22 ocid1.bastionsession.oc1.ap-tokyo-1.amaaaaaawzoefcia4dtbwg5kixkgv3ixgsupn2625puytgcsvk6dyrch27bq@host.bastion.ap-tokyo-1.oci.oraclecloud.com



上記コマンドは実行したままにしておきます。

別のターミナルよりファイルのアップロードを実行します。sftpコマンドでローカルのポートである10022に接続し、putコマンドを実行します。以下の実行例ではWallet_APEXDEV.zipおよびapexugj.dev.zipというファイルをアップロードしています。

sftp -i ssh-key-cmords1.key -P 10022 opc@localhost

Connected to localhost.

sftp> put Wallet_APEXDEV.zip

Uploading Wallet_APEXDEV.zip to /home/opc/Wallet_APEXDEV.zip

Wallet_APEXDEV.zip                            100%   21KB   1.3MB/s   00:00    

sftp> put apexugj.dev.zip

Uploading apexugj.dev.zip to /home/opc/apexugj.dev.zip

apexugj.dev.zip                               100% 6762   752.1KB/s   00:00    

sftp> exit

% 


以上で、ファイルがユーザーopcのホーム・ディレクトリにアップロードされました。

これ以上アップロードするファイルがなければ、ポート転送を行なっているsshコマンドは終了できます。

コンピュート・インスタンスへSSHで接続する


SSHでコンピュート・インスタンスに接続します。今度は要塞で管理対象SSHセッションを作成します。要塞Bastion1を開き、セッションの作成を実行します。

セッション・タイプとして管理対象SSHセッションユーザー名opcを指定する以外は、先ほどのポート転送セッションと同様の設定を行い、セッションの作成をクリックします。


セッションが作成されたら右端のハンバーガー・メニューを開き、SSHコマンドのコピーを実行します。


以下のようなsshコマンドがコピーされます。

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.ap-tokyo-1.amaaaaaawzoefciakq7z6smcwfodqn2ebveyeca7z7brmbn2dfgdmpox4dyq@host.bastion.ap-tokyo-1.oci.oraclecloud.com" -p 22 opc@10.0.1.82


<privateKey>の部分を秘密キーのファイル名に置き換え、sshコマンドを実行します。

ssh -i ssh-key-cmords1.key -o ProxyCommand="ssh -i ssh-key-cmords1.key -W %h:%p -p 22 ocid1.bastionsession.oc1.ap-tokyo-1.amaaaaaawzoefciakq7z6smcwfodqn2ebveyeca7z7brmbn2dfgdmpox4dyq@host.bastion.ap-tokyo-1.oci.oraclecloud.com" -p 22 opc@10.0.1.82

The authenticity of host '10.0.1.82 (<no hostip for proxy command>)' can't be established.

ECDSA key fingerprint is SHA256:oTItIYbGj7E26UZlk2dcXFqcBeZ5GXGUVbJXyn+IkJY.

Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

Warning: Permanently added '10.0.1.82' (ECDSA) to the list of known hosts.

Activate the web console with: systemctl enable --now cockpit.socket


[opc@cmords1 ~]$ 


初回接続時はfingerprintをknown_hostsファイルに追加するかどうか確認を求められます。yesを入力すると宛先のコンピュート・インスタンスに接続されます。

以上で要塞を使って使ってプライベート・ネットワーク上のコンピュート・インスタンスに接続する方法の記事は終了です。

Oracle APEXをOracle Cloud上で構成する際の参考になれば幸いです。

ロード・バランサの割り当て制限をAlways Freeの範囲にする

 Oracle CloudのAlways Free Cloud Servicesとして、Flexible Load Balancerが含まれています。

https://www.oracle.com/jp/cloud/free/#always-free


シェイプとして動的シェイプを選び、合計帯域幅の選択マイクロを指定してロード・バランサを作成したところ、課金されました


そのためロード・バランサを一旦削除して、異なるシェイプでロード・バランサを作成し直すことにしました。

シェイプフレキシブル・シェイプにし、最小帯域幅の選択最大帯域幅の選択を両方とも10Mbpsに変更して、ロード・バランサを作成しました。


Free Tierアカウント(アップグレードされていないアカウント)で作成できるロード・バランサは上記の設定に限定されています。

Free Tierアカウントでのロード・バランサのリソース制限を確認してみます。

ガバナンス制限、割当ておよび使用状況を開きます。サービスとしてLBaaSを選択します。スコープにはホーム・リージョンコンパートメントとしてルート・コンパートメントを選択します。


Free Tierアカウントでは、Flexible LB bandwidth total sum10Flexible Load Balancer Count1に制限されていることがわかります。それ以外はすべて0です。

アップグレードされたアカウントを確認してみます。ガバナンス制限、割当ておよび使用状況を開きます。サービス制限が緩和されています。


このサービス制限をAlways Freeに一致させます。

割当て制限ポリシーとして以下を設定します。ルート・コンパートメント名はそれぞれの環境に合わせて変更します。lb-flexible-bandwidth-sum10lb-flexible-count1とし、それ以外は0にします。
Set load-balancer quota lb-10mbps-micro-count to 0 in compartment [ルート・コンパートメント名]
Set load-balancer quota lb-10mbps-count to 0 in compartment [ルート・コンパートメント名]
Set load-balancer quota lb-100mbps-count to 0 in compartment [ルート・コンパートメント名]
Set load-balancer quota lb-400mbps-count to 0 in compartment [ルート・コンパートメント名]
Set load-balancer quota lb-flexible-bandwidth-sum to 10 in compartment [ルート・コンパートメント名]
Set load-balancer quota lb-flexible-count to 1 in compartment [ルート・コンパートメント名]
ガバナンス割当て制限ポリシーを開きます。割当て制限の作成をクリックします。


割当て制限ポリシーの作成として、名前AlwaysFreeLBaaS説明Always Freeの範囲内に制限とします。割当て制限ポリシーには前出の設定を、ルート・コンパートメント名を置き換えた上で記述します。割当て制限ポリシーの作成をクリックします。


割当て制限ポリシーが作成されます。


割当て制限ポリシーの画面に戻ります。


制限、割当ておよび使用状況を再度確認してみます。


Flexible LB bandwidth total sum使用可能10Flexible Load Balancer Count使用可能1になっています。それ以外はすべて0で、割当て制限ポリシーにて指定した値になっていることが確認できます。

Always Freeの範囲で割当て制限をかけているため、ロード・バランサで課金が発生することは避けられます。Always Freeの範囲でロード・バランサを作成すると、制限、割当ておよび使用状況は以下のようになりました。


課金が発生した設定でロード・バランサを作成し、制限を確認してみます。ロード・バランサの作成画面で、動的シェイプマイクロを選択します。


ロード・バランサのシェイプについてさらに学習するのリンクを開いて内容を確認すると、動的シェイプはwhich is only available to certain legacy customer accountsとなっており、利用に制限がかかっていること、You can also select the Always Free option if you have not used your one free tier accountとあり、アップグレードしたアカウントの場合はAlways Freeオプションを選択する必要がある(実際にはAlways Freeのオプションは無くなっています)と記載されています。

ロード・バランサの作成に必要な設定をすべて行い、最終的に送信するとlb-10mbps-countの制限を超えているので作成できない、とエラーが発生します。このシェイプはAlways Freeの対象ではないため、作成すると課金は発生します。Always Freeのオプションを選択していれば、lb-10mbps-micro-countのシェイプでロード・バランサが作成されたのだろうと予想されます。


最近、Oracle Cloudのアカウントを作成したユーザーには、そもそも動的シェイプが選択できないのかもしれません。動的シェイプが選択できる場合でも、選択しない方が良いように思います。コスト・エスティメータを使った予測の仕方が不明です。


今のところLoad Balancer Count(lb-flexible-count)が1、Flexible LB bandwidth total sum(lb-flexible-bandwidth-sum)が10の使用量で課金が発生していないことは確認していますが、お金に関することなので懸念がある場合は正式にベンダーに確認するのがよいでしょう。