정말 이상한 데비안 문제: 공용 IP에서 데비안에서 실행되는 서비스에 연결할 수 없으며 개인 IP에서는 잘 작동합니다.

정말 이상한 데비안 문제: 공용 IP에서 데비안에서 실행되는 서비스에 연결할 수 없으며 개인 IP에서는 잘 작동합니다.

우선 포트포워딩 문제는 아닙니다. tcpdump를 실행하면 debian 서버로 전달되는 요청을 볼 수 있고 그 후 요청이 중지됩니다.

내 데비안 서버는 PleX뿐만 아니라 Apache도 실행하고 있습니다. 192.168.1.210을 사용하여 Debian 서버에 연결하면 완벽하게 작동합니다. 웹페이지를 볼 수 있고 PleX에서 스트리밍할 수도 있습니다.

네트워크를 떠나 친구 집에 가도 접속할 수 없습니다. tcpdump를 사용하면 패킷이 서버에 도달하는 것을 볼 수 있지만 그게 전부입니다. canyouseeme.org와 동일합니다.

하다일부 라우팅 및 iptables가 마련되어 있습니다. 저는 이 컴퓨터를 토렌트 + VPN용으로 사용하므로 라우팅을 사용하여 모든 기능을 계속 작동시킵니다. 라우팅은 PleX를 VPN 인터페이스인 tun0에서 멀리 유지하도록 되어 있으며, iptables는 사용자 debian-transmission이 tun0 이외의 다른 인터페이스를 사용하지 못하도록 막아야 합니다.

 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.172.1.5      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
10.172.1.1      10.172.1.5      255.255.255.255 UGH   0      0        0 tun0
10.172.1.5      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
50.18.0.0       192.168.1.1     255.255.0.0     UG    0      0        0 eth0
54.241.0.0      192.168.1.1     255.255.0.0     UG    0      0        0 eth0
128.0.0.0       10.172.1.5      128.0.0.0       UG    0      0        0 tun0
184.72.0.0      192.168.1.1     255.255.192.0   UG    0      0        0 eth0
184.169.128.0   192.168.1.1     255.255.128.0   UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
216.144.236.186 192.168.1.1     255.255.255.255 UGH   0      0        0 eth0

IP테이블:

target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.1.0/24       owner UID match debian-transmission
REJECT     all  --  anywhere             anywhere             owner UID match debian-transmission reject-with icmp-port-unreachable

답변1

예를 들어 무슨 일이 일어나고 있는지 설명하는 것이 아마도 가장 쉬울 것입니다.

귀하의 NAT 라우터 IP 주소가 1.1.1.1이고 귀하의 친구 IP 주소가 2.2.2.2라고 가정해 보겠습니다. 단순화를 위해 귀하의 친구가 NAT 라우터 뒤에 있지 않다고 가정해 보겠습니다(그렇다면 예제가 약간 더 복잡해집니다. 근본적으로 문제를 바꾸지는 않습니다. 또한 포트 전달이 외부 IP의 포트 80을 데비안 상자의 포트 80으로 전달한다고 가정하겠습니다.

친구의 컴퓨터는 소스 주소 2.2.2.2, 무작위로 선택된 소스 포트(예: 12345), 대상 주소 1.1.1.1, 대상 포트 80으로 구성된 syn 패킷을 보냅니다.

패킷은 NAT에 도달하고 포트 전달을 조회하고 대상 IP를 192.168.1.210으로 변경합니다. 소스 IP는 2.2.2.2로 유지되고 포트는 동일하게 유지됩니다. 지금까지는 반환된 패킷에 대해 역변환이 수행될 수 있도록 매핑이 생성되었습니다.

패킷이 서버에 도달합니다. 이는 응답으로 ack 패킷을 생성하는 TCP 스택으로 전달됩니다. 일반적으로 패킷이 소스와 대상에 응답할 때 교환됩니다. 따라서 패킷의 소스 주소는 192.168.1.210, 대상 주소는 2.2.2.2, 소스 포트는 80, 대상 포트는 12345입니다.

응답은 TCP 스택을 떠나 iptables에 도달합니다. 규칙이 UID 일치를 수행하므로 소유자 일치가 올바르게 작동하므로 패킷이 그곳을 통과해야 합니다.

그런 다음 라우팅 테이블에 도달합니다. VPN을 통해 전송됩니다. 어떤 방식으로든 소스를 수정하는 VPN의 NAT에 도달하여 친구에게 다시 돌아오다가 잘못된 소스 주소로 인해 삭제됩니다.

가능한 수정 사항: 1: 라우팅 테이블에 친구 IP를 추가하세요. 확실히 확장성이 좋지 않고 토렌트 트래픽이 누출될 수 있습니다. 2: nat 박스가 적절한 리눅스 시스템이라면 들어오는 연결의 소스와 대상을 변경하도록 구성하는 것이 가능해야 합니다. 따라서 토렌트 상자는 인터넷에서 친구 시스템을 보는 대신 NAT 상자를 소스로 봅니다. 3: Linux의 "고급 라우팅" 기능을 사용하여 소스 포트를 기반으로 라우팅합니다. 불행하게도 고급 라우팅 기능은 매우 강력하지만 이해하기 어렵습니다. 이 경로에 대한 더 많은 정보를 원하시면 "리눅스 고급 라우팅 및 트래픽 제어 방법"을 확인하십시오.

관련 정보