2013-06-14 9 views
2

전달 연결을위한 iptables 규칙이 여러 개 있습니다.iptables/ebtables/bridge-utils : 단일 NIC를 통해 다른 서버로 PREROUTING/FORWARD를 전송

예를 들어, 포트 80은 동일한 시스템 (웹 서버)의 포트 8080으로 전달됩니다. 주어진 웹 서버가 다시 시작될 때 우리는 유지 보수 페이지를 표시하는 포트 8080의 다른 IP로 요청을 전달합니다. 대부분의 경우이 IP는 별도의 서버에 있습니다.

우리는 bridge-utils를 설치할 때까지 완벽하게 작동했으며 eth0 대신 인터페이스 br0로 변경했습니다.

우리가 브리지 인터페이스를 사용하여 변환 한 이유는 ebtable의 MAC SNAT/DNAT 기능에 액세스하기 위해서입니다. 서버에 브리지 인터페이스를 추가 할 다른 이유는 없습니다. 실제로 여러 인터페이스에서 연결을 브리지하지 않기 때문입니다.

나는 이것이 서버에 브리지를 추가하는 이상한 이유라고 알고 있지만, 우리는 새로운 프로젝트에서 MAC SNAT/DNAT 기능을 사용하고 있으며 ebtables는 우리가 가장 안전하고 신속하고 쉬운 방법이라고 생각됩니다. 이미 iptables에 익숙합니다.

문제는 br0 인터페이스로 변환 한 후 iptables PREROUTING 외부 서버로의 전달이 더 이상 작동하지 않는다는 것입니다.

내부 PREROUTING 전달이 잘 작동합니다 (예 : 요청이 포트 80에서 수신되면 포트 8080으로 전달).

OUTPUT 체인도 작동합니다 (예 : 로컬 대상 IP : 8080을 통해 상자에서 외부로 연결할 수 있으며 OUTPUT 체인은이를 다른 서버의 포트 8080에있는 유지 서버 IP에 매핑하고 웹 페이지를 반환합니다).).

그러나 목적지 IP가 외부 인 경우 PREROUTING 규칙 이후에 상자로 들어오는 모든 트래픽은 죽는 것처럼 보입니다. 여기

는 우리의 설치의 예입니다

올드 설정 :

 
iptables -t nat -A PREROUTING -p tcp --dport 9080 -j DNAT --to-destination $MAINTIP:8080 
iptables -a FORWARD --in-interface eth0 -j ACCEPT 
iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE 
echo 1 > /proc/sys/net/ipv4/ip_forward 

새로운 설정 : (다양한 형식으로 된 설치뿐만 아니라 시도 ..., eth0를하고 BR0 패킷을 기록하려고)

 
iptables -t nat -A PREROUTING -p tcp --dport 9080 -j DNAT --to-destination $MAINTIP:8080 
iptables -a FORWARD --in-interface br0 -j ACCEPT 
iptables -t nat -A POSTROUTING --out-interface br0 -j MASQUERADE 
echo 1 > /proc/sys/net/ipv4/ip_forward 

BR0을 변경하기 전에 클라이언트 요청은 다른 서버 $의 MAINTIP에 떨어져 매스 커 레이드 후 포트 9080에서 서버 A로 이동 한 것입니다.

위에서 설명한 것처럼 $ MAINTIP가 동일한 컴퓨터에 있으면 좋지만 다른 서버에있는 경우 새 br0 설치 아래에서 패킷이 $ MAINTIP에 보내지지 않습니다.

단일 NIC 브리지 (br0/bridge-utils)를 사용하여 전환하기 전에 패킷이 들어 왔던 것과 동일한 인터페이스 (MASQUERADED)로 나가기를 원합니다.

iptables의 모든 단계에서 로깅을 추가해 보았습니다. 어떤 이유로 iptables TRACE 대상이이 설정에서 작동하지 않으므로 TRACE 로그를 가져올 수 없지만 패킷이 PREROUTING 테이블에 나타나지만 그 후에는 자동으로 삭제됩니다.

나는이 훌륭한 문서를 사라와의 iptables와 ebtables 사이의 흐름에 대한 이해가했습니다 내 이해에서 http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html

, 다리가 동일한 인터페이스에서 패킷을 전달하지 않는 것 같다 그들이 들어 와서 그들을 떨어 뜨리고 있습니다. 두 번째 인터페이스가 추가 된 경우 인터페이스 (브리지의 다른 쪽)에서 브리지를 전달하는 것이 상상됩니다 .- 다리가 작동하는 방식입니다 .-)

우리가 원했던 방식대로 작동하고, 예전과 같은 인터페이스를 통해 패킷을 전달/전달할 수 있습니까?

iptables 전달/전달/POSTROUTING 규칙과 함께 작동하여 일부 iptables 규칙이 iptables 전달 작업을 일반적으로하는 방식으로 만들고 ro0 (eth0) 대신 라우트 된 패킷을 보내길 바란다. 그 (것)들을 떨어 뜨리기의.

댓글, 불꽃, 모든 조언을 환영합니다!

안부, 닐

답변

1

나는, 당신은 다리에 eth0를 추가 않았다 당신이 한 생각, 그러나 다만 확실하게?

나는 문제가 무엇인지 확실하지 않다,하지만, 난 당신이나 다른 디버깅 다리/ebtables/iptables에 문제 도움을 수있는 몇 가지 디버깅 팁을 줄 것이다 :

것이 있는지 확인을하는 "/ proc 디렉토리/SYS/순/bridge-bridge-nf-call-iptables "이 활성화 됨 (1)
이렇게하면 브리지 트래픽이 netfilter iptables 코드를 통과하게됩니다.

성능에 영향을 줄 수 있습니다. ebtabels/iptables에 규칙에 의해 패킷 차단에 대한

확인,
사용 명령 :

iptables -t nat -L -n -v 

ebtables -t nat -L –Lc 

이 트래픽 일치 및 차단되지 않거나 이해하는 데 도움이 될 수 있습니다.
확인 IP NAT 트래픽이 작성한 conntrack 테이블에 나타납니다 :

brctl showmacs br0 

사용 tcpdump와의 eth0를에와 BR0에 다리의

conntrack –L (if installed) 

또는

cat /proc/net/nf_conntrack 

확인 MAC 학습 두 패킷 모두에서 예상대로 확인하십시오.
MAC 주소도 보려면 -e 옵션을 사용하십시오.

디버깅,

아마 설정 다리 순방향 지연 0

에 (그것뿐만 아니라 다른 MAC을 수락 무차별 모드) 아마 다리 다른 MAC 주소를 사용하여 패킷을 수신하고, 무차별 모드 브리지 인터페이스를 전환하려고
brctl setfd br0 0 

비활성화 STP (스패닝 트리 프로토콜)

brctl stp br0 off 

는 라우팅 테이블처럼 보이는 무엇입니까?
"dev에 BR0"

내가 조금 도움이되기를 바랍니다

...

1

음 1.5 세 행운으로 특정 또는 기본 경로 규칙을 추가 시도하지만 나중에 조회를 위해 유용 할 수있다. 지금 막 당신의 링크를 보면, MAC이 브리지의 같은쪽에 있고 (다른 포트 나 브리지 자체가 아닙니다.) (그림 2.b 참조)

그 때문에, 단순히 링크 인용 : http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxBridge

를 "... ebtables DROP을 iptables에 대부분의 경우에 드롭 타겟 수단은 네트워크 트래픽을 필터링하는 데 사용되는 iptables에에서

을 DROP 대"패킷 "사라지게.

ebtable에서 "-j redirect --redirect-target DROP"은 "패킷이 브리지에서 t 그는 라우팅 \ 포워딩과 같은 커널의 상위 계층 "(< - 관련 비트!)

ebtable은 연결을 가로 채기 위해 연결의 링크 계층에서 작동하기 때문에 우리는 트래픽을 iptables가 \ tproxy를 가로 챌 수있는 레벨.

여기에 답변이 있습니다 (아직 방문하지 않는 한 장래의 방문자에게는 베팅이 추가됩니다)