제 경우에는 브리지에 연결된 물리적 인터페이스가 인터넷에서 액세스할 수 없는 이유는 무엇입니까?

제 경우에는 브리지에 연결된 물리적 인터페이스가 인터넷에서 액세스할 수 없는 이유는 무엇입니까?

다음과 같은 네트워크 토폴로지가 있습니다.

(1.1.8.209) 는 em1인터넷을 통해 통신할 수 있는 물리적 인터페이스입니다. 두 개의 VM 인스턴스를 만들었습니다. PID 8740PID 8817둘 다 네트워크 IP를 사용하고 1.1.8.210/29, 1.1.8.211/29둘 다 공용 IP 주소를 사용합니다.

이제 인터넷을 통해 em1과 통신할 수 있습니다.

하지만 요구 사항이 있습니다. 두 가상 머신 모두에 직접 액세스하고 싶기 때문에 em1을 br0.

그런 다음 이것을 실행했습니다.

brctl addif br0 em1

토폴로지는 다음과 같습니다.

여기에 이미지 설명을 입력하세요.

하지만 이 명령을 실행한 후 오류가 발생하고 1.1.8.209더 이상 누구와도 통신할 수 없습니다. 그런 다음 첨부 파일을 삭제했고 brctl delif br0 em1이제 액세스할 수 있습니다 1.1.8.209.

왜 이 문제가 발생합니까? 잘 이해가 되지 않습니다. 이유를 설명해주세요.

답변1

인터페이스가 브리지 포트가 되면 더 이상 라우팅에 참여하지 않습니다.

기본 세부정보는 이 블로그에 설명되어 있습니다.Linux 브리지의 적절한 격리:

  1. 프레임을 전역 또는 장치별 프로토콜 처리기(예: IPv4, ARP, IPv6)에 전달합니다.

    브리지 인터페이스의 경우 커널은 장치별 수신 핸들러를 구성합니다. br_handle_frame()이 기능은 STP 및 LLDP 프레임을 제외하고 "라우팅"이 활성화된 경우를 제외하고 수신 인터페이스의 컨텍스트에서 추가 처리를 허용하지 않습니다. 그러므로,프로토콜 핸들러가 실행되지 않음이 경우.

이러한 브리지 포트의 IP 주소는 들어오는 패킷과 연결되지 않습니다. 그대로 놔두면 나가는 패킷의 올바른 라우팅이 중단됩니다. 이러한 패킷은 여전히 ​​브리지 포트를 통해 직접 전송될 수 있기 때문입니다(더 이상 보내서는 안 되는 경우).

수행해야 할 작업은 IP 주소를 브리지(또는 네트워크 네임스페이스 또는 동일한 위치에 있는 veth 쌍의 다른 자유 끝)에 연결된 반대편의 시스템으로 이동하거나 브리지의 자체 포트로 이동하는 것입니다. 항구, 즉 다리 자체. 이동 중에 중단이 발생하는 짧은 시간이 항상 있으므로 로컬에서 수행되는 이 구성에 대한 변경은 네트워크 액세스에 의존해서는 안 됩니다(예: 중단된 경로를 사용하는 셸을 통한 원격 키 입력에 의존해서는 안 됩니다). .

아래에서는 최신 구문이 포함된 최신 도구만 사용하겠습니다.

예를 들어:

ip address flush dev em1
ip address add 1.1.8.209/29 dev br0

대신, 또 다른 접근 방식은 브리지가 라우팅에 참여하지 않고 추가 정보를 사용하는 것입니다.와이즈동일한 네트워크 네임스페이스에서 라우팅에 참여하는 피어는 다음과 같습니다.

ip address flush dev em1
ip link add name em1twin type veth peer name br0portem1twin
ip link set br0portem1twin master br0 up
ip link set em1twin up
ip address add 1.1.8.209/29 dev em1twin

두 경우 모두 기본 경로(또는 다른 경로)가 해당 주소의 존재에 의존하는 경우 해당 경로가 사라지므로 해당 경로를 다시 추가해야 합니다.

관련 정보