[勉強] NAT (ネットワークアドレス変換)

NAT はしばしばルーターで行われます。そのため、 NAT を行うホストを NAT ルーターと呼びます。しかしながら、 OpenStack デプロイメントでは、通常 Linux サーバーで NAT 機能が実装され、ハードウェアルーターではありません。これらのサーバーでは iptables ソフトウェアパッケージを使って NAT 機能を実装します。

tozastation

- Controller Node - Runs OpenStack services and the ODL controller.
- Network Node - Runs the DHCP agent, the metadata agent, and the L3 agent (for SNAT).
- Compute Node - VMs live here.

tozastation

DVR (Distributed Virtual Router) was first implemented at Juno. Virtual routers
needed to work on Network Node, but, with DVR, they can work on Compute Nodes.

JP: DVR（Distributed Virtual Router）は、Junoで初めて実装された。仮想ルーターは
はNetwork Node上で動作する必要がありましたが、DVRではCompute Node上で動作することができます。

tozastation

DVRの仕組みを簡単に言うと、「同じ仮想ルーターのコピーをすべてのコンピュートノードに配置する」ということです（図1の右）。仮想マシンインスタンスから送信されたパケットは、同じノード上の仮想ルーターで転送先が決定されますので、転送先の仮想マシンインスタンスが同じノードにあれば、そのまま目的の仮想マシンインスタンスにパケットが届けられます。外部ネットワークと通信する場合は、コンピュートノードからそのまま外部ネットワークにパケットが送信されます。

tozastation

Neutron DVR Local Router のソースコード

iptables のコマンド生成してる

dnat_from_floatingip_to_fixedip = (
  'PREROUTING', '-d %s/32 -i %s -j DNAT --to-destination %s' % (
  floating_ip, rtr_2_fip_name, fixed_ip))

tozastation

iptablesでNATを操作するには、「natテーブル」を使用します。「テーブル」はiptablesの重要な概念です。前回紹介したチェインは、フィルタルールを集めてモジュール化したものです。このチェインをさらにグループ化したのがテーブルです。テーブルの種類によって、使えるチェインも異なります。

tozastation

本体
https://git.netfilter.org/iptables/
git clone
git clone git://git.netfilter.org/iptables.git

tozastation

外部 IP アドレスを持たない VM に送信元ネットワークアドレス変換（送信先 NAT または SNAT）を提供します。また、Cloud NAT は、確立された受信レスポンスパケットに対してのみ宛先ネットワークアドレス変換（宛先 NAT または DNAT）を提供します。

tozastation

中間ノードは存在せず、Cloud NAT はコントロールプレーンとしてのみ実装されている

Google Kubernetes Engine と(GKE)いった、どちらかというと(クライアントではなく)サーバー用途で使われるホストに対して NAT のサービスを提供するものであり、GCE/GKE のホスト同士が NAT トラバーサルを使った直接の通信をしなければならない場面は非常に限定的であることを考えると、Cloud NAT においては Endpoint Dependent Mapping を利用することによるデメリットはほぼ無いと考えられます

Endpoint Independent Mapping の必要性

tozastation

NAT ゲートウェイは送信先別に最大 55,000 の同時接続をサポートできます。この制限は、単一の送信先に 1 秒あたり約 900 の接続 (1 分あたり約 55,000 の接続) を作成する場合にも適用されます

tozastation

eBPF NAT

tozastation

When to use eBPF

XDP – eBPF provides an efficient way to examine raw packet buffers as they enter the system, allowing you to make quick decisions about what to do with them.
Connect-time load balancing – With eBPF, you can load balance at the source using a program you’ve loaded into the kernel, instead of using a virtual IP. Since DNAT does not need to take place on the packet processing path, all NAT overhead from service connections is removed.
Observability – eBPF programs are an excellent way to add probes as sensors in the Linux kernel to get context-rich data. This is a huge benefit, as there is no need to make changes to the kernel to enable tracing and profiling. You can easily receive socket calls within the context of the program that opened the socket, or add programs to trace syscalls in the kernel. In our opinion, observability is the use case for which eBPF is most beneficial.

tozastation

XDP
XDPとは受信した通信に対して制御できるもので，eBPFの中でも特に注目されている機能だと思います．先ほどの画像を見てもらうとわかりますが．startの次にXDPで処理する部分があります．XDPはパケット処理の中でも非常に早い段階なので，パケット処理のためのメモリの確保が必要なく，低コストで早く処理できます．そのため，DDoS対策やLoad Balancerとしての活躍が期待されています．

Traffic Control
XDPでは受信したパケットに対してしか処理できませんでしが，Traffic Control(以下 tc)では受信も送信も処理できます．Traffic ControlというのはBPFとは関係なくLinuxに存在する機能ですが，そこにBPFプログラムをアタッチできる感じです．

tozastation