VPN of TURN-relay: hokker draacht in WebRTC-oprop echt?
In tunnel feroaret it paad dat ICE sjocht; hy ken nea in relay ta en leveret gjin sinjaaljouwing. Fergelykje wat in VPN-útgong en in TURN-tsjinner elk biede.
De side wurdt oer de VPN laden, de oprop komt nea ta stân: twa ferskillende flaters yn deselde adresbalke. De tunnel hat it paad feroare dat de browser brûkt; hy waard gjin tsjinst foar sinjaaljouwing, gjin STUN-tsjinner en gjin relay, en hy beslút net hokker kandidaatpear ICE kieze sil. Krekt it skieden fan de taak fan elk ûnderdiel makket fan in fage “WebRTC is blokkearre” in konkrete flater.
Fjouwer taken, wêrfan de tunnel mar ien rekket
De applikaasje wikselet sesje-ynformaasje út fia in of oare regeling foar sinjaaljouwing, en dat is de earste taak. ICE sammelt kandidaatadressen en test pearen oant ien wurket, wat de twadde is. STUN lit in peer leare hoe't syn ferkear fan bûten ôf liket, en TURN ken in relay ta foar gefallen dêr't gjin direkte paad bestiet. Dy fjouwer rollen binne ferskillend, en in VPN beynfloedet de adressen en de filtering dy't se treffe, ynstee fan ien fan har te leverjen.
Dêrom seit in slagge oanmelding neat oer it mediapaad. Sinjaaljouwing rydt meastentiids oer deselde HTTPS dy't de side al brûkt, op poarte 443, wylst de media oer UDP nei in hiel oar bestimming reizgje kinne.
Privee adressearjen makket de betizing slimmer. In tunneladres is foar in peer allinnich nuttich as dy peer in bedoeld paad werom hat; privee wêze is gjin bewiis fan ûnderlinge berikberens, en browsers behannelje it net sa as se kandidaten weismite dy't net kontrolearre wurde kinne. In kandidaat dy't foar jo lokaal liket, kin fan ’e oare kant net testber wêze. Dat gat is it wurdich om út te sluten foardat jo konkludearje dat de tunnel media falle lit.
Fergelykje in VPN-útgong mei in TURN-relay
Beide stjoere pakketten troch, en dêrom wurde se betize, en de fergelikingstabel hjirboppe is it wurdich kolom foar kolom te lêzen ynstee fan as in list mei funksjes. In relaytawizing is in objekt per sesje dat troch in autentisearre fersyk makke wurdt; in tunnel is in rûte. De iene hat oanmeldgegevens dy't ferrinne, de oare hat in peeradres dat of berikber is of net.
| 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 |
Poartenûmers meitsje it ferskil konkreet. TURN harket standert op 3478 foar UDP en TCP en op 5349 foar TLS, en in netwurk dat 443 tastean lit mar dy poarten weilitten, sil relaye oproppen mislearje litte wylst browsen normaal trochgiet. It feroarjen fan de poarte fan de VPN konfigurearret dêr neat fan, omdat de poarten dy't fan belang binne by de relaytsjinst hearre, net by de tunnel.
Lês de diagnostyk, test dan de oprop
Browsers litte de nedige ynformaasje sjen sûnder pakketopname. Iepenje de WebRTC-diagnostykside foar jo browser, meitsje de oprop, en lês it keazen kandidaatpear ynstee fan ’e sammele list: hokker lokale en fiere kandidaattypen keazen binne, oer hokker transport en adresfamylje, en oft it paad direkt of relaye is.
Twa lêzingen is it wurdich foarôf te kennen. As it keazen pear host-ta-host is op privee adressen, bliuwt de media op in paad dêr't jo oer neitinke kinne; as it relay-ta-relay is, brûkt de oprop relaykapasiteit en hinget it ôf fan ’e beskikberens fan dy tsjinst. In flater dy't by “kontrolearje” stopet sûnder keazen pear betsjut dat kandidaten sammele waarden, mar gjinien slagge foar de ferbiningskontrôles.
Fergelykje dan deselde twa einpunten yn deselde oprop wylst jo mar ien goedkarde betingst feroarje, en akseptearje it resultaat op twarjochtsje media of gegevens ynstee fan op in oantsjutting “ferbûn”. Kandidaatsamling slagget yn in soad gefallen dy't nea ien kader lûd drage. Werhelje de oprop oan ’e oare kant fan ’e feroaring en bewarje beide diagnostyske opnamen, want it fergelykjen fan twa rinnen is ynformativer as it lêzen fan ien fan beide allinnich. Deselde einpunten, deselde codec, ien feroare fariabele.
In applikaasje dy't syn ICE-transportbelied mei opsetsin op relay set, freget allinnich relaykandidaten. Dy ynstelling makket gjin relay en reparearret gjin ûntbrekkende oanmeldgegevens; se makket de eask eksplisyt, wat nuttich is as immen de VPN de skuld jout foar in belied dat de side keazen hat.
Hâld de privacybewearing sa smel as it bewiis
De bleatstelling fan kandidaten hinget ôf fan browser- en applikaasjebelied, net allinnich fan tunnelstatus, en de W3C-specifikaasje foar peerferbining behannelet IP-omgong as in eigen saak. In ferbûne VPN is dêrom in swakke basis om te beloven dat in oprop mar ien keazen adres sjen lit. Twa peers efter deselde tunnel kinne sels in paad kieze dat de host nea ferlit, wat tagelyk in ferbettering fan privacy en in beheining fan ferbining is.
Wat jo krekt sizze kinne, is smeller en nuttiger: hokker kandidaatpear keazen is, hokker transport it droech, en oft dat paad yn ’e tunnel bleau. Skriuw dy trije feiten op foar in wurkjende oprop en foar ien dy't mislearret, en it ferskil neamt meastentiids it ûnderdiel dat reparearre wurde moat.
As de ferbining wurket, skied dan prestaasje fan berikberens. Ferlies, fertraging, wachtrigen en MTU lizze allegear streamôf fan in koroek kandidaatpear, en it behanneljen fan in hakkeljende oprop as in ferbiningsflater stjoert jo sûnder reden werom nei de kandidatelist.