☰

내부 네트워크에서는 고정 IP를 핑할 수 없으며 외부에서만 핑할 수 있습니다.

tag-icon • tag-icon networking ping localhost
내부 네트워크에서는 고정 IP를 핑할 수 없으며 외부에서만 핑할 수 있습니다.

저는 우분투를 실행하고 있고 Apache를 실행하고 있습니다. 그러나 내부적으로 고정 IP로 핑을 할 수 없고 http://207.40.XXX.XX고정 IP를 사용하여 웹 서버를 탐색할 수도 없습니다. 핑/탐색만 할 수 있어요localhost, 127.0.0.1, and 192.168.0.120 또는 207.40.XXX.XX외부 세계에서만.

# cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       my-server.myhost.com my-server

# hostname
my-server

# netstat -tapn
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -                  
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:29754         0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN

이것이 작동하지 않는 이유에 대한 아이디어가 있습니까?

답변1

NAT 게이트웨이가 이를 허용하는 방식으로 작동하지 않습니다. 아마도 작동하는 방식은 다음과 같습니다.

핑

  1. 192.168.0.5에서 207.40.123.45로 ICMP Echo 요청을 보냅니다.
  2. 이는 라우터를 통해 라우팅됩니다.
  3. 라우터 내부의 NAT 게이트웨이는 207.40.123.45(고정 IP 주소)에서 요청을 다시 작성합니다.
  4. 라우터가 ICMP Echo 요청에 응답합니다.
  5. 라우터는 ICMP 상태를 지원하지 않으므로 ECHO 응답을 사용자에게 다시 전달하지 않습니다.

HTTP

  1. 192.168.0.5에서 207.40.123.45로 TCP/80 연결 요청을 보냅니다.
  2. 이 경로는 라우터를 경유하여 이루어집니다.
  3. NAT 게이트웨이는 패킷이 수신될 때 다시 작성합니다.~에서207.40.123.45:41345 ~ 207.40.123.45:80
  4. NAT 게이트웨이는 포트 전달이 있음을 확인하고 패킷을 192.168.0.120:80으로 전달합니다.
  5. 192.168.0.120의 서버는 207.40.123.45:41345의 연결 시도에 응답합니다.
  6. NAT 게이트웨이는 응답을 보고 192.168.0.5:36311에 대한 응답의 To: 주소를 다시 쓰지만 From:은 그대로 둡니다(192.168.0.120:80).
  7. 192.168.0.5에 있는 컴퓨터는 192.168.0.120에서 요청하지 않은 패킷을 받아 바닥에 떨어뜨립니다.
  8. 연결이 약해지고 절대 열리지 않습니다.'

ping이 실패하는 이유는 HTTP도 실패하는 것과 같은 이유 때문일 수 있습니다. 이를 'NAT 헤어피닝'이라고 합니다.

필요한 것은 6단계에서 다음을 다시 작성할 만큼 똑똑한 NAT 게이트웨이입니다.원천주소.

답변2

1138의 대답은 정확하지만 "헤어핀 NAT"가 무엇인지, 어떻게 작동하는지, 그리고 이 상황에서 왜 필요한지에 대해 자세히 설명하고 싶었습니다. IP, NAT 및 라우팅의 핵심적인 세부 사항에 관심이 없다면 (다소 긴) 답변의 나머지 부분을 무시해도 됩니다.

헤어핀을 사용하지 않으면 로컬 LAN 클라이언트(192.168.0.5)에서 외부 IP 주소(207.40.123.45)를 통해 웹 서버로 HTTP 연결을 시도하는 동안 다음과 같은 일이 발생합니다.

  1. 192.168.0.5는 SYN 패킷을 207.40.123.45, 포트 80으로 보냅니다. 207.40.123.45는 로컬 네트워크에 없기 때문에 이 패킷은 기본 게이트웨이(예: 라우터)로 전송됩니다.

  2. 207.40.123.45:80을 192.168.0.120:80으로 전달하도록 구성된 라우터는 패킷의 대상 주소를 192.168.0.120으로 다시 쓴 후 웹 서버로 패킷을 전달합니다.

  3. 웹 서버는 SYN 패킷을 수신하고 응답 SYN-ACK 패킷을 보낸 사람의 주소로 다시 보냅니다.192.168.0.5. 192.168.0.5가 동일한 네트워크에 있으므로 웹 서버는 패킷을 192.168.0.5로 직접 전달합니다.

  4. SYN-ACK 패킷192.168.0.120192.168.0.5에 도착했지만 호스트는 192.168.0.120에서 SYN-ACK를 기대하지 않았으므로 삭제/거부되었습니다. 192.168.0.5의 호스트는 207.40.123.45의 응답 SYN-ACK를 계속 기다리지만 물론 해당 패킷은 결코 도착하지 않습니다. 몇 번의 재시도 후에 연결 시도가 결국 시간 초과되고 결국 클라이언트와 웹 서버가 연결을 설정하지 못하게 됩니다.

이 문제는 2단계에서 라우터가 "hairpin NAT"를 적용하여 해결할 수 있습니다. 간단히 말해서, 해결책은 클라이언트와 웹 서버가 라우터를 통해 상호 트래픽을 보내도록 속이는 것입니다. 이것은 영리하게 적용하여 수행됩니다.NAT의 두 번째 단계2단계에서는 일반적으로 포트 전달에 적용되는 한 단계에 추가됩니다. 다음은 헤어핀 NAT가 추가된 시퀀스입니다.

  1. 이전과 마찬가지로 192.168.0.5는 207.40.123.45, 포트 80으로 향하는 SYN 패킷을 라우터로 보냅니다.

  2. 이전과 마찬가지로 라우터는 SYN 패킷을 수신하고 구성된 포트 전달 규칙에 따라 대상 주소를 192.168.0.120으로 다시 씁니다. 그러나 이번에는 라우터가 패킷을 수신했던 동일한 네트워크로 다시 "헤어핀"할 것임을 알아차리고 패킷의소스 주소라우터의 자체 LAN 주소(예: 192.168.0.1)에 연결됩니다. 그런 다음 라우터는 패킷을 192.168.0.120의 웹 서버에 전달합니다.

  3. 웹 서버는 SYN 패킷을 수신하고 응답 SYN-ACK 패킷을 보낸 사람의 주소로 다시 보냅니다.192.168.0.1. 따라서 응답은 라우터로 돌아갑니다.

  4. 라우터는 웹 서버로부터 SYN-ACK를 수신하고 그것이 최근에 NAT(2번)한 패킷에 대한 응답임을 인식합니다. 따라서 라우터는 두 NAT를 모두 역전시키고 이제 응답 패킷의 소스 주소는 207.40.123.45이고 대상 주소는 192.168.0.5입니다. 따라서 응답은 192.168.0.5로 전달되고 TCP 연결 핸드셰이크가 계속되며 클라이언트와 웹 서버는 성공적으로 통신할 수 있습니다.

따라서 라우터의 헤어핀 지원을 통해 192.168.0.5의 호스트는 207.40.123.45의 웹 서버와 통신하고 있다고 생각하는 반면, 192.168.0.120의 웹 서버는 라우터 자체(192.168.0.1)의 클라이언트와 통신하고 있다고 생각합니다. 헤어핀을 적용하면 두 호스트가 실제로 동일한 네트워크에 있더라도 두 호스트 사이의 모든 트래픽이 라우터를 통과합니다. 이는 분명히 네트워크 리소스를 차선책으로 사용하는 것이며, 분할 DNS를 설정하는 것이 일반적으로 헤어핀에 의존하는 것보다 선호되는 주된 이유입니다.

답변3

어떤 종류의 방화벽을 사용하고 있나요? NAT 헤어핀이 켜져 있지 않은 것 같습니다.

관련 정보