OpenVPN 위의 SSM: 하나의 소스와 그룹을 처음부터 끝까지 추적하기

스트림 하나와 수신자 하나를 고른 다음, 멀티캐스트를 범주로 시험하는 대신 그 쌍을 모든 홉에서 따라가세요. 소스 지정 설계는 정확히 네 곳 중 한 곳에서 실패하는데, 수신자가 가입하지 않았거나, 라우터가 역방향 경로에서 패킷을 거부했거나, 커널에 상태가 없거나, 터널이 복사본을 전달하지 않은 경우입니다. 이 순서로 작업하면 홉당 몇 분이면 되고, 네 가지 중 실제로 어느 것인지 알 수 있습니다.

먼저 소스, 그룹, 수신자를 확정하세요

어떤 장비든 만지기 전에 보낼 소스 주소, 수신자가 가입할 그룹 주소, 수신자가 있는 서브넷 세 가지 값을 적으세요. 예시 IPv4 스트림이라면 소스 10.50.0.10과 그룹 232.20.30.40이 소스 지정 설계에 맞는 쌍입니다. 이 세 값보다 모호한 것은 시험할 수 없습니다.

232/8 범위는 소스 지정 멀티캐스트용으로 예약되어 있으며, 모델은 RFC 4607 에 설명되어 있습니다. SSM을 운영한다고 믿으면서 그룹이 그 범위를 벗어나 있다면, 수신자의 가입과 라우터의 전달 결정이 모두 모델의 일관성에 달려 있으므로 멈추고 배포의 실제 의도를 확인하세요.

수신자가 소스에 가입했는지 확인하세요

그룹만 대상으로 한 가입 보고서는 소스 지정 가입이 아닙니다. 수신자에게 어느 소스를 요청했는지 물어보고, 첫 홉 라우터에서 그룹 상태를 보고 소스 목록이 나타나는지 확인하세요. 보고서에 소스가 없으면 라우터는 이를 임의 소스 가입으로 처리하고 설계 전체가 계획하지 않은 무언가로 조용히 퇴화합니다.

Linux 수신자에서는 소켓이 실제로 무엇을 구독했는지, 커널이 무엇을 기록했는지 확인하세요. 애플리케이션 설정 파일이 아니라 가입 테이블이 증거입니다. 수신자가 실제로 실행 중일 때 읽어야 하는데, 항목은 그것을 만든 프로세스가 종료된 뒤에도 잠시 남을 수 있습니다. 이전 시험의 낡은 항목은 잘못된 확신의 확실한 원인입니다.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

예상한 소스로 가입이 존재하면 라우터로 넘어가세요. 없다면 전달할 것이 없으므로 어떤 터널 설정도 도움이 되지 않습니다.

터널을 보기 전에 역방향 경로를 검증하세요

멀티캐스트 라우팅은 역방향 경로 검사를 수행하며, 유니캐스트 경로가 가리키는 인터페이스가 아닌 곳으로 도착한 패킷은 버려집니다. 분명히 전송 중인 스트림이 다음 홉에 절대 도달하지 못하는 가장 흔한 이유이며, 애플리케이션 수준에서는 쓸모 있는 오류가 전혀 나지 않습니다.

소스를 향한 라우터에서는 소스로 가는 경로와 패킷이 실제로 도착하는 인터페이스를 비교하세요. 수신자를 향한 라우터에서는 수신자 자신의 서브넷에 대해 같은 일을 하고, 나가는 인터페이스 목록에 그쪽으로 가는 링크가 포함되는지 확인하세요. 어느 방향이든 불일치는 RPF 실패이지 가입 실패가 아닙니다.

그다음 소스의 TTL이 설계한 라우팅 홉을 통과하기에 충분히 큰지 확인하세요. 첫 라우터에서는 동작하고 두 번째에서 죽는 스트림은 대개 정책이 아니라 TTL의 문제입니다.

설정이 아니라 커널의 멀티캐스트 상태를 읽으세요

설정은 무엇을 요청했는지 알려주고, 커널은 무엇이 일어나는지 알려줍니다. 각 Linux 홉에서 멀티캐스트 라우팅 항목을 읽고, 정확한 소스와 그룹 쌍에 대해 들어오고 나가는 인터페이스 목록이 있는지 확인하세요. 와일드카드 소스를 가진 그룹 항목은 다른 객체이며 소스 지정 흐름을 설명하지 못합니다.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

라우팅 데몬은 그 상태 위에 자체적인 관점을 유지하며, 이를 출력하는 명령은 어떤 구현이 설치되어 있는지에 따라 다릅니다. 원칙은 일정하며, 데몬에 그 쌍의 업스트림 항목을 묻고 다음으로 커널에 전달 항목이 있는지 물으세요. 커널에 항목이 없는데도 전달한다고 생각하는 데몬은 해당 호스트의 설정 범위 문제입니다.

둘이 맞지 않으면 VPN이 아니라 호스트를 고치세요. 물어본 흐름을 전달하지 않는 홉은 하류의 무엇으로도 보상할 수 없습니다. 스트림이 동작하는 동안 각 홉의 쌍, 들어오는 인터페이스, 나가는 목록을 기록하세요. 그 기록이 다음 실패를 새로운 조사가 아니라 비교로 바꿉니다.

터널이 실제로 어떻게 복제하는지 결정하세요

여기서 VPN 위의 멀티캐스트는 일상 업무가 아니게 됩니다. 지점 간 터널은 패킷을 반대편의 단일 피어에게 전달하므로, 복사본은 정확히 한 클라이언트에 도달합니다. 브리지된 세그먼트는 공유 링크처럼 더 많이 동작합니다, 터널이 프레임을 운반하고 브리지가 무엇을 플러딩할지 결정하기 때문입니다. 이들은 서로 다른 전달 모델이며, 두 번째를 가정하면서 첫 번째를 실행하는 설계는 한 수신자에게는 동작하는 것처럼 보이고 다음 수신자에게는 실패합니다.

다중 지점 서버를 통해 둘 이상의 수신자를 다루려면 복제를 명시적으로 설계해야 합니다. 게이트웨이에 멀티캐스트 경로를 설치한다고 VPN 서버가 어떤 피어가 복사본을 받아야 하는지 알게 되지 않으며, 클라이언트 측 경로가 그 결정을 대신하지도 않습니다. 수신자가 많은 것이 요구 사항이라면 지원되는 복제나 의도적으로 선택한 대안을 사용하고, 어느 것을 골랐는지 적어 두세요.

마지막으로 수신자에서 좁은 관찰로 정확한 소스, 그룹, 포트를 기대하는 인터페이스에서, 권한이 있는 수신자 하나가 가입한 상태로 확인하세요. SSM은 송신자를 선택하며, 그 선택은 그 송신자에 대한 인증이 아니고 다른 멀티캐스트 트래픽이 같은 정책을 통과할 권한도 아닙니다.