☰

NAT가 컴퓨터의 TCP 및 UDP 포트 풀에서 포트를 예약하지 않는 이유는 무엇입니까?

tag-icon • tag-icon networking iptables nat
NAT가 컴퓨터의 TCP 및 UDP 포트 풀에서 포트를 예약하지 않는 이유는 무엇입니까?

저는 두 가지 실험을 했습니다. 두 가지 네트워크는 다음과 같습니다.

        [private network]     [public network]
    A -------------------- R ----------------- B
192.168.0.5     192.168.0.1|192.0.2.1       192.0.2.8

ㅏ기본 게이트웨이는오른쪽.오른쪽IPv4 전달이 활성화되어 있으며 다음과 같은 iptables 규칙이 있습니다.

iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE --to-ports 50000

목적은 TCP에서 들어오는 트래픽이ㅏ마스킹에 192.0.2.1을 사용합니다.오른쪽포트 50000.

포트 60000에 TCP 서비스를 게시했습니다.두번째사용 nc -4l 192.0.2.8 60000.

그런 다음 연결을 열었습니다.ㅏ:nc -4 192.0.2.8 60000

ㅏ다음과 같이 패킷 전송을 시작합니다.

192.168.0.5:53269 -> 192.0.2.8:60000

오른쪽그것을 번역하다

192.0.2.1:50000 -> 192.0.2.8:60000

여태까지는 그런대로 잘됐다.

그런 다음 다음 클라이언트를 열려고합니다.오른쪽: nc -4 192.0.2.8 60000 -p 50000. 메시지를 보냈는데 아무 일도 일어나지 않았습니다. 패킷을 볼 수 없습니다오른쪽tcpdump.tcpdump.

변장 규칙이 존재하기 때문에, 아니면 적어도 활성화되어 있기 때문에 예상했을 것입니다.오른쪽두 개의 nc를 동일한 포트에 바인딩하면 발생하는 "nc: 주소가 이미 사용 중입니다"라는 오류 메시지와 함께 nc가 실패합니다.

그런 다음 conntrack 매핑이 사라질 때까지 잠시 기다립니다.

두 번째 실험은 내가 열려고 시도한 것입니다.오른쪽고객이 먼저입니다.오른쪽다음으로 시작두번째바로. 그런 다음 연결을 열면ㅏ, 해당 패킷은 무시됩니다.ㅏSYN 도착오른쪽, 그러나 응답을 받지 못합니다. 심지어 ICMP 오류에도 응답을 받지 못합니다. 때문인지는 모르겠지만오른쪽가장 무도회 포트가 부족하거나 Linux가 완전히 혼란스럽기 때문입니다(기술적으로 포트를 차단하고 있지만 이미 설정된 연결이 어떻게든 방해하고 있음).

NAT의 동작이 잘못된 것 같습니다. 실수로 masquerading(특히 iptables 규칙 중에 지정되지 않음) 및 services용 포트를 구성할 수 있었고 --to-ports커널은 자동으로 연결을 끊었습니다. 저도 그런 기록은 어디에도 없습니다.

예를 들어:

  • ㅏ정상적인 요청을 해보세요두번째.오른쪽50k의 포트 마스크를 사용하십시오.
  • ㅏDNS 쿼리 만들기오른쪽. 그게 다야시간재귀적이며,오른쪽(우연히 임시 포트 50k 사용) 권한 있는 네임서버 쿼리지포트 53에서.

방금 충돌이 일어났습니다.오른쪽이제 두 개의 개별 TCP 연결에 포트 50k를 사용하십시오.

나는 이것이 일반적으로 라우터에 서비스를 게시하지 않기 때문이라고 생각합니다. 그렇다면 TCP 포트 풀에서 포트를 "빌려오는" 것이 커널이 적극적으로 가장할 때 커널에 해를 끼치나요?

내 임시 포트를 내 포트와 결합할 수 있다는 것을 알고 있습니다 --to-ports. 그러나 이것이 기본 동작은 아닌 것 같습니다. NAT와 임시 포트 모두 기본적으로 32768-61000으로 설정되어 있는데, 이는 소름끼치는 일입니다.

(/proc/sys/net/ipv4/ip_local_port_range를 쿼리하여 임시 범위를 찾았고, 별도의 실험에서 단순히 많은 수의 UDP 요청을 NAT하고 서버 측에서 소스 포트를 인쇄하여 NAT 범위를 찾았습니다. iptables를 사용하여 범위를 인쇄하는 방법을 찾을 수 없습니다.

답변1

TCP 포트 풀에서 포트를 "빌려오는" 것이 커널이 활발하게 가장하고 있을 때 커널에 해를 끼치나요?

나는 대답이 "아니요, 하지만 상관없습니다"라고 생각합니다.

내가 잘못 추측한 거야오른쪽응답 패킷의 대상 전송 주소만 사용하여 패킷이 다음으로 향하는지 확인합니다.ㅏ아니면 그 자체. 실제로 연결을 식별하기 위해 전체 소스-대상 전송 주소 튜플을 사용하는 것으로 보입니다. 따라서 NAT가 동일한 연결을 사용하여 여러 연결을 생성하는 것은 실제로 정상입니다(오른쪽has) 포트가 있으면 혼동이 발생하지 않습니다. 따라서 TCP/UDP 포트 풀은 중요하지 않습니다.

지금 생각해보면 이는 너무나 당연한 일이다.

그런 다음 다음 클라이언트를 열려고합니다.오른쪽: nc -4 192.0.2.8 60000 -p 50000. 메시지를 보냈는데 아무 일도 일어나지 않았습니다. 패킷을 볼 수 없습니다오른쪽tcpdump.tcpdump.

이것은 내가 망친 실험의 일부입니다.

소스 때문에 실패가 발생합니다.그리고단지 소스 주소가 동일하기 때문이 아니라 대상 전송 주소도 동일합니다.

이렇게 하면 nc -4 192.0.2.8 60001 -p 50000실제로 작동합니다. NAT 마스크와 동일한 포트를 사용하더라도 마찬가지입니다.

NAT의 동작이 잘못된 것 같습니다. 실수로 masquerading(특히 iptables 규칙 중에 지정되지 않음) 및 services용 포트를 구성할 수 있었고 --to-ports커널은 자동으로 연결을 끊었습니다.

차폐 연결 때문에 그렇지 않습니다.오른쪽- 시작된 연결의 목적지가 다를 가능성이 높습니다.

변장 규칙이 존재하기 때문에, 아니면 적어도 활성화되어 있기 때문에 예상했을 것입니다.오른쪽두 개의 nc를 동일한 포트에 바인딩하면 발생하는 "nc: 주소가 이미 사용 중입니다"라는 오류 메시지와 함께 nc가 실패합니다.

나는 여전히 이 질문에 대한 확실한 답을 찾고 있지만 모든 것이 "이것은 구현 방식에 따른 부정적인 결과이며 우리가 기꺼이 감수할 만큼 작습니다."라고 지적하는 것 같습니다.

관련 정보