적어도 Arch Linux에서는 이것이 기본 설정입니다. 나는 이것이 관리되지 않는 스위치처럼 동작해야 하고 이제 대부분의 순방향 체인에 대한 기본 정책이 패킷을 삭제하는 것이기 때문에 브리지 동작을 직관적이지 않게 만든다고 생각합니다.
이러한 기본값 뒤에 어떤 이유가 있습니까?
답변1
이 기능사용 증가 허용ebtables사용시iptables브리지 경로에 라우터 대신 상태 저장 방화벽 브리지를 구현합니다. 그것오랜만이네요(2002)처음에는 스위치가 없으며 브리지 코드의 일부입니다. 브리지와넷필터 지원이 활성화되었습니다,역시 그렇군요.
그 다음에2003년에 추가된 스위치. 물론 호환성상의 이유로 기본 설정은 활성화되어 있습니다.
그 다음에커널은 3.18입니다.br_netfilter이 기능으로 인해 발생할 수 있는 문제로 인해 이 기능은 자체 커널 모듈로 분리되었습니다. 사람들은 호환성에 대해 걱정하고 있으며 이미 호환성을 중단할 계획이 있습니다.nftables:
이로 인해 호환성이 손상됩니다. [...] 그러나 br_netfilter 를 modprobing하면 손상을 쉽게 제거할 수 있습니다.
게다가 nftables의 계획은 이 소프트웨어 계층에 의존하지 않고 대신 연결 추적을 브리지 계층에 통합하여 브리지 넷필터 사용자가 원하는 상태 저장 필터링 및 NAT를 활성화하는 것입니다.
이 기능이 제대로 작동하려면 이제 커널 모듈을 로드해야 합니다. 그러나 주요 알려진 고객은 일반적으로 모든 브리지 상태 저장 방화벽 설정에서 발견됩니다.iptables표적physdev어느br_netfilter호환성상의 이유로 다시 자동 로드.
따라서 간단한 시스템에서는 br_netfilter로드되거나 로드되어서는 안 됩니다.시스템 제어: net.bridge, bridge-nf-call-arptables, bridge-nf-call-ip6tables( bridge-nf-call-iptables및 bridge-nf-filter-pppoe-tagged, bridge-nf-filter-vlan-tagged, ) bridge-nf-pass-vlan-input-dev내에서 사용 가능한 콘텐츠는 전혀 표시되지 않아야 합니다.
하지만 이제 이 커널 모듈에는 Docker라는 새로운 주요 고객이 있습니다. 이 문제가 발생하는 일반적인 방법은 Docker를 실행할 때입니다.Docker 명시적 로딩br_netfilter컨테이너 간 내부 통신을 제어하는 동시에기본적으로 전달된 패킷을 필터링하고 삭제합니다.. 결과적으로 사람들은 종종 예상하지 못한 상황에서도 해당 동작이 사용되는 것을 발견하거나 실제로 다시 발생해서는 안되는 동작이 예상된다고 생각합니다.
기본 설정은 시스템 전체이므로 Docker가 관리하는 브리지 외에도 시스템의 다른 모든 브리지, 즉 초기 호스트 네임스페이스의 브리지뿐만 아니라어느기타 네트워크 네임스페이스.
비슷하게,iptables'physdevbr_netfilter자신의 모듈( ) 자체가 로드될 때만 자동으로 로드됩니다. xt_physdev(예전에는 이보다 더 자주 발생했습니다.)이번 패치). 방법 참고해주세요수리하다설명은 다음과 같습니다.
더 나은 해결 방법은 "call-iptables" 기본값을 0으로 변경하고 명시적 설정을 1로 강제하는 것입니다.하지만 이로 인해 이전 버전과의 호환성이 손상됩니다..
이 모든 것이 이 질문에 대한 답을 제공합니다.
이는 이전 버전과의 호환성을 위한 것입니다.
추가 참고 사항.
xt_physdev커널 모듈이 현재 로드되지 않은 시스템에서는 br_netfilter사용자 네임스페이스를 실행하는 일반 사용자만 다음 작업을 수행할 수 있습니다.
$ unshare -urnm
# iptables -A FORWARD -m physdev --physdev-is-bridged
# exit
$
특수하고 외관상 쓸모없는 규칙을 사용하는 공격으로부터 자신을 보호하지 않는 시스템(가상 머신, 컨테이너...)에 설치된 다른 기술의 LAN 연결을 중단할 수 있습니다.
iptables -P FORWARD DROP
Netfilter 문서 페이지에서는 이러한 효과를 설명하고 브리지 경로, 라우팅 경로, ebtable 및 iptable 간의 상호 작용을 설명합니다. Linux 기반 브리지의 ebtables/iptables 상호 작용. 이것7부어떤 종류의 보호를 추가해야 하는지 설명하므로 특히 유용합니다. 예를 들면 다음과 같습니다.
iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -d 172.16.1.0/24 -j ACCEPT iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -j MASQUERADE
위의 첫 번째 규칙은 동일한 LAN의 주소 간 패킷이 IP 계층에서 전달되지 않고(즉, 라우팅) 이더넷 계층에서 프레임으로 전달(브리징/스위칭)되기 때문에 별 의미가 없습니다. 경로가 아닌 교량 및 교량으로 간주되므로 일치합니다.iptables레이어 3: IPv4에서만 작동할 것으로 예상됩니다. 그러나 br_netfilter로드되면 이러한 유형의 "죽은 규칙"이 필요합니다. 그렇지 않으면 브리지 경로의 레이어 2에서 라우팅 전용 작업이 발생합니다(여기에 표시된 대로: NAT는 동일한 LAN에 있는 두 노드 간에 브리지됩니다. 첫 번째 규칙 없이 완료됨). ).
사람들은 (수년 동안) 그것에서 벗어나려고 노력해 왔지만 br_netfilter기능적 동등성이 필요합니다. 이는 커널 5.3을 통한 IP 및 IPv6(ARP인 것 같습니다)의 구현과 비슷합니다.nftables및 커널 모듈nf_conntrack_bridge이를 통해nftablesbridge가족 중에( 또는 트리거 와 같은 계열이 ip아님 ) 사용ip6inetbr_netfilter연결하다:
이는 "br_netfilter" 인프라를 대체합니다.
상태 필터링
Bridge 시리즈는 Linux 커널 5.3부터 연결 추적을 지원합니다.
이를 활성화하려면 규칙 세트의 conntrack 상태 정보와 일치시키기만 하면 됩니다.
iptable에 익숙한 사람들을 위해:이는 br_netfilter에 대한 대안을 제공하고 iptables의 -m physdev와 일치합니다..
그러나 VLAN 캡슐화/캡슐화 해제와 관련된 다른 기능, 특히 PPPoE 프로토콜은 아직 준비되지 않았습니다.
또한 커널 5.3부터는 네트워크 네임스페이스 전체 기능을 비활성화하고 네트워크 네임스페이스별 또는 브리지 기준에서만 활성화할 수 있습니다. 그러나 이는 생성된 모든 새 네임스페이스(초기 네트워크 네임스페이스 포함) 내에서 다음과 같이 초기에 실행되어야 합니다.
sysctl -w net.bridge.bridge-nf-call-arptables=0
sysctl -w net.bridge.bridge-nf-call-iptables=0
sysctl -w net.bridge.bridge-nf-call-ip6tables=0
ip link add ...그런 다음 브릿지 생성 시간( ) 또는 그 이후( ip link set ...) 에 이를 필요로 하는 신중하게 선택된 브릿지에 대해 다음을 수행합니다 .
ip link set somebridge type bridge nf_call_iptables 1
Docker 및 기본 설정iptables설정에서는 이를 처리할 수 없으므로 Docker는 이러한 설정을 사용하는 호스트에서 동시에 실행될 수 없지만 Docker-in-Docker(실제로 같은 이유로 Docker가 아닌 LXC와 같은 다른 컨테이너 기술에서)는 각각의 기본값이므로 좋을 수 있습니다. 새 네임스페이스는 여전히 이전 버전과 호환됩니다.