☰

iptables - INPUT DROP이 FORWARD 규칙을 무시합니까?

tag-icon • tag-icon networking iptables routing
iptables - INPUT DROP이 FORWARD 규칙을 무시합니까?

최근에 홈 네트워크의 Debian 서버에 클라이언트 VPN을 설치했습니다. 네트워크의 일부 장치에 대한 또 다른 게이트웨이로 사용하고 싶습니다. 이것은 제가 성공한 것이므로 모두 좋습니다. 단지 여러분에게 배경 이야기를 제공하고 싶었습니다.

이제 iptables -P INPUT DROP을 사용하지 않는 한 VPN을 통해 WAN을 통해 연결할 수 있는 RDP 서버(WS 2019)가 있습니다. 그런데 포트포워딩을 사용하고 있는데 왜 이 포트들이 작동하지 않는지 헷갈립니다. 나는 어제 iptables를 사용하기 시작했기 때문에 이것은 아마도 매우 분명한 것일 수 있지만 Google에서 검색하는 방법을 모르겠습니다.

내 설정:

$ iptables -L -n  
Chain INPUT (policy DROP)  
target    prot opt source               destination         
ACCEPT     tcp  --  192.168.0.0/24      0.0.0.0/0            tcp dpt:22  
Chain FORWARD (policy ACCEPT)  
target     prot opt source               destination  
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:11111  
Chain OUTPUT (policy ACCEPT)  
target     prot opt source               destination      


$ iptables -L -n -t nat  
Chain PREROUTING (policy ACCEPT)  
target     prot opt source               destination  
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:11111 to:192.168.0.50:3389 <-(RDP server)  
Chain INPUT (policy ACCEPT)  
target     prot opt source               destination  
Chain POSTROUTING (policy ACCEPT)  
target     prot opt source               destination  
SNAT       all  --  192.168.0.0/24      0.0.0.0/0            to:[my public VPN IP]  
Chain OUTPUT (policy ACCEPT)  
target     prot opt source               destination

분명히 말하면 모든 것이 다시 작동하도록 하기 위해 해야 할 유일한 일은 "입력" 정책을 "수락"으로 설정하는 것이었지만 WAN에 대한 라우터였기 때문에 그렇게 하고 싶지 않았습니다.

그렇다면 INPUT의 정책은 순방향 체인 트래픽도 정의합니까? DROP 정책을 사용하고 여전히 11111 트래픽을 로컬 RDP 서버의 3389로 전달할 수 있도록 이 문제를 해결하려면 어떻게 해야 합니까?

답변1

트래픽이 실제로 Windows Server에 도달하는지 확인하려면 패킷이 삭제되기 전에 기록되도록 방화벽 스크립트 끝에 "-J LOG"를 추가하는 것이 좋습니다. 패키지가 삭제되는 것이 표시되지 않으면 Windows 방화벽이 해당 패키지를 삭제하는 것일 수 있습니다. 또한 이 설정이 진행 중인 작업일 수 있다는 것을 알고 있지만 방화벽에서 FORWARD 체인의 기본 대상으로 ACCEPT를 사용하는 것은 전혀 권장하지 않습니다. 이는 매우 위험할 수 있기 때문입니다. 또한 터미널 서비스 로그(위치는 확실하지 않음)를 확인하여 Windows가 어떤 이유로든 연결이 끊어지지 않고 수신되고 있는지 확인할 수도 있습니다.

도움이 되었기를 바랍니다.

답변2

SSH 포트를 INPUT 규칙으로 전달한 다음 가져오기만 하면 iptables -P INPUT DROP들어오는 ICMP가 차단됩니다.

모든 최신 운영 체제(적어도 Windows 95 이후)는 TCP 연결에서 PMTUD(Path MTU Discovery)를 사용합니다. MTU = 최대 전송 단위, 기본적으로 두 개 이상의 작은 패킷(조각)으로 분할하지 않고 전송할 수 있는 가장 큰 패킷의 크기입니다.

기본적으로 최신 운영 체제는 해당 홉의 최대 패킷 크기가 일반 최대 패킷보다 작기 때문에 특정 네트워크 홉을 통과하지 않는다는 것을 라우터 어딘가에서 발견한 경우 항상 "조각화 안 함" 플래그가 설정된 패킷을 보냅니다. 크기가 다르면 라우터가 ICMP "조각화 필요" 패킷을 다시 보낼 것이라고 예상할 것입니다. 이 패킷에는 조각화되지 않은 상태로 전달할 수 있는 최대 패킷 크기에 대한 정보도 포함되어 있습니다. ICMP 메시지를 받으면 지정된 크기를 사용하기 시작합니다. 패킷 크기가 제한된 홉에서 이 프로세스가 반복되면 TCP 연결은 조각화 없이 원본에서 대상까지 전달될 수 있는 최대 패킷 크기를 자동으로 찾습니다. 그 사이의 모든 라우터는 최적의 효율성으로 작동합니다.

모든 ICMP를 차단함으로써 이미 작업에 흠집을 낸 것입니다. 아마도 귀하의 서버가 최대 크기의 패킷을 보내려고 하는데 다른 무언가가 "이것은 적합하지 않습니다. MTU를 조금 낮추십시오"라고 말하려고 할 것입니다. 그러나 들어오는 ICMP가 차단되기 때문에 서버는 연결 시간이 초과될 때까지 의도한 수신자에게 도달하지 않는 최대 크기의 패킷을 계속 보내려고 시도합니다.

VPN도 사용합니다. VPN 터널로 들어가는 모든 패킷에는 두 번째 주소 헤더 세트(암호화 및/또는 VPN 자체 요구에 대한 일부 오버헤드 추가)가 앞에 추가되어야 하기 때문에 대부분의 VPN 연결은 MTU를 특정 값으로 제한합니다. 이 값은 다음보다 약간 작습니다. 이더넷의 기본값입니다. 따라서 작동하려면 반드시 PMTUD가 필요합니다.

다양한 클라우드 기반 서비스의 MTU 값도 약간 낮을 수 있지만 모든 서비스의 MTU 값이 완전히 동일한 것은 아닙니다. 따라서 더 작은 MTU 값을 수동으로 설정하는 것은 이상적이지 않습니다.

ICMP를 읽고 처리하기에 충분히 안전하다고 생각되는 ICMP 패킷과 방화벽에 삭제할 ICMP 패킷을 스스로 결정해야 합니다.

또한 최신 운영 체제에는 기본적으로 ICMP 기반 공격에 대한 일부 보호 기능이 이미 포함되어 있다는 점을 알아야 합니다. 예를 들어 ICMP 오류 메시지를 보내는 것은 작동하는 연결을 처리하는 것보다 우선 순위가 낮은 것으로 간주되는 경우가 많습니다. 그리고 나가는 ICMP 메시지의 수는 이미 운영 체제 커널 자체에 의해 속도가 제한되어 있을 수 있습니다. 네트워크 프로토콜 코드 개발자는 일반적으로 완전한 바보가 아닙니다.

관련 정보