NAT

Network Address Translation

IPマスカレードとも呼ばれる

linuxのIP masquerade機能でNAPTが有名になったのが経緯らしい

パケットのIP addressを別のIP addressに変換する技術

正確にはsrc, dest IPのどちらを変換させるかでsource nat, destination natの二種類ある。

さらにportの変換も行うNAPT(Network Address Port Translation)もある

複数端末からの通信で同じグローバルアドレスを共有する際にportで区別させるため

これもsrc port , dest portのどちらを変換するかで二種類にわかれる。

ご家庭で使われる一般的なNAT はsource natであり、NAPTである。'

NAPTではパケットのsource IP, source portを別のIP, portに変換。

変換情報をメモリの変換テーブルに記録

戻りパケットが来た際にテーブルを参照してパケットを逆方向に変換

戻すべき送信元クライアントにポートや戻りパケットを返す

NA(P)Tの実装は次の2種類にわかれる

Cone型

Symetric 型

家庭用ルーターのNATがどのタイプかは製品情報にもあまり書かれていない・・・

Cone

WANからの受信パケットの送信先(dest ip,dest port)となるNATエントリがあれば通信許可

受信パケットの送信元は(src IP, src port)は見ていない

受け取ったパケットの宛先が過去にNATの変換で利用したものならOKという仕様

送信元が誰であろうがLANへの通信を許可する

何らかの手段でNATエントリーを知っていればWANからLANへパケットが届く

Full cone NAT

WAN側からLAN側への通信において、一度も送信したことがないIPアドレスでも受信可能

Addresss Restricted cone NAT

一度送信した端末(NAT デバイスのWAN側に送信先アドレスのエントリが存在)であれば受信可能

ポートは無視

Port Restricted cone NAT

一度送信した端末(NAT デバイスのWAN側に送信先アドレスと送信先Portのエントリが存在)あれば受信

Symmetric NAT

宛先(dest IP, dest port)ごとに、ユニークになるようなアドレス変換を行う。

変換情報だけでなく、元パケットの宛先(destIP, dest port)も記録しておく

宛先からの通信についてのみWANからLANへの通信許可。

Coneと違い別の誰かの通信も許可されてしまうということもない。

セキュリティとしては一番間違いが無い、ただしNAT Traversal時に問題になりがち

全体の10,20%程度がこれ？

本当のところは謎。

NAT問題点

udp,tcpパケットにしか対応していない。

IPパケットのアドレスを変換しかできないか、そもそもUDP,TCPしか扱わない機種が多い。

UDPの変換テーブルでエントリーを適切に消せない。

大量のクライアントが大量にUDP通信するとテーブルサイズが増えてメモリに乗り切らなくなる

TCPの場合は通信の終わりはわかるので適切に消せるが、UDPは通信の終わりがわからない。

現実的には最後の通信からの時間でタイムアウトでエントリを削除している実装がほとんど

CGNAT, QUIC周りで問題になりがち

outgoing パケットのIPフラグメントの対応が難しい

たいていのNAPT実装では対応できていない

incomming パケットのIPフラグメントの対応ができない

NAT Traversal

NAT越えのための技術

UPnP

UDP hole punching

STUN

connection reversal

TRUN

UPnP

Universal Plug and Play

もともとは機器を接続するだけでネットワークに参加するための仕組み

IPアドレスの取得

別の機器の発見、制御

XMLとHTTPで情報をやりとり

UPnPでNAT機器のNATテーブルにエントリーを追加してNAT Traversalを実現

通信が必要な時だけポートを開け閉め、エントリー追加、削除をする

素人が自前で変なport fowardingするようより安心かもしれない。

ただWEBカメラ等の常時開放系とか、開けるポートがわかってしまう製品だと、ただ穴を開けるだけと同じなのでセキュリティホールになりがち

実際ハッカーのDDOS用のクライアントに使われたりしがち

UDP hole punching

Cone型NATで有効なNAT越え技術

Cone側のエントリーさえあればパケット送信元を無視して内部へ通信を許可するという仕様を利用

UDPのみの策なのでTCPは非対応。

synmetric型のNATだと非対応

STUNはこの仕組みを使っている

前提としては通信の双方がNAT配下にいる場合

UDP hole punching用のサーバーにたいして双方LANからWANへUDPを送りつける

ここでNATテーブルにエントリーが乗る

サーバーは双方のUDPパケットを受け取っている状態

つまりCone 型NATの穴であり通信先となる相手のIP アドレスと、ポートを知っている。

UDP hole punching サーバーに通信相手のIPアドレスとポートを問い合わせて相手の情報を双方で得る

得た情報を利用して通信先となる相手にUDP通信。

事前にUDPで通信してNAT エントリーが乗っているのでCone型なら通信可能

実際にはrestricted port cone natだったりすると、過去に送信先となったかを確認している

そのため、さらに双方で実際の相手先に一度通信してNATエントリーを追加する必要がある

UDPの場合はNATエントリーのタイムアウト問題がある

キープアライブのために何もなくてもダミーでキープアライブ用パケットの送出が必要になる

STUN

Session Traversal Utilities for NAT

UDP hole puhcingを実現する標準仕様

仕組みとしてはUDP hole puchingサーバーが具体的にはSTUNサーバーとなる

クライアントとSTUNサーバーのメッセージフォーマットやもろもろ決まっている

ゲーム、WEB RTCのP2P通信をNAT越えで確立するために主に利用される

connection reversal

TCPのestablished パケット(戻り)は当然NATを通ることを利用

前提としては通信の片方はNATは以下、片方はグローバルにいる

グローバル側から接続依頼サーバーに通信依頼

NAT配下のクライアントは接続依頼サーバーを定期的にポーリング

接続依頼があればNAT配下側からグローバル側のクライアントに通信開始

TCP前提なのでUDP通信には使えないのがネック

TURN

Traversal Using Relay around NAT

シンプルにグローバル上に通信を中継するサーバーを立てる

通信する双方がNAT配下でも問題なし。

TCP,UDP両対応可能

中継サーバーの運用コスト、サーバー負荷での通信劣化、非効率な通信と問題点はある。