Coursera の Networking in Google Cloud: Defining and Implementing Networks を学んだ。

個人的なメモです。

# 前書き

courseraの[Networking in Google Cloud](https://www.coursera.org/professional-certificates/google-cloud-networking)は、以下のコースを含む

1. Defining and Implementing Networks (このページでメモを取る)
1. Hybrid Connectivity and Network Management
1. Hands-On Labs in Google Cloud for Networking Engineers




# [1]Basics

## VPC network(以下network)とsubnet

- １つのプロジェクトは複数のネットワークを持ちうる。ネットワークはregionをまたげる。**同一ネットワーク内なら、internal IPアドレス指定でやりとりできる**。
    - ネットワークを跨いだとしても、GCP間の通信なら(実はインターネットを経由せず)google edge router経由で external IPアドレス指定でやりとりしている。
- デフォでsubnetは、regionごとに１つ作られる(subnetはregionをまたげない)。
- subenet同士はWANで繋がっている。
- subnet内で、x.x.x.0はネットワーク用に、x.x.x.1はゲートウェイ用に、あと２つなんらかのために確保される。



## IPアドレス

internalIPとexternal IPのマッピングは、VPCでlookup tableによって行われる。

### internal IP
- インスタンスのOSは自分のinternal ipがなにかを知っている。(see: /sbin/config)
- DHCPによってsubnetのレンジの中からIPアドレスが１つがVMに与えられる。ドメイン名(FQDNは`[hostname].c.c[project-id].internal`)とIPの組み合わせがnetwork-scoped DNSに登録される。
- IPアドレスはephemeralだが、ドメイン名はインスタンスをstopしても不変である。

- alias ip rangesを使うことで一つのインスタンス上で動く複数のサーバに異なるIPアドレスを振ることができる。(もちろんsubnetのレンジ内のものを使用可能)

### external IP
- インスタンスのOSは自分のexternal ipがなにかを知らない。
- 基本ephemeralだが、自分でreserveしているものを使い、staticにすることも可能。
- adminは自分で、Cloud DNSにpublic dnsレコードを登録する必要がある。

## routing

- cloud routesがルーティングテーブルを持っており、これはネットワークやサブネットが作られたときに作られる。
- ルーティングテーブルは、以下の情報を含む。
   - (1)各サブネット(のインスタンス??)へのルーティング
   - (2)デフォルトゲートウェイ(`0.0.0.0`)へのルーティング

## firewall

インスタンスごとに付与される。`in/out X from/destination X protocol` 



デフォで以下が許可される。(以下のネットワークとはサブネットではない！っぽい)

- 同一ネットワーク内(=`10.128.0.0/9`)の全てのincoming TCP, UDP, ICMP
- 外部ネットワークからの(=デフォルトゲートウェイ`0.0.0.0/0`からの)incoming ICMP, RDP, SSH

優先度下がって、
- deny-all-ingress rule
- allow-all-egress rule


# [2]VPCネットワークをまたいでinternal IPアドレスでやりとりする

VPCネットワークをまたいでinternal IPアドレスでやりとりするためには、VPC peeringかVPNという方法を使う必要がある。

## Network Interfaces

- インスタンスは、デフォルトのnetwork interfaceを持っており、さらに特定のnetworkに接続するためのnetwork interfaceを追加することができる。これにはNIC(= network interface controllers)を用いる。(subnetのレンジは全てユニークである必要がある)
- 一つのインスタンスはnetwork interfaceを最大８つもつことができる。それぞれのinterfaceに、繋ぎ先のsubnetのIPアドレスのレンジ内のinternal IPアドレスが一つ紐づけられている。
   - ８つと書いたが、インスタンスのcpuのコア数などによって左右される。

- network interfaceは、インスタンス作成時にしか設定できない。インスタンスを削除する以外に消す方法はない。

## Network Peering

- orgを跨ぐことすらできる。
- external IP addressでやりとりするよりも、Network Latency低い, Network Security高い, Network Cost低いという利点がある。
- subnetのrangeが被ったらダメ
- ネットワークAとBをpeeringするためには、peering-A-Bとpeering-B-Aの二つの設定が必要である


## Shared VPC

- 同じOrgの別プロジェクトでVPC Networkを共有(することでinternal IPアドレスを指定してやりとり)したい。 このために、一つのHost Projectに、他のService Projectsをattachする。これによって、shared VPC network(xpnとも)を作成する。このために、host projectに???必要なのは
   - Organization admin role (多分userに対して??)
   - Shared VPC admin (hostにもserviceにも??) = Compute Nework Admin roleに含められて付与される
   - Service Project admin role



# GCP Load Balancer

以下の６種類。

- Global
   - HTTP(S)
   - SSL Proxy
   - TCP Proxy
- Regional
   - Internal TCP/UDP   (powered by Andromeda)
   - Network TCP/UDP   (powered by Maglev)
   - Internal HTTP(S)    (using proxy-based Layer 7ロードバランサ)

## HTTP(S) load balancer

 以下まとめて一つのバランサ。BackendServiceとBackendは異なることに注意。

1. global forwarding rule経由でリクエストがHTTP target proxyに到達
2. target proxyはurl mapを見て、リクエストを然るべきBackendService(こういう名前)にわりふる
2. backend serviceから、同一region(がいっぱいだったらclosest region)のBackend(インスタンス)にリクエストを転送する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/534442/52b0053d-8858-8135-63ee-305ab47934a3.png)


- HTTPSロードバランサだと、 target HTTPS proxyを使う。このproxyは、最低1つ(最高10)のSSL証明書を持っている必要がある。
- Cloud Armorを導入することで、「特定のIPを弾く」などのsecurity policyを作成できる。作成時に、backend serviceに紐づけられる。
- Backendとして、Cloud Storageを使用することもできる。load balancerでbackendとしてこれを選択するときに、`Enable Cloud CDN.`を選択するだけで、CDNを使ったキャッシュが有効になる！(初回のリクエスト時は「まずCDNにリクエストし、キャッシュミスが発覚して、ロードバランサに転送される」という流れ。)


ちなみに、同一region内の、同一ネットワークからのinternalなインスタンスからリクエストは以下のように裁いている。
(同一のregion)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/534442/14f85506-3add-e0c2-64b6-d1ac721e5233.png)


## Managed instance groups

一つのテンプレ(設計図)をもとに、複数のコピーとなるインスタンスを立ち上げられる。ローリングアップデートや、ロードバランシングの負荷調整の際に使用される。







# IAM

(新たに記事作るのもアレなのでここに入れてしまう)

- IAM policyでは、階層の下に行くほど、権限が足し算されていく。(ので、上の回想で権限を与えすぎるな)
- IAM roleは、
    - Basic Roles = Owner > Editor > Viewer (順に包含される) / BillingAdminstrator
    - Predefined Roles = list of permissionsで、名前がついている (Network viewerとか、network adminとか、security adminとかshared VPCとか)
    - Custom Roles


- Security admin roleはfirewallを含む全てのネットワークリソースのlistとCRUDが、Network admin roleはfirewallを含まないリソースのlistのみができる

# 雑多なメモ

- pingはICMPプロトコル(@インターネット層)を使用している。
- DNSサーバ = DNSキャッシュサーバ + DNSコンテンツサーバ