OpenVPN을 통한 두 보드 사이의 격리된 TAP 브리지
브리지는 구성원 포트 사이로 프레임을 전달하며, 호스트 주소는 브리지 자체에 속합니다. 관리를 노출하지 않고 벤치 포트를 연결하십시오.
두 개발 보드가 하나의 Ethernet 세그먼트를 공유해야 하지만, 그 벤치는 서로 다른 건물에 있습니다. 터널은 이미 존재하고 이미 Ethernet을 운반하므로, 남은 작업은 세 개의 명령처럼 보이지만 그렇지 않습니다. 호스트가 브리지된 프레임으로 무엇을 하는지, PC 자체의 주소가 어디에 속하는지, 브리지가 만들지 않는 경계가 무엇인지는 세 가지 별개의 사실이며, 두 번째를 틀리는 것이 실험실이 간헐적으로 동작하고 관리 접근이 조용히 나빠지는 흔한 이유입니다. 이 세 가지 사실 중 어느 것도 토폴로지 다이어그램에는 보이지 않습니다.
아래 경로는 두 Linux PC 사이의 인증된 TAP 연결, 벤치마다 하나의 전용 유선 포트, 실험의 일부가 아닌 관리 인터페이스를 가정합니다. 순서가 중요합니다. 먼저 프레임, 다음 주소, 마지막 경계입니다.
브리지가 실제로 옮기는 것
브리지는 소프트웨어로 구현된 스위치입니다. 어떤 MAC 주소가 어떤 구성원 포트 뒤에 나타나는지 학습하고, IP 라우팅 테이블을 참조하지 않고 구성원 사이로 프레임을 전달합니다. 그 설명에는 서브넷, 게이트웨이, 기본 경로가 없습니다. 그래서 IP 전달을 활성화해도 이 연결이 생기지 않고, ping이 성공해도 다른 트래픽은 계속 실패할 수 있습니다. 보드는 기본 경로를 전혀 구성하지 않고도 상대에 도달할 수 있으며, 이는 두 번째 계층이 세 번째 계층처럼 동작하리라 기대하는 사람을 놀라게 합니다.
각 PC는 유선 포트 하나를 브리지에, TAP 장치를 같은 브리지에 제공하므로, 보드의 프레임은 로컬 포트로 들어가 TAP 장치로 전달되고, 터널을 건너 상대의 TAP 장치에 도착한 뒤 상대의 보드로 전달됩니다. 터널은 다른 구성원 포트와 같으며, 브리지는 뒤에 VPN이 있다는 것을 알지도 신경 쓰지도 않습니다. 이 대칭성 덕분에 예제를 이해하기 쉽습니다. 각 측에는 실험실을 향한 포트 하나와 터널 포트 하나가 있고, 어느 쪽도 특별하지 않습니다.
Board A -- bench0 -- br-test -- tap-bench
| OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench두 PC의 동일한 이름은 로컬 이름이며 공유 객체가 아닙니다. 벤치 사이에는 하나의 Ethernet 경로가 있고, 두 번째 케이블도 루프를 닫는 두 번째 터널도 없습니다. 같은 MAC이 두 포트로 도착하는 것을 본 브리지는 기꺼이 원을 그리며 전달합니다.
구성원 포트가 아니라 브리지에 주소를 주십시오
실험실 세그먼트에서 PC의 정체성은 브리지 장치에 속합니다. 구성원 포트는 번호가 없습니다. 포트는 전달 구성원이고 그 위의 주소는 같은 세그먼트의 두 번째 경쟁 소유자를 만들기 때문입니다. 이것이 대부분의 수작업 레시피가 틀리는 수정점입니다. TAP 장치와 브리지 모두에 주소를 주고 나서 상대가 실제로 어느 쪽에 도달하는지 궁금해합니다.
ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up상대는 다른 호스트 주소로 같은 형태를 사용하고, 보드는 필요하면 PC의 브리지 주소를 다음 홉으로 삼아 같은 범위의 주소를 받습니다. 계획이 합의될 때까지 문서용 범위를 사용하고, 사무실이 이미 라우팅하는 것과 충돌하지 않도록 범위를 예약하십시오. 실행하기 전에 구성원 포트에 남은 주소, DHCP 클라이언트, 다른 브리지 소속이 없는지 확인하고, TAP 장치의 주소 지정을 터널 구성을 소유한 쪽을 통해 조정하여 나중에 주소를 복원하지 않도록 하십시오.
벤치마다 전용 포트가 하나인 이유
전용 유선 포트가 실험을 사무실 전체의 변경으로 만들지 않게 막습니다. 관리 인터페이스는 SSH, 기본 경로, 외부 VPN 연결을 운반하며, 그중 어느 것도 실험실 프레임을 옮기는 것이 목적인 브리지에 속하지 않습니다.
관리 어댑터를 연결하면 사무실 LAN이 개발 보드로부터 한 번의 전달 결정 거리에 놓입니다. 두 번째 계층에서 잘못 동작하는 보드는 바로 그 세그먼트에 두고 싶지 않은 종류의 장치입니다. Wi-Fi 어댑터는 더 나쁩니다. 인프라 모드의 무선 인터페이스를 브리지하는 것은 Ethernet 브리지처럼 동작하지 않으며, 실패는 깔끔하지 않고 혼란스럽습니다.
실험실 범위를 어떤 프로덕션 DHCP 범위에서도 빼십시오. 보드에 나중에 동적 주소 지정이 필요하면 하나의 풀을 가진 하나의 승인된 할당자만이 예측 가능하게 유지됩니다. 같은 세그먼트에서 응답하는 두 사이트의 일반 라우터는 아무도 설명할 수 없는 주소를 만들어냅니다.
브리지가 만들지 않는 경계
브리지는 라우팅이 아니며 격리도 아닙니다. 브리지를 통과하는 프레임은 설치된 bridge-netfilter 경로에 따라 호스트의 필터링 훅에 여전히 도달할 수 있으므로, 유효 정책은 가정하지 말고 검사해야 합니다. 프레임 하나가 사라졌다고 방화벽을 끄는 것은 특정 버그를 일반 버그와 맞바꾸는 일입니다.
브리지와 각 관리 또는 업링크 인터페이스 사이의 IP 전달은 꺼 두거나 명시적으로 거부해야 하며, 이는 브리지 소속과 별개의 제어입니다. PC의 실험실 주소를 게이트웨이로 선택하는 보드는 바로 이것을 시험합니다. 관리 통과가 성공한다면 의도한 경계는 애초에 없었던 것입니다.
두 가지 계열이 더 명시적 결정을 받을 만합니다. 주소 계획이 브리지를 IPv4 전용으로 만들지는 않으므로 IPv6와 다른 EtherType에는 자체 계획이나 필터가 필요합니다. 그리고 성공한 ping은 보드의 검색 브로드캐스트, 멀티캐스트 그룹, 점보 프레임이 경로를 통과하는지에 대해 아무것도 말하지 않습니다. 서로 다른 기본값을 가진 서로 다른 트래픽 클래스이기 때문입니다.
마지막으로 전송과 기밀성은 서로 다른 구매입니다. TAP은 Ethernet을 운반하고 OpenVPN 서비스가 그 주변의 보호를 제공합니다. VXLAN 오버레이도 Ethernet을 운반하며 그 자체로는 기밀성을 제공하지 않으므로, 하나를 다른 것으로 바꾸면 토폴로지 다이어그램이 같아 보여도 보안 속성이 달라집니다.
지속성과 이를 증명하는 테스트
연결 후 한 번 입력한 명령은 구성이 아닙니다. 브리지, 포트 소속, 단일 호스트 주소를 PC의 기존 네트워크 관리자를 통해 지속시키고, 연결을 TAP 장치의 출현에 묶어 재연결이 구성원이 사라진 브리지를 남기지 않도록 하십시오.
bridge link show
ip -d link show br-test
bridge fdb show br br-test | head그런 다음 보드가 양방향으로 실제로 무엇을 필요로 하는지 시험하고, 터널을 다시 연결하고, 승인된 복구 계획에 따라 PC 하나를 재시작하십시오. 그 후 세 가지를 확인하십시오. 관리 접근이 여전히 독립적으로 동작하고, 중복된 실험실 주소가 나타나지 않으며, 예기치 않은 프로덕션 인터페이스가 브리지에 합류하지 않았습니다. 그 조합이 실험이 벤치 안에 머물렀다는 증거입니다.