2022-04-09-NAT 소개

NAT는 (Network Address Translation)의 약자입니다.

NAPT(Network Address Port Translation)라는 또 다른 이름이 있습니다. NAPT는 주소 변환과 포트 변환을 모두 지원하며 여러 내부 네트워크 호스트가 외부 네트워크 IP 주소를 공유하여 외부 네트워크에 액세스할 수 있도록 합니다. NAPT는 IP 주소 부족을 효과적으로 개선할 수 있습니다.

달리 명시하지 않는 한, 본 문서의 NAT는 NAPT NAT를 의미합니다.

네트워크 애플리케이션이 증가함에 따라 IPv4 주소 고갈 문제는 점점 더 심각해지고 있습니다. IPv6는 IPv4 주소 공간 부족 문제를 근본적으로 해결할 수 있지만 현재 많은 네트워크 장비와 네트워크 애플리케이션은 대부분 IPv4를 기반으로 하고 있습니다. 따라서 IPv6가 널리 사용되기 전에는 일부 전환 기술(예: CIDR, 개인 네트워크 주소 등)이 사용되었습니다. .)은 이 문제를 해결하는 가장 좋은 방법입니다. 문제를 해결하는 주요 방법은 NAT가 이러한 전환 기술 중 하나라는 것입니다.

공용망에 접속하는 사설망 사용자로부터의 패킷이 게이트웨이 장치에 도착할 때, 게이트웨이 장치에 NAT 기능이 배치되어 있으면 장치는 수신된 IP 데이터의 헤더에 있는 IP 주소를 변환합니다. 다른 포트로의 패킷 IP 주소와 포트 번호를 다른 포트 번호로 변환한 후 공용 네트워크로 전달합니다. 이 과정에서 장치는 동일한 공용 네트워크 주소를 사용하여 여러 개인 네트워크 사용자가 보낸 패킷을 변환하고 포트 번호를 통해 서로 다른 개인 네트워크 사용자를 구별함으로써 주소 재사용 목적을 달성할 수 있습니다.

초기 NAT는 기본 NAT를 의미하며 기술적으로 구현이 비교적 간단하고 주소 변환만 지원하며 포트 변환은 지원하지 않습니다. 따라서 기본 NAT는 사설망 호스트가 공용 네트워크에 액세스하는 문제만 해결할 수 있을 뿐 IPv4 주소 부족 문제는 해결할 수 없습니다. 이후 NAT는 주로 NAPT(Network Address Port Translation)를 참조하며, NAPT는 주소 변환과 포트 변환을 모두 지원하므로 여러 개인 네트워크 호스트가 공용 IP 주소를 공유하여 공용 네트워크에 액세스할 수 있습니다. 부족 문제.

기본 NAT 방식은 IP 주소만 변환하며 TCP/UDP 프로토콜의 포트 번호는 변환하지 않습니다. 하나의 외부 네트워크 IP 주소는 하나의 내부 네트워크 사용자만 사용할 수 있습니다. . [그림 1]은 Basic NAT의 기본 원리를 설명하고 있다.

기본 NAT 구현 과정은 다음과 같습니다.

NAPT 방식은 IP 주소뿐만 아니라 TCP/UDP 프로토콜의 포트 번호도 변환합니다. -대일 변환. NAPT는 "IP 주소 + 포트 번호" 형식을 사용하여 여러 인트라넷 사용자가 하나의 외부 IP 주소를 사용하여 외부 네트워크에 액세스할 수 있도록 합니다. 따라서 NAPT는 "다대일 주소 변환" 또는 "주소 다중화"라고도 합니다. ". [그림 2]는 NAPT의 기본 원리를 설명하고 있다.

NAPT 구현 과정은 다음과 같습니다.

탄력적 공인 IP를 절약하기 위해 VPC 내 클라우드 호스트가 공용 네트워크에 접속해야 하고 요청 수가 많은 경우 공용 네트워크에서는 공용 네트워크 NAT 게이트웨이의 SNAT 기능을 사용할 수 있습니다. VPC의 서브넷 하나는 하나의 SNAT 규칙에 해당하며, 하나의 SNAT 규칙은 여러 탄력적 공용 IP로 구성될 수 있습니다. 공용 네트워크 NAT 게이트웨이는 다양한 사양의 연결 수를 제공합니다. 비즈니스 계획에 따라 여러 SNAT 규칙을 생성하여 탄력적인 공용 네트워크 IP 리소스를 최대한 활용할 수 있습니다.

VPC 내 클라우드 호스트가 공용망에 서비스를 제공해야 하는 경우 공용망 NAT 게이트웨이의 DNAT 기능을 활용할 수 있습니다.

DNAT 기능은 탄력적 공용 IP에 바인딩되며 매핑 방법에는 두 가지(IP 매핑, 포트 매핑)가 있습니다. 포트 매핑을 통해 사용자가 지정된 프로토콜과 포트를 사용하여 탄력적 공용 IP에 액세스하면 공용 NAT 게이트웨이가 대상 클라우드 호스트 인스턴스의 지정된 포트로 요청을 전달합니다.

IP 매핑을 통해 클라우드 호스트에 대한 탄력적 공용 IP를 구성할 수도 있으며, 탄력적 공용 IP에 대한 액세스 요청은 대상 클라우드 호스트 인스턴스로 전달됩니다. 여러 클라우드 호스트가 탄력적인 공용 IP 및 대역폭을 공유하고 대역폭 리소스를 정확하게 제어할 수 있습니다.

클라우드 호스트는 DNAT 규칙으로 구성됩니다. 여러 클라우드 호스트가 공용 네트워크에 대한 서비스를 제공해야 하는 경우 하나 이상의 탄력적 공용 네트워크 IP 리소스를 공유하도록 여러 DNAT 규칙을 구성할 수 있습니다.

일반적인 P2P 시나리오:

[STUN] 표준에서 NAT는 다음과 같이 4가지 유형으로 구분됩니다. 자세한 내용은 아래 그림을 참조하세요.

STUN에 정의된 NAT 유형

STUN

ICE

서버에서 받은 포트에 1을 추가했는데 2개를 지원한다면 대칭형 NAT의 경우 증분도 1 포트입니다. 예를 참조하세요.

서버에 연결하고 NAT A는 다음을 포함하는 패킷을 S에게 보냅니다. 45.89.66.125:58000

B는 다음에 연결합니다. 서버에서 NAT B는 다음 내용이 포함된 데이터 패킷을 S로 보냅니다: 144.85.1.18:45000

S는 B의 정보를 A로 보내고 A의 정보를 B로 보냅니다.

이제 다음과 같습니다. A가 B에게 이 정보를 보내면 NAT A는 다음 맵을 생성합니다:

INTERNAL_IP_A:58001-144.85.1.18:45001

이 연결을 위해 NAT A는 포트 58001(마지막 포트)을 사용해야 합니다. 1, 대칭형 NAT입니다)

NAT B가 패킷을 수신했지만 삭제합니다.

이제 B가 수신된 정보를 사용하여 A에 패킷을 보내는 경우 NAT B는 다음 매핑을 생성합니다.

INTERNAL_IP_B:45001-45.89.66.125:58001

이제 NAT는 이 패킷을 수락해야 합니다. 왜냐하면 테이블에 수신에 대한 정보가 있기 때문입니다.

더 유명한 사진 먼저:

(CONNTRACK)은 이름에서 알 수 있듯이 연결 상태를 추적하고 기록하는 것입니다. Linux는 네트워크 스택을 통과하는 각 데이터 패킷에 대해 새로운 연결 항목(Connection 항목)을 생성합니다. 그 후, 이 연결에 속하는 모든 패킷은 이 연결에 고유하게 할당되고 연결 상태를 식별합니다. 연결 추적은 방화벽 모듈의 상태 감지를 위한 기초이며 주소 변환에서 SNAT 및 DNAT를 구현하기 위한 전제 조건이기도 합니다.

그렇다면 Netfilter는 어떻게 연결 기록을 생성합니까? 모든 데이터에는 "소스"와 "대상" 호스트가 있습니다. 연결을 시작하는 호스트를 "소스"라고 하며, "소스"의 요청에 응답하는 호스트를 소위 대상이라고 합니다. 기록 항목의 생성은 각 연결에 대해 생성, 전송 및 종료가 추적되고 기록됩니다. 모든 기록 항목에 의해 생성된 테이블을 연결 추적 테이블이라고 합니다.

연결 추적 하위 시스템은 표시된 모든 패킷 흐름을 추적합니다. 내용을 보려면 "sudo conntrack -L"을 실행하세요.

한 줄에 하나의 연결 추적 항목이 표시됩니다. 각 줄에는 주소와 포트 번호가 두 번 표시되거나 역방향 주소와 포트 쌍이 표시되는 것을 볼 수 있습니다. 이는 각 항목이 상태 테이블에 두 번 삽입되기 때문입니다. 첫 번째 주소 쿼드러플(소스 및 대상 주소와 포트)은 원래 방향으로 기록된 주소, 즉 Initiator가 보낸 주소입니다. 두 번째 4개 튜플은 conntrack이 피어로부터 응답을 받을 때 확인하기를 기대하는 것입니다.

이는 두 가지 문제를 해결합니다:

NAT 규칙이 일치하는 경우(예: IP 주소 위장) 연결 추적 항목의 응답 섹션에 기록되며, 이는 동일한 규칙에 속하는 모든 연결에 자동으로 적용될 수 있습니다. 미래의 패킷 흐름.

상태 테이블의 조회는 네트워크 또는 포트 주소 변환 형식이 적용된 흐름에 대한 응답 패킷인 경우에도 성공합니다.

원래(처음 표시된) 쿼드러플은 변경되지 않습니다. 이는 개시자가 보낸 것입니다. NAT 작업은 응답(두 번째 응답)을 4배만 변경합니다. 왜냐하면 수신자가 이를 보게 되기 때문입니다. 첫 번째 쿼드러플에 대한 변경은 의미가 없습니다. netfilter는 개시자의 상태를 제어할 수 없으며 패킷 수신/전달에만 영향을 미칠 수 있습니다. conntrack은 기존 항목에 매핑되지 않는 경우 패킷에 새 상태 항목을 추가할 수 있습니다. UDP의 경우 이는 자동으로 발생합니다. TCP의 경우 TCP 패킷에 SYN 비트가 설정된 경우에만 새 항목을 추가하도록 conntrack을 구성할 수 있습니다. 기본적으로 conntrack은 conntrack이 활성화되기 전에 존재했던 스트림에 문제를 일으키지 않고 중간 스트림 픽업을 허용합니다.

이전 섹션에서 언급했듯이 나열된 응답 튜플에는 NAT 정보가 포함됩니다. 소스 또는 대상 NAT가 적용된 항목만 표시하도록 출력을 필터링할 수 있습니다. 이를 통해 특정 스트림에서 어떤 유형의 NAT 변환이 활성화되어 있는지 확인할 수 있습니다. "sudo conntrack -L -p tcp --src-nat"는 다음을 표시할 수 있습니다.

이 항목은 10.0.0.10:5536에서 10.8.2.12:80까지의 연결을 보여줍니다. 그러나 이전 예와 달리 응답 방향은 단순히 원본의 반대 방향이 아닙니다. 소스 주소가 변경되었습니다. 대상 호스트(10.8.2.12)는 10.0.0.10이 아닌 192.168.1.2로 응답 패킷을 보냅니다. 10.0.0.10이 다른 패킷을 보낼 때마다 이 항목이 있는 라우터는 소스 주소를 192.168.1.2로 바꿉니다. 10.8.2.12가 응답을 보내면 대상이 다시 10.0.0.10으로 변경됩니다. 이 소스 NAT는 nft 매스커레이드 규칙으로 인해 발생합니다:

inet nat postrouting Meta oifname "veth0" 매스커레이드

"dnat to" 또는 "redirect to"와 같은 다른 유형의 NAT 규칙 , 유사한 방식으로 표시되며 응답 튜플은 원본과 다른 대상을 갖습니다.

conntrack 계산 및 타임스탬프는 두 가지 유용한 확장입니다. "sudo sysctl net.netfilter.nf_conntrack_acct=1"은 "sudo conntrack -L"을 활성화하여 스트림당 바이트 및 패킷 카운터를 추적합니다.

"sudo sysctl net.netfilter.nf_conntrack_timestamp=1"은 각 연결의 "시작 타임스탬프"를 기록합니다. "sudo conntrack -L"은 스트림이 처음 표시된 이후 경과된 시간(초)을 표시합니다. 절대 시작 날짜도 보려면 "--output ktimestamp"를 추가하세요.

상태 테이블에 항목을 추가할 수 있습니다. 예를 들면 다음과 같습니다.

conntrackd는 이를 상태 복제에 사용합니다. 활성 방화벽의 항목이 대기 시스템에 복사됩니다. 이렇게 하면 트래픽이 증가하더라도 연결을 중단하지 않고 백업 시스템이 인계받을 수 있습니다. Conntrack은 또한 conntrack 태그 및 연결 추적 레이블과 같이 유선으로 전송된 패킷 데이터와 관련 없는 메타데이터를 저장할 수 있습니다. 이를 변경하려면 "update"(-U) 옵션을 사용하십시오:

sudo conntrack -U -m 42 -p tcp

이렇게 하면 모든 tcp 스트림의 connmark가 42로 변경됩니다.

상태 테이블에서 항목을 삭제하려는 경우도 있습니다. 예를 들어 NAT 규칙을 변경해도 테이블의 흐름에 속하는 패킷에는 영향을 미치지 않습니다. 수명이 긴 UDP 세션(예: VXLAN과 같은 터널링 프로토콜)의 경우 새 NAT 변환이 적용될 수 있도록 항목을 삭제하는 것이 합리적일 수 있습니다. "sudo conntrack -D"를 통해 항목을 제거한 다음 선택적 주소 및 포트 정보 목록을 제거하십시오. 다음 예에서는 테이블에서 특정 항목을 삭제합니다.

클라우드 시나리오에서 NAT의 기본 원칙은 크게 변경되지 않았습니다. 그러나 테넌트 격리, 테넌트 운영 및 유지 관리 등의 문제를 고려해야 합니다.

VPC와 VPC 아래의 서브넷 세그먼트는 사용자가 자체 관리하므로 주소가 겹칠 수 있는 여러 테넌트에 대해 하나의 장치에 NAT 기능을 제공해야 합니다. 그래서 우리는 이 문제를 해결하기 위해 vxlan 터널링 기술을 사용했습니다.

클라우드 컴퓨팅에서는 테넌트 격리 문제를 해결하기 위해 일반적으로 각 사용자 서브넷에 vni(vxlan net ID)가 할당됩니다.

따라서 vni를 사용하여 다른 vpcs에서 NAT 인스턴스를 식별할 수 있습니다.

Huawei Cloud NAT 소개

_topic_0086739762.html