TURN-servers uitgelegd: zo komt video door restrictieve netwerken

Af en toe weigert een schermdeling, een videogesprek of de bedieningsverbinding van een presentator gewoon verbinding te maken op één bepaald netwerk, terwijl het overal elders prima werkt. In negen van de tien gevallen is een geblokkeerde directe verbinding de boosdoener, en de oplossing is een TURN-server. TURN-servers simpel uitgelegd: het is de relay die een peer-to-peerverbinding werkend houdt wanneer het netwerk niet toestaat dat twee apparaten rechtstreeks met elkaar praten.

Als je je ooit hebt afgevraagd waarom je presentatietool überhaupt een “relay”- of “TURN”-instelling nodig heeft, dan is dit het antwoord. Het loont om dit te begrijpen, of je nu vanavond een weggevallen verbinding moet oplossen of de netwerkclaims van een tool beoordeelt voordat je die koopt.

Waarom directe verbindingen soms mislukken

WebRTC, de technologie achter de meeste peer-to-peertools voor video en bediening, verbindt twee apparaten het liefst rechtstreeks met elkaar. Dat is efficiënt en snel: er zit geen derde partij tussen de telefoon van de presentator en de hostcomputer waarop de slides draaien. Het probleem is dat een echt directe verbinding afhangt van de bereikbaarheid van beide apparaten op het open internet, en de meeste apparaten zijn dat niet.

Thuisrouters gebruiken NAT (Network Address Translation) om één openbaar IP-adres over veel apparaten te delen, wat directe verbindingen al lastiger maakt. Bedrijfs- en locatienetwerken gaan nog verder: ze blokkeren UDP-verkeer vaak volledig of beperken uitgaande verbindingen tot een korte lijst toegestane poorten. STUN, een lichter protocol, kan eenvoudige NAT-situaties oplossen door twee apparaten te helpen hun openbare adres te ontdekken. Maar het kan niet alles oplossen.

Wat TURN echt doet

TURN, Traversal Using Relays around NAT, is de fallback voor precies die situatie. TURN is vastgelegd in IETF RFC 8656 en werkt door beide apparaten een relay-adres te geven om verkeer naartoe te sturen, in plaats van naar elkaar. De relay stuurt de pakketten simpelweg door tussen beide kanten.

Drie dingen zijn belangrijk aan hoe dat gebeurt:

STUN, TURN en TURNS: wat is het verschil

Deze drie afkortingen worden door elkaar gebruikt, en dat zou niet moeten:

Die laatste rij is belangrijker dan hij lijkt. Een netwerk dat alles blokkeert behalve standaard HTTPS-verkeer op poort 443, laat een TURNS-verbinding toch door, omdat die er voor dat netwerk precies hetzelfde uitziet als gewoon surfen op het web. Dit is precies het mechanisme achter waarom bedrijfsfirewalls presentatietools blokkeren, en waarom de goede tools er toch doorheen komen.

Hoe Cliqer TURN gebruikt

De desktop- en webclients van Cliqer proberen eerst een directe WebRTC-verbinding, beveiligd met DTLS en SRTP. Blokkeert het netwerk die, dan valt de verbinding automatisch terug op een versleutelde TURN-relay, inclusief een TURNS-route via poort 443 voor netwerken die uitgaand alleen standaard webverkeer toestaan. TURN-inloggegevens worden per aanvraag aangemaakt met een geldigheidsduur van 24 uur en roteren automatisch, in plaats van vaste waarden te zijn die een client eindeloos hergebruikt.

Je hoeft hiervoor zelf niets in te stellen. De fallback gebeurt automatisch en onzichtbaar, of je nu presenteert vanuit je thuiskantoor of vanuit een streng afgeschermd congrescentrum. Wil je het volledige beeld van hoe de rest van de verbinding is beveiligd, lees dan is WebRTC veilig en de documentatie over Beveiliging & netwerken.

Wat een relay je kost, en wat niet

TURN-relaying is technisch gezien niet gratis. Verkeer via een derde punt leiden voegt een kleine hoeveelheid latency toe ten opzichte van een directe verbinding, en het gebruikt meer bandbreedte aan de kant van de relay-beheerder. Wat het je niet kost, is beveiliging: de relay ontsleutelt de payload nooit, dus een afgeschermd netwerk dwingt je niet te kiezen tussen “het werkt” en “het is privé”.

Voor schermdeling in het bijzonder, waar elke extra honderd milliseconden meer opvalt dan bij een eenvoudig signaal om naar de volgende slide te gaan, bespreken we het bredere latencyplaatje in hoe we schermdeling vier keer sneller maakten en latency bij schermdeling oplossen in hybride vergaderingen.

Een verbinding oplossen die niet tot stand komt

1. Probeer kort te tetheren via een mobiele hotspot. Werkt de verbinding daar wel maar niet op het netwerk van de locatie, dan ligt het probleem bij het netwerk, niet bij de app.
2. Kijk of de app een zichtbare indicator voor “relay” of “verbindingstype” heeft, en controleer of hij TURN probeert in plaats van meteen te falen.
3. Controleer of uitgaand HTTPS-verkeer op poort 443 is toegestaan, want een TURNS-fallback via 443 is de laatste verdedigingslinie op de meest restrictieve netwerken.
4. Werkt dat allemaal niet, kaart het dan aan bij het IT-team van de locatie of het kantoor, met de specifieke poorten en protocollen uit de documentatie van de leverancier in plaats van een algemene melding dat “het niet werkt”.

Beoordeel je netwerkgedrag als onderdeel van een bredere leveranciersbeoordeling, neem dit dan mee in de volledige beveiligingschecklist voor presentatiesoftware, want hoe een tool omgaat met restrictieve netwerken wordt makkelijk over het hoofd gezien, tot de dag dat het ertoe doet.

Veelgestelde vragen

Aan de slag

Presenteer je vanaf locaties, kantoren van klanten of andere plekken met een netwerk dat je niet zelf beheert? Probeer Cliqer gratis en zie de automatische fallback in actie, of lees het volledige beveiligingsoverzicht over hoe elke laag van de verbinding is beschermd.