Am următorul scenariu: Două site-uri, fiecare cu propria rețea (subrețea privată care nu se suprapun), conectate cu un VPN site-to-site (layer 3, Wireguard). Rutele către celelalte site-uri sunt configurate în gateway-urile implicite și, de asemenea, distribuite clienților prin DHCP. Traficul IP (v4 și v6) circulă bine între rețele.
Pe ambele gateway-uri VPN, avahi-daemon funcționează ca repetitor mDNS (enable-reflector=da) între rețeaua locală și tunelul wireguard și smcroute este configurat pentru a transmite pachete rutabile SSDP multicast (trimis la 239.255.255.250, ff05::c, ff08::c) de la rețeaua locală la tunelul wireguard și invers. Funcționează bine, ambele pachete MDNS și SSDP călătoresc de la o rețea la alta, am verificat-o cu Wireshark.
Pe Windows 10 (21H2), rezoluția numelui mDNS a domeniilor .local funcționează bine în ambele rețele, datorită reflectării avahi-daemon.În VLC pe Windows, dispozitivele multimedia din ambele rețele se găsesc cu mDNS, precum și UPnP (SSDP) și pot fi accesate. Cu toate acestea, Windows Explorer afișează numai dispozitivele din rețeaua locală în vizualizarea de rețea.
Am verificat și am încercat deja următoarele lucruri:
- Serviciul Function Discovery Resource Publication (FDResPub) este activat și rulează.
- Serviciul Function Discovery Provider Host (fdPHost) este activat și rulează (deși, din punctul meu de vedere, acest lucru nu este necesar pentru descoperirea serviciului).
- Descoperirea rețelei și partajarea fișierelor și a imprimantei sunt ambele activate pentru profilul de rețea activ (Privat) în setările avansate de partajare.
- Am dezactivat complet Windows Firefall pentru testare (nu sunt instalate alte produse firewall).
Când apăsați Ctrl+F5 în vizualizarea Rețea din Windows Explorer, pot vedea cererile SSDP M-SEARCH trimise la adresele multicast 239.255.255.250 și ff02::c. Adresa IPv6 ff02::c este o adresă de multicast link-local și nu este direcționată către cealaltă rețea, ci către cererea trimisă 239.255.255.250 ajunge în cealaltă rețea și răspunsurile de la dispozitivele de acolo ajung în rețeaua locală. Dar aceste dispozitive nu sunt afișate în Windows Explorer.
Am găsit documentația API-urilor Windows UPnP. Există o secțiune despre setările de configurare care poate fi schimbat cu cheile de registry. Cele mai multe dintre căile de registry menționate există, dar niciuna dintre cheile menționate nu este setată. Cheile DownloadScope și ReceiveScope ambele implicite 1, care permite descoperirea gazdelor din subrețele private. De asemenea, am adăugat ambele chei la registry (ca DWORD pe 32 de biți), le-am setat în mod explicit la 1 și am repornit mașina Windows, dar Windows Explorer încă arată doar alte computere din aceeași subrețea.
The UPnPDeviceFinder poate fi folosit dintr-un PowerShell pentru a lista dispozitivele UPnP (credite):
$ssdpFinder = Nou-Object -ComObject 'UPnP.UPnPDeviceFinder'
$ssdpFinder.FindByType('ssdp:all', 0)
Acest face găsiți dispozitive UPnP atât din rețeaua locală, cât și de la distanță, de asemenea, cu DownloadScope și ReceiveScope nespecificate în registru. Cu toate acestea, solicitările IPv6 SSDP M-SEARCH sunt trimise către ff02::c Chiar si cu DownloadScope și ReceiveScope ambele setate în mod explicit la 1 și, astfel nu vor fi direcționate către alte rețele.
Deci două întrebări rămân:
- Cum poate fi configurat Windows 10 astfel încât Windows Explorer să arate dispozitivele din alte rețele descoperite prin WS-Discovery / UPnP / SSDP în vizualizarea Rețea?
- Cum poate fi configurat Windows 10 (UPnPDeviceFinder, Windows Explorer) pentru a difuza solicitări IPv6 SSDP M-SEARCH către
ff05::c sau ff08::c în loc de ff02::c, astfel încât mesajele multicast să poată fi direcționate către alte rețele?
