WireGuard 위의 mDNS: 피어가 응답하기까지의 세 관문
Avahi에는 적격 인터페이스, 그룹으로 가는 경로, 목적지를 소유한 피어가 필요합니다. 세 관문, 세 가지 별도 확인, 그리고 팬아웃은 없습니다.
WireGuard 장치에 멀티캐스트 플래그를 설정하면 인터페이스가 검색 소프트웨어에 적격해지며, 플래그가 하는 일은 그게 전부입니다. 그룹 패킷이 어디로 가야 하는지 프로토콜에 알려 주지 않으며, 여러 피어가 있는 장치에는 하나의 명백한 답이 없습니다. 실행 중인 데몬과 발견된 서비스 사이에는 세 개의 별도 관문이 있습니다.
순서대로 시험해 보세요. 하나를 통과해도 다음 관문에 대해서는 아무것도 알려 주지 않습니다.
첫 번째 관문: 플래그와 데몬의 정책
Linux WireGuard 장치는 ARP가 없는 점대점 링크로 생성되며 기본적으로 멀티캐스트 플래그를 갖지 않습니다. 플래그 추가는 장치를 관리하는 무엇이든 수행하는 로컬 인터페이스 변경입니다. 그 위에 Avahi는 나름의 세계관을 가지고 있으며, 기본 정책은 점대점 인터페이스를 완전히 건너뜁니다. 따라서 패킷 하나가 움직이기 전에 두 개의 독립적인 적격성 시험이 적용됩니다.
그래서 데몬에는 명시적인 결정이 필요하며, 단지 실행 중인 프로세스만으로는 충분하지 않습니다. 문서화된 제어 항목에는 allow-interfaces, deny-interfaces, allow-point-to-point이 있으며, 마지막 것이 사람들이 놓치는 설정입니다.
아래 확인은 링크 플래그, 멀티캐스트 경로, 그리고 데몬 구성이 파싱되는지 여부를 보고합니다:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --check성공적으로 시작된 데몬이 관심 있는 인터페이스에 소켓을 열었다고 단정할 수는 없습니다. 서비스 상태가 커버리지와 같다고 가정하지 말고 실제 유효 구성을 읽으십시오.
두 번째 관문: 그룹으로 가는 경로
두 번째 관문은 평범한 라우팅입니다. 224.0.0.251로 향한 패킷은 다른 모든 것과 마찬가지로 포워딩 테이블을 따르며, 테이블이 물리 LAN 인터페이스로 내보낸다면 어떤 WireGuard 구성도 그것을 바꾸지 못합니다. 먼저 경로를 고치면 나머지 조사가 짧아집니다. 어떤 피어 키도 건드리기 전에 커널이 그룹 주소에 대해 무엇을 보고하는지 보십시오.
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
특정 경로가 없으면 커널은 링크 자체의 멀티캐스트 처리로 돌아갑니다. 그래서 기본값은 평평한 LAN에서는 맞아 보이지만, 같은 그룹 트래픽이 터널로 나가야 하는 순간 틀려 보입니다. 실패는 송신 측에서 조용합니다. 질의는 어딘가로 가고 응답은 결코 도착하지 않습니다.
세 번째 관문: WireGuard는 패킷마다 하나의 피어를 고릅니다
WireGuard는 허용 주소 집합에서 목적지를 조회하여 송신 피어를 선택하며, Linux 전송 경로는 그 조회를 패킷마다 한 번 수행합니다. 결과는 하나이고, 패킷은 그 피어를 위해 암호화됩니다. 같은 그룹 접두사가 여러 피어의 허용 목록에 나타나도 멤버십이나 복제가 생기지 않습니다. 모호한 조회가 생기고 그중 하나로 귀결됩니다.
두 끝점만 있는 전용 링크에서는 이것이 바로 원하는 동작입니다. 의도적으로 전달하는 그룹 트래픽의 수신자가 하나이기 때문입니다. 피어가 다섯인 인터페이스에서는 이것은 제약이며 기능이 아니고, 수정은 어느 한 피어의 구성이 아니라 설계에 속합니다.
팬아웃 설계에는 명시적인 릴레이, 분리된 링크, 또는 완전히 다른 검색 메커니즘이 필요합니다. 모든 클라이언트가 게이트웨이에 핑할 수 있다는 이유로 두 끝점용 레시피를 다중 클라이언트 해법으로 공개하는 것이 바로 이것을 잘못 배포하는 방식입니다.
인바운드 방향은 다르게 확인합니다. 수신한 패킷의 출처는 인증된 피어의 허용 목록 안에 있어야 합니다. 거기에 멀티캐스트 목적지를 추가하는 것은 송신자의 실제 출처 소유권을 대체하지 않습니다.
리플렉션은 경계이지 다리가 아닙니다
Avahi의 리플렉터는 선택한 인터페이스 사이에서 mDNS 메시지를 응용 계층에서 재현합니다. 네트워크 사이의 검색 경계이며, 이더넷 브리지도 범용 멀티캐스트 라우터도 아닙니다. 같은 네트워크에 연결된 두 리플렉터는 반복되는 알림의 루프를 기꺼이 만들 것입니다.
리플렉션은 서비스 이름과 메타데이터를 다른 네트워크로 넘기기도 하며, 이는 라우팅 결정만큼이나 프라이버시 결정입니다. 선택한 인터페이스를 제한하고, 설치된 버전이 지원하는 경우 서비스 필터를 사용하여 권한 있는 사용자에게 필요한 알림만 경계를 넘게 하십시오.
발견과 사용은 별개의 결과로 남습니다. 클라이언트는 광고된 주소가 클라이언트가 있는 곳에서 도달할 수 없는 서비스나, 접근 정책이 포트를 거부하는 서비스의 알림을 볼 수 있습니다. 알림이 나타난 뒤 서비스 연결을 확인하고, 애플리케이션이 안정적인 DNS 이름이나 명시적 서버 주소를 지원한다면 링크 로컬 검색을 확장하는 대신 그것을 선호하십시오. 암호 키 라우팅 설명은 이 모든 것이 의존하는 목적지 기반 피어 선택을 다룹니다.