계획 없이 멀티캐스트가 VPN을 넘지 못하는 이유

두 사이트가 유니캐스트로 완벽하게 서로에게 도달하면서도, 한쪽이 프린터의 검색 공지, IPTV 스트림, 클러스터의 하트비트를 보지 못하는 것처럼 동작할 수 있습니다. 이것은 끊어진 터널이 아니라 목적지와 그룹의 차이입니다. 멀티캐스트 전달에는 멤버십 모델, 경로를 따라 유지되는 포워딩 상태, 트래픽을 실어 나를 의사가 있는 인터페이스가 필요하며, 어느 것도 유니캐스트 경로에서 나오지 않습니다. 애플리케이션의 그룹에서 동작하는 한 수신자까지 가는 것이 답에 이르는 가장 짧은 길입니다.

그룹과 애플리케이션에서 시작하십시오

애플리케이션이 어떤 그룹 주소를 쓰고 그 트래픽이 무엇을 위한 것인지 물으십시오. 서비스를 알리는 검색 프로토콜, 스트리밍 피드, 라우팅 프로토콜의 hello 패킷은 서로 다른 세 가지 문제이고 받아들일 수 있는 답도 세 가지로 갈립니다. 그룹 주소 자체가 범위를 말해 줍니다. 로컬 네트워크 제어 블록의 주소는 일반 라우팅으로 링크 밖으로 전달되도록 만든 것이 아니며, 그것을 쓰는 애플리케이션은 보통 하나의 브로드캐스트 도메인을 전제합니다. 전역 범위의 그룹 위에 있는 스트리밍 피드는 모든 장치가 모든 질의를 듣는다고 기대하는 검색 프로토콜과 다른 설계이며, 브로드캐스트 도메인의 크기를 신경 쓰는 것은 후자뿐입니다.

요구 사항이 서비스인지 검색 메커니즘인지 정하십시오. 그 두 답은 비용이 한 자릿수만큼 다릅니다. 하나는 바뀌지 않는 주소를 요구하고, 다른 하나는 광역 링크를 넘어 확장된 브로드캐스트 도메인 과 그로부터 이어지는 모든 것을 요구합니다.

링크 로컬 검색은 멈추도록 되어 있습니다

RFC 6762 에 설명된 멀티캐스트 DNS는 하나의 링크를 전제로 설계되었습니다. 질의는 고정된 그룹으로 가고 응답도 같은 그룹으로 보내지며, 프로토콜은 모든 참여자가 모두의 말을 듣는 것에 의존합니다. 라우터는 그 트래픽을 기본적으로 전달하지 않으며, 이는 실수가 아니라 설계 결정입니다. 경계가 있는 이유는 한 건물의 장치가 다른 건물로 쉽게 자신을 알리지 못하게 하기 위해서입니다. 그룹을 어디로든 실어 나름으로써 검색을 고친 것처럼 보이는 터널은 도움이 필요했던 애플리케이션만이 아니라 모든 애플리케이션에서 그 경계를 없애 버렸습니다.

리피터와 리플렉터는 존재하며 실제 결과를 가진 실제 서비스입니다. 한 사이트에서 공지된 모든 이름이 다른 사이트에서 보이게 되며, 사람이나 장비를 식별하는 장치 이름도 포함됩니다. 진짜 요구 사항이 특정 서비스를 찾을 수 있게 하는 것이라면 DNS에 게시하는 서비스 레코드가 보통 더 작은 변경이고, 이름의 흐름이 아니라 이름 하나만 드러냅니다.

라우팅되는 멀티캐스트에 필요한 세 가지

라우팅되는 멀티캐스트에는 함께 동작하는 세 가지가 필요합니다. 그룹에 가입하는 수신자, 그 그룹을 위한 포워딩 상태를 유지하는 라우터, 그룹 주소를 실어 나를 트래픽으로 취급하는 터널입니다. 유니캐스트 서브넷만 나열한 정책의 터널은 암호화 경계에서 그룹 트래픽을 떨어뜨리며, 그래서 첫 증상이 오류가 아니라 침묵인 경우가 많습니다. GRE나 VTI 터널 같은 경로 기반 인터페이스는 라우팅 테이블이 보내는 것을 실어 나르므로, 멀티캐스트 상태만 있으면 그룹은 도달 가능해집니다.

송신자 도달 가능성이 나머지 절반입니다. PIM 같은 멀티캐스트 라우팅 프로토콜은 송신자로 돌아가는 경로가 기대한 경로인지 확인하며 분배 트리를 만듭니다. 그래서 그룹 멤버십이 올바르더라도 다른 곳을 가리키는 유니캐스트 경로는 트리를 깨뜨립니다. 수신자용 경로를 설치하는 것은 그 확인에 아무 도움이 되지 않으며, 이것이 통하는 ping과 실패하는 스트림을 만드는 실수입니다. 먼저 송신자의 귀환 경로를 확인하고, 다음에 멤버십을 추가하고, 그다음에야 애플리케이션을 보십시오.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

처음 두 줄은 호스트가 무엇에 가입했고 커널이 무엇을 전달하는지 보여 주고, 세 번째 줄은 애플리케이션 자체의 멤버십을, 마지막 줄은 역경로 검사가 사용할 유니캐스트 경로를 보여 줍니다. 함께 읽으면 한 번도 가입하지 않은 애플리케이션과 한 번도 전달하지 않은 네트워크를 구별할 수 있습니다.

한 송신자와 한 수신자로 증명하십시오

설정을 건드리기 전에 애플리케이션이 단일 세그먼트에서 동작하는지 확인하십시오. 로컬에서 실패한다면 멀티캐스트 라우팅이 문제가 아니며 어떤 터널 변경도 도움이 되지 않습니다. 그런 다음 터널을 건너 한 수신자로 반복하고 암호화 경계 양쪽에서 패킷을 보십시오.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

터널 안에서는 보이지만 밖에서는 없는 패킷은 캡슐화나 정책을 가리키고, 양쪽에서 보이지만 애플리케이션이 진행되지 않는 패킷은 수신자의 멤버십이나 애플리케이션의 바인딩을 가리킵니다. 캡처는 짧고 필터링된 상태로 유지하십시오. 혼잡한 세그먼트에서의 넓은 멀티캐스트 캡처는 대부분 잡음입니다.

서비스만 필요하다면 서비스 주소를 고르십시오

검색은 움직이는 무언가를 찾기 위해 존재합니다. 이름이 안정적인 서버에는 검색이 필요 없고, 사설 DNS에 문서화된 주소는 브로드캐스트 도메인을 광역 링크로 확장하지 않고 사용자의 진짜 질문에 답합니다. 같은 논리가 프린터, 가전, 내부 웹 서비스에도 적용됩니다. DNS의 이름은 필요한 모든 사이트에서 도달할 수 있으면서 필요 없는 사이트에는 아무것도 알리지 않으며, 장치가 다른 주소의 장치로 교체되어도 계속 동작합니다.

프로토콜이 정말로 멀티캐스트를 요구한다면 그룹과 그것이 필요한 사이트로 한정하고, 이유를 문서화하며, 애플리케이션이 바뀌면 결정을 다시 검토하십시오. 검색을 어디로든 확장하는 것은 한 번은 쉽고, 그것에 조용히 의존하는 장치로 일 년을 보낸 뒤 되돌리는 것은 어렵습니다.