두 개의 물리적 인터페이스 eth1과 eth2가 있다고 가정해 보겠습니다.
eth1에는 192.168.0.1이 할당되었습니다.
eth2에는 192.168.0.2가 할당되었습니다.
하나의 로컬 프로세스는 192.168.0.2에서 수신 대기하고 다른 로컬 프로세스는 192.168.0.1에서 연결됩니다.
ip 패킷이 iptable의 OUTPUT 및 INPUT 체인을 통과합니까, 아니면 일종의 단락이 있습니까? FORWARD 체인을 통과하나요?
답변1
교통은 정해진 경로를 따릅니다.
그렇다면 어느 것이 될지 어떻게 알 수 있나요? 경로를 확인하여. 여기서는 호스트에 속한 주소에서 호스트에 속한 주소로 이동합니다. lo
이 경우에는 NIC 하드웨어가 포함될 필요가 없으므로 항상 선택(루프백) 인터페이스가 발생합니다 .
클라이언트가 먼저 192.168.0.1에 바인딩하는 경우(거의 발생하지 않음):
$ ip route get from 192.168.0.1 to 192.168.0.2
local 192.168.0.2 from 192.168.0.1 dev lo uid 1000
cache <local>
이는 일반적으로 발생합니다(그러나 전체 결과는 동일함).
$ ip route get to 192.168.0.2
local 192.168.0.2 dev lo src 192.168.0.2 uid 1000
cache <local>
이 결과의 결론을 강조하자면 다음과 같습니다.안 돼요eth0
또는 을 사용 eth1
하지만 을 사용합니다 lo
.
Netfilter(따라서iptables) 네트워크 스택을 따라 작업합니다(라우팅 스택 부분은 다음과 같습니다).
통과제인 엔젤하트- 자신의 작품, 유래정적 변수 생성기 파푸아 뉴기니,CC-SA 3.0,협회
로컬 애플리케이션은 패킷을 보냅니다. 이것이 필터/출력 체인입니다. 또한 다른 체인(다른 OUTPUT 및 POSTROUTING 체인)을 순회하지만 필터 테이블에만 관심이 있습니다. 패킷이 루프백됩니다. 이는 인터페이스의 특수 속성입니다 lo
. 이는 라우팅 스택에 새 패킷처럼 도착하므로 라우팅 결정을 내리기 위해 PREROUTING 처리(그러나 PREROUTING 체인은 필터 테이블에 연결되지 않음)를 따릅니다. 로컬 대상 패킷이므로 INPUT 분기도 따릅니다. 패킷이 대상 애플리케이션에 도달합니다.
표준 Linux 상태 저장 방화벽iptables최소한 다음 규칙을 사용하십시오( -I
나는 일반적으로 규칙의 순서를 강제하기 위해 +숫자를 사용합니다 -A
).
iptables -I INPUT 1 -m conntrack --ctstate established,related -j ACCEPT
iptables -I INPUT 2 -i lo -j ACCEPT
그런 다음 일반적으로 해당 정책은 DROP으로 설정됩니다.
iptables -P INPUT DROP
두 번째 규칙은 특정 환경에서 보안 약점으로 간주될 수 있지만 루프백 인터페이스를 통해 통신할 수 있기를 원하는 많은 응용 프로그램이 이 규칙 없이는 실패할 수 있기 때문에 종종 존재하고 필요합니다.
따라서 이러한 사용을 방지해야 하는 규칙은 두 번째 규칙 앞에 삽입되어야 합니다. 또한 해당 인터페이스의 주소가 아닌 인터페이스를 기반으로 하는 규칙은 로컬 상황을 해결하지 못합니다.
따라서 두 번째 규칙을 제거하면 다음과 같습니다.
iptables -D INPUT -i lo -j ACCEPT
그런 다음 예를 들어 OP의 예와 함께 사용되는 HTTP 서비스 예외를 허용합니다.
오류(OP의 상황과 일치하지 않음):
iptables -I INPUT 2 -i eth2 -p tcp --dport 80 -j ACCEPT
허용:
iptables -I INPUT 2 -d 192.168.0.2 -p tcp --dport 80 -j ACCEPT
또한 허용되며 일반적으로 수행됩니다.
iptables -I INPUT 2 -i lo -j ACCEPT iptables -I INPUT 3 -i eth2 -p tcp --dport 80 -j ACCEPT
정확히 동일하지는 않습니다. 예를 들어, 측면의 클라이언트는 eth1
사례 3을 사용하여 HTTP 서비스에 액세스할 수 없지만 사례 2를 사용하면 HTTP 서비스에 액세스할 수 있습니다. 마찬가지로, 수신 대기 서비스가 192.168.0.2 대신 INADDR_ANY(0.0.0.0)를 수신하는 경우 127.0.0.1에 액세스하는 것은 사례 2에서는 작동하지 않지만 사례 3에서는 작동합니다.