Dek ’n blaaier se instaanbediener ook WebRTC?
’n Gewone web-IP-toets en ’n WebRTC-verbinding kan verskillende roetes gebruik. Toets die blaaier se intydse kommunikasie apart.
’n Blaaier se HTTP-instaanbedienerinstelling dek nie outomaties WebRTC nie. ’n Gewone IP-toetsblad meet ’n webversoek; ’n oproep kan aparte roetes vir verbinding en adresontdekking gebruik.
SOCKS5 hef dié verskil nie op nie. Chromium se ingeboude SOCKS5-URL-instaanbedienerimplementering ondersteun TCP, nie ’n algemene UDP-assosiasie nie. Die protokol kan meer as wat dié blaaierkoppelvlak bied.
Blaaiers bied aparte WebRTC-netwerkkontroles. Chrome stel ’n IP-hanteringsbeleid deur sy API vir privaatheidsuitbreidings beskikbaar, onder meer disable_non_proxied_udp; Mozilla dokumenteer ook WebRTC-netwerkprivaatheidsinstellings. Dié Chrome-waarde is ’n API-beleid, nie ’n universele merkblokkie of waarborg dat elke adres versteek word nie.
Toets die gewone webuitgang, en ondersoek dan WebRTC in die konferensietoepassing wat jy werklik gebruik, met ’n diagnostiese hulpmiddel waarvan jy die gerapporteerde velde verstaan. Plaaslike adresse, herleiadresse en publiek waargenome adresse beskryf verskillende dele van ’n verbinding. Teken die blaaier en toetsomstandighede aan: beleide, uitbreidings, privaatheidsgedrag en beskikbare roetes beïnvloed die resultaat. Nóg “lek altyd” nóg ’n suksesvolle web-IP-toets is dus ’n voldoende gevolgtrekking.
Beperk jy ’n WebRTC-roete, probeer die nodige oproepe weer. Minder blootstelling van adresse kan ook verhinder dat ’n oproep verbind. Dié afweging staan los daarvan of ’n HTTP-instaanbedienereindpunt aanlyn is.