VPN aŭ TURN-relajso: kiu vere portas WebRTC-vokon?
Tunelo ŝanĝas la vojon, kiun ICE vidas; ĝi neniam asignas relajson nek provizas signaladon. Komparu, kion donas VPN-elirejo kaj TURN-servilo.
La paĝo ŝargiĝas tra la VPN, sed la voko neniam konektiĝas: du malsamaj paneoj kun la sama adresa strio. La tunelo ŝanĝis la vojon, kiun la retumilo uzas; ĝi ne fariĝis signalada servo, STUN-servilo aŭ relajso, kaj ĝi ne decidas, kiun kandiatan paron ICE elektos. Ĝuste la disigo de la tasko de ĉiu komponanto transformas svagan “WebRTC estas blokita” en konkretan paneon.
Kvar taskoj, el kiuj la tunelo tuŝas nur unu
La aplikaĵo interŝanĝas sesiajn informojn per ia signala aranĝo, kaj tio estas la unua tasko. ICE kolektas kandidatajn adresojn kaj testas parojn ĝis unu funkcias, kio estas la dua. STUN ebligas al samtavolano lerni, kiel ĝia trafiko aspektas de ekstere, kaj TURN asignas relajson por kazoj, kie rekta vojo ne ekzistas. Tiuj kvar roloj estas apartaj, kaj VPN influas la adresojn kaj filtradon, kiujn ili renkontas, anstataŭ provizi iun ajn el ili.
Tial sukcesa ensaluto diras nenion pri la aŭdvidada vojo. Signalado kutime vojaĝas per la sama HTTPS, kiun la paĝo jam uzas, sur pordo 443, dum la aŭdvidaĵoj povas vojaĝi per UDP al tute alia celo.
Privata adresado plimalbonigas la konfuzon. Tunela adreso utilas al samtavolano nur kiam tiu havas celitan vojon reen al ĝi; esti privata ne estas pruvo de reciproka atingeblo, kaj retumiloj ne traktas ĝin tiel, kiam ili forĵetas kandidojn, kiujn oni ne povas kontroli. Kandido, kiu aspektas loka al vi, povas esti nekontrolebla de la alia flanko. Tiu breĉo indas esti ekskludita antaŭ ol vi konkludos, ke la tunelo faligas aŭdvidaĵojn.
Komparu VPN-elirejon kun TURN-relajso
Ambaŭ plusendas pakojn, pro kio oni konfuzas ilin, kaj la kompara tabelo supre indas esti legata kolumne, ne kiel listo de trajtoj. Relajsa asigno estas objekto por sesio kreita per aŭtentigita peto; tunelo estas vojo. Unu havas akreditaĵojn, kiuj eksvalidiĝas, la alia havas samtavolan adreson, kiu aŭ estas atingebla aŭ ne.
| Component | What it contributes | What it needs to work | What it cannot do |
|---|---|---|---|
| VPN exit | Changes the observed mapping and the route packets take | A working tunnel and a policy that permits the media transport | Allocate a relay or supply signaling |
| STUN server | Reports the mapped address a peer appears to use | Reachability from the client, on its configured transport | Carry media when a direct path fails |
| TURN server | Relays media through an authenticated allocation | Valid credentials, an allowed transport and sufficient capacity | Fix a missing ICE policy or an unauthorized client |
| Signaling channel | Carries offers, answers and candidate lists | Both peers reaching the same application endpoint | Establish connectivity by itself |
Pordaj numeroj igas la diferencon konkreta. TURN aŭskultas defaŭlte ĉe 3478 por UDP kaj TCP kaj ĉe 5349 por TLS, kaj reto, kiu permesas 443 sed forĵetas tiujn pordojn, malsukcesos ĉe relajsaj vokoj dum retumado daŭras normale. Ŝanĝi la pordon de la VPN agordas neniom el tio, ĉar la gravaj pordoj apartenas al la relajsa servo, ne al la tunelo.
Legu la diagnozon, poste testu la vokon
Retumiloj montras la bezonatajn informojn sen paketa kaptado. Malfermu la WebRTC-diagnozan paĝon por via retumilo, faru la vokon, kaj legu la elektitan kandidan paron anstataŭ la kolektitan liston: kiuj lokaj kaj malproksimaj kandidoj estis elektitaj, per kiu transporto kaj adresa familio, kaj ĉu la vojo estas rekta aŭ relajsa.
Du legaĵojn indas scii anticipe. Se la elektita paro estas gastiganto-al-gastiganto sur privataj adresoj, la aŭdvidaĵoj restas sur vojo, pri kiu vi povas racii; se ĝi estas relajso-al-relajso, la voko konsumas relajsan kapaciton kaj dependas de la disponeblo de tiu servo. Paneo, kiu haltas ĉe “kontrolado” sen elektita paro, signifas, ke kandidoj estis kolektitaj sed neniu trapasis la konektecajn kontrolojn.
Poste komparu la samajn du finpunktojn en la sama voko ŝanĝante nur unu aprobitan kondiĉon, kaj akceptu la rezulton laŭ dudirekta aŭdvidaĵo aŭ datumo, ne laŭ indikilo “konektita”. Kandida kolektado sukcesas en multaj kazoj, kiuj portas eĉ ne unu kadron da sono. Ripetu la vokon al la alia flanko de la ŝanĝo kaj konservu ambaŭ diagnozajn registraĵojn, ĉar kompari du runojn pli informas ol legi iun ajn sole. Samaj finpunktoj, sama koduko, unu ŝanĝita variablo.
Aplikaĵo, kiu intence agordas sian ICE-transportan politikon al relay, petas nur relajsajn kandidojn. Tiu agordo ne kreas relajson kaj ne riparas mankantajn akreditaĵojn; ĝi faras la postulon eksplicita, kio utilas kiam iu kulpas la VPN-on pri politiko, kiun elektis la retejo.
Tenu la privatecan aserton tiel mallarĝa kiel la pruvoj
Kandida elmetiĝo dependas de retumila kaj aplikaĵa politiko, ne nur de tunela stato, kaj la W3C-specifikaĵo pri samtavola konekto traktas IP-traktadon kiel sian propran aferon. Konektita VPN do estas malforta bazo por promesi, ke voko malkaŝas nur unu elektitan adreson. Du samtavolanoj malantaŭ la sama tunelo eĉ povas elekti vojon, kiu neniam forlasas la gastiganton, kio estas samtempe plibonigo de privateco kaj limigo de konektebleco.
Kion vi povas precize diri, estas pli mallarĝe kaj pli utile: kiu kandida paro estis elektita, kiu transporto portis ĝin, kaj ĉu tiu vojo restis ene de la tunelo. Notu tiujn tri faktojn por funkcianta voko kaj por malsukcesa, kaj la diferenco kutime nomas la komponanton riparindan.
Kiam konektebleco funkcias, apartigu efikecon de atingeblo. Perdo, prokrasto, atendovicoj kaj MTU ĉiuj situas malsupre de ĝusta kandida paro, kaj trakti interrompetan vokon kiel konektecan paneon resendas vin al la kandida listo sen kaŭzo.