☰

NAT 게이트웨이에서 SNAT 소스 주소를 구성해야 합니까?

tag-icon • tag-icon iptables nat
NAT 게이트웨이에서 SNAT 소스 주소를 구성해야 합니까?

다음 네트워크 토폴로지를 가정합니다. NAT 게이트웨이 네트워크 설정

NAT 게이트웨이에는 linux-router다음과 같은 SNAT 규칙이 있습니다.

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       all  --  10.99.99.50          anywhere             to:1.1.1.6

또한 그림과 같이 인터페이스에 1.1.1.6주소가 구성되어 있습니다 . lo기술적으로 이것은 필요하지 않습니다. 즉, 제거해도 linux-svr여전히 연결이 가능합니다. 그렇다면 NAT 게이트웨이에서 SNAT 소스 주소를 구성하는 것이 합리적일까요? 상관 관계 및 1.1.1.6역추적이 더 쉽기 때문에 문제 해결 목적으로만 사용됩니까 linux-svr?

답변1

웹 필터경로와는 아무 관련이 없습니다. 이는 아래에서 일어나는 일을 설명하는 데 중요한 요소입니다.웹 필터NAT 처리는 주소를 변경하며, 경우에 따라 라우팅 결정 전에 이 작업이 수행되면 라우팅 결정이 변경되는 경우도 있습니다.웹 필터그 자체로는 라우팅 결정을 내리지 않습니다. 이는 단지 라우팅 스택의 역할일 뿐입니다.

나는 이 아래에 가정하고있다리눅스 라우터추가 없음방화벽규칙(기본적으로iptables 필터표) 질문에 언급된 적이 없기 때문입니다. 또한 해결해야 할 사례 수가 늘어나는 것을 방지하기 위해 다음과 같은 사항을 추가로 가정합니다.리눅스-srv(그리고리눅스 라우터) 10.99.99.0/24 LAN에 있습니다(수정하는 것도 어렵지 않습니다).

삭제 정보 1.1.1.6

SNAT는 라우팅 결정이 내려진 후 POSTROUTING 중에 발생합니다. SNAT가 지정된 기준과 일치하는 IP를 찾으면 응답을 처리하기 위해 conntrack 항목을 추가합니다. 비슷한 일이 일어났습니다.리눅스 라우터(사용 conntrack -E -e NEW):

    [NEW] tcp      6 120 SYN_SENT src=10.99.99.50 dst=8.8.8.8 sport=57490 dport=80 [UNREPLIED] src=8.8.8.8 dst=1.1.1.6 sport=80 dport=57490

그렇지 않다웹 필터응답이 실제로 돌아왔는지 확인하는 것이 귀하의 임무입니다. 이것은 다시 라우팅 스택의 작업입니다(외부 라우팅 포함).리눅스 라우터통제 없음).

삭제 전 IP 주소는 1.1.1.6이었습니다.리눅스 라우터. Linux는 다음과 같으므로 이 IP가 어떤 인터페이스에 추가되는지는 중요하지 않습니다.약한 호스트 모델: 모든 인터페이스에서 수신된 이 IP에 대한 쿼리에 응답할 수 있습니다. 이 항목을 제거해도 1.1.1.6에 대한 패킷 수신이 차단되지 않습니다.M10i1.1.1.6에 대한 특정 경로가 있습니다. 다음에 속하는 1.1.215.48을 사용하십시오.리눅스 라우터. 그래서리눅스 라우터이 IP에 대한 ARP 요청을 받지 못했습니다. 다음에서 ARP 요청을 받았습니다.M10i항상 1.1.215.48입니다(마찬가지로 다음을 의미합니다.M10iARP 테이블은 1.1.1.6이 아닌 1.1.215.48만 캐시합니다. 이는 이 IP의 존재가 중요하지 않음을 의미합니다.리눅스 라우터~ 할 것이다언제나1.1.1.6에서 트래픽을 수신합니다. 하지만 이제 차이점이 있습니다.

  • 수신 패킷이 이전에 생성된 conntrack 항목과 일치하지 않는 경우

패킷이 이전 활동과 관련이 없는 경우리눅스-srv, 패킷이 가장 먼저 도착합니다경로 결정, 보여진 바와 같이이 다이어그램. 현재 라우팅 테이블에 따르면 다음과 같아야 합니다.

    # ip route get from 198.51.100.101 iif eth0 1.1.1.6
    1.1.1.6 from 198.51.100.101 via 1.1.215.60 dev eth0 
        cache iif eth0

그렇다면M10i(또는 1.1.215.32/27 LAN의 모든 시스템)리눅스 라우터아래와 같이 ICMP 리디렉션도 수시로 추가됩니다.

    # ip route get from 1.1.215.60 iif eth0 1.1.1.6
    1.1.1.6 from 1.1.215.60 via 1.1.215.60 dev eth0 
        cache <redirect> iif eth0

그럼에도 불구하고 인터넷에서 들어오는 패킷의 경우 패킷이 다시 전송됩니다.M10i, 구현될 수 있음엄격한 역방향 경로 전달: 뒤로 라우팅된 패킷은 삭제됩니다.M10i, 소스(198.51.100.101)가 라우팅 테이블의 잘못된 쪽에 있고 따라서 엄격한 경로 전달에 의해 필터링되기 때문입니다. 엄격한 역방향 경로 전달이 없으면 사이에 루프가 발생합니다.M10i그리고리눅스 라우터패킷의 TTL이 0으로 줄어들 때까지 패킷은 삭제됩니다.

  • 패킷이 들어오는 경우하다이전에 NAT로 연결되고 conntrack으로 추적된 흐름을 일치시킵니다.

이전 예: 8.8.8.8 tcp 포트 80에서 1.1.1.6 포트 57490으로 수신된 응답 패킷은 다음을 통해 추적됩니다 conntrack -E.

     [UPDATE] tcp      6 60 SYN_RECV src=10.99.99.50 dst=8.8.8.8 sport=57490 dport=80 src=8.8.8.8 dst=1.1.1.6 sport=80 dport=57490
     [UPDATE] tcp      6 432000 ESTABLISHED src=10.99.99.50 dst=8.8.8.8 sport=57490 dport=80 src=8.8.8.8 dst=1.1.1.6 sport=80 dport=57490 [ASSURED]

특정 사전 라우팅 지점에서,연결하다"de-SNAT"을 처리합니다. (참고로 이 패킷은 다시는 통과하지 않습니다.)iptables'nat 테이블, 이는 이전 회로도에도 기록되어 있습니다."새" 연결에 대해서만 "nat" 테이블을 참조하세요.). 이제 대상 IP는 10.99.99.50으로 변경되고 패킷은 첫 번째 라우팅 결정에 도달합니다.리눅스-srv. 모든 것이 정상입니다.

그래서 1.1.1.6을 제거하면 어떤 일이 발생하는지 설명했습니다. 영향이 없습니다.리눅스-srv인터넷 클라이언트 역할을 하지만 약간의 중단이 발생합니다.M10i그리고리눅스 라우터관련 없는 수신 패킷의 경우.

인터넷상의 일부 고객에게 도달하려는 경우리눅스-srvDNAT 규칙 사용리눅스 라우터, 영향을 받은 연결(예: 웹 서버)에 대해리눅스-srvTCP 포트 80), 모든 것이 중단 없이 정상적으로 실행됩니다. 다른 시도에도 작은 문제가 있습니다M10i그리고리눅스 라우터.

SNAT 규칙의 소스 IP 선택기/필터 삭제 정보

제공된 정보 없음: 나가는 인터페이스에도 선택기/필터가 있는지 여부. 아래 두 규칙은 다음과 같은 결과를 얻습니다 iptables -t nat -n -L(그러나 아직은 더 나은 결과는 아님 ) .iptables -t nat -n -v -Liptables-save

iptables -t nat -A POSTROUTING -o eth0 -s 10.99.99.254 -j SNAT --to-source 1.1.1.6

또는

iptables -t nat -A POSTROUTING -s 10.99.99.254 -j SNAT --to-source 1.1.1.6

실제로 이 경우에는 다음 두 명령 중 하나를 사용하는 것이 중요하지 않습니다.

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 1.1.1.6
iptables -t nat -A POSTROUTING -j SNAT --to-source 1.1.1.6
  • 1.1.1.6은 여전히 ​​​​에 속합니다리눅스 라우터

eth0 측에서는 개인 IP 대상 주소를 볼 수 없기 때문에,리눅스 라우터효율적으로 라우팅할 수 있어야 함하나IP 주소:리눅스-srv10.99.99.50이며 이 경로는 10.99.99.50에서 먼저 시작된 경우에만 발생하므로 공용 IP로 SNAT됩니다. ~부터iptables새로운 conntrack 항목은 초기 연결(NEW 상태)에서만 생성됩니다. 그 후에는 conntrack 항목이 더 이상 변경되지 않으며 모든 것이 제대로 작동합니다.

  • 1.1.1.6 삭제됨리눅스 라우터

  • ~을 위한리눅스-srv인터넷에 연결되면 모든 것이 예상대로 작동합니다. 이전 설명도 적용됩니다.

  • 외부에서 1.1.1.6(예: 198.51.100.101)으로 들어오는 알 수 없는 연결의 경우:

    라우팅 스택은 1.1.1.6이 다음으로 라우팅되어야 한다고 결정합니다.M10i(이전 설명 참조) NEW 상태에 임시 conntrack 항목이 추가되고 패킷은 nat/POSTROUTING에 도착합니다. 패킷은 1.1.1.6에 SNAT되어 다시 전송됩니다.M10i.M10i1.1.1.6으로 가는 경로가 있고 다시 변경된 패킷이 다음으로 전송됩니다.리눅스 라우터소스 및 대상 IP는 모두 1.1.1.6입니다(소스가 라우팅 테이블의 올바른 쪽에 있기 때문에 엄격한 역방향 경로 전달은 이를 제거하지도 않습니다).리눅스 라우터conntrack -E패킷이 수신되었습니다... 버그인지는 알 수 없지만 198.51.100.101에서 수신된 단일 TCP SYN 패킷을 사용하여 상황을 재현하는 실험에서 캡처된 내용은 다음과 같습니다.

         # conntrack -E
         [NEW] tcp      6 120 SYN_SENT src=198.51.100.101 dst=1.1.1.6 sport=48202 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=48202
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=48202 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=60062
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=60062 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=23442
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=23442 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=54429
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=54429 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=7652
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=7652 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=34503
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=34503 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=49256
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=49256 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=58399
         [NEW] tcp      6 120 SYN_SENT src=1.1.1.6 dst=1.1.1.6 sport=58399 dport=5555 [UNREPLIED] src=1.1.1.6 dst=1.1.1.6 sport=5555 dport=54522
         [...]

    netfilter가 비정상적으로 작동하더라도 사이에 루프가 존재합니다.M10i그리고리눅스 라우터(TTL이 0으로 떨어질 때까지).

결론적으로

로컬 IP 주소 1.1.1.6을 삭제하지 마십시오. 라우팅 문제를 일으키고 있지만 그렇지 않습니다.웹 필터이러한 라우팅 문제를 수정하세요. 이러한 루프를 방지하기 위해 방화벽 규칙을 추가하더라도 잘못된 라우팅을 사용하는 것은 현명한 조치가 아닙니다.

마찬가지로 SNAT 규칙의 소스 IP 선택기를 삭제하도록 선택할 수 있지만 인터페이스가 선택되지 않은 경우(즉, 이 규칙을 선택한 경우) 삭제하지 않는 것이 가장 좋습니다 iptables -t nat -A POSTROUTING -j SNAT --to-source 1.1.1.6. 인터넷에서 라우팅할 수 없는 개인 IP 주소가 있기 때문에 작동합니다. 그렇지 않은 경우 외부에서 들어오는 모든 연결은 후면 LAN에 도달하려고 시도합니다.리눅스 라우터eth2 인터페이스는 1.1.1.6으로 SNAT됩니다.

예를 들어, 다음으로부터 특정 서비스를 얻기 위해 DNAT 규칙을 추가한 경우에도 마찬가지입니다.리눅스-srv인터넷에서 액세스할 수 있어리눅스-srv1.1.1.6과 다른 소스 주소는 절대 표시되지 않습니다. 다음은 시뮬레이션의 구체적인 예입니다(1.1.1.6에서 1.1.1.6으로의 일반 복귀).리눅스 라우터):

# ip -br a
lo               UNKNOWN        127.0.0.1/8 1.1.1.6/32 
eth0@if5         UP             1.1.215.48/27 
eth2@if4         UP             10.99.99.254/24 

# iptables -t nat -A PREROUTING -d 1.1.1.6 -p tcp --dport 80 -j DNAT --to-destination 10.99.99.50

# iptables-save | grep -v ^#
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -d 1.1.1.6/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.99.99.50
-A POSTROUTING -j SNAT --to-source 1.1.1.6
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

# conntrack -E 
   [NEW] tcp      6 120 SYN_SENT src=198.51.100.101 dst=1.1.1.6 sport=45752 dport=80 [UNREPLIED] src=10.99.99.50 dst=1.1.1.6 sport=80 dport=45752
 [UPDATE] tcp      6 60 SYN_RECV src=198.51.100.101 dst=1.1.1.6 sport=45752 dport=80 src=10.99.99.50 dst=1.1.1.6 sport=80 dport=45752
 [UPDATE] tcp      6 432000 ESTABLISHED src=198.51.100.101 dst=1.1.1.6 sport=45752 dport=80 src=10.99.99.50 dst=1.1.1.6 sport=80 dport=45752 [ASSURED]

명확하지 않을 수 있지만 이는 예상되는 응답이 10.99.99.50에서 1.1.1.6(198.51.100.101이 아님)이라는 것을 의미합니다.리눅스-srv실제로 연결되는 IP 주소를 무시하면 항상 1.1.1.6이 표시됩니다.

관련 정보