Traversering med hjälp av reläer runt NAT
Traversering med hjälp av reläer runt NAT ( TURN ) är ett protokoll som hjälper till att passera nätverksadressöversättare (NAT) eller brandväggar för multimediaapplikationer. Det kan användas med Transmission Control Protocol (TCP) och User Datagram Protocol (UDP). Det är mest användbart för klienter på nätverk maskerade av symmetriska NAT- enheter. TURN hjälper inte till att köra servrar på välkända portar i det privata nätverket via en NAT; den stöder anslutningen av en användare bakom en NAT till endast en enda peer, som till exempel i telefoni.
TURN specificeras av RFC 8656 . TURN URI-schemat är dokumenterat i RFC 7065 .
Introduktion
NAT:er, samtidigt som de ger fördelar, har också nackdelar. Den mest besvärliga av dessa nackdelar är det faktum att de bryter många befintliga IP-applikationer och gör det svårt att distribuera nya. Riktlinjer har tagits fram som beskriver hur man bygger "NAT-vänliga" protokoll, men många protokoll kan helt enkelt inte konstrueras enligt dessa riktlinjer. Exempel på sådana protokoll inkluderar multimediaapplikationer och fildelning.
Session Traversal Utilities för NAT (STUN) tillhandahåller ett sätt för en applikation att passera en NAT. STUN tillåter en klient att få en transportadress (en IP-adress och port) som kan vara användbar för att ta emot paket från en peer. Adresser erhållna av STUN kanske inte kan användas av alla kamrater. Dessa adresser fungerar beroende på de topologiska förhållandena i nätverket. Därför kan STUN i sig inte tillhandahålla en komplett lösning för NAT-traversering.
En komplett lösning kräver ett sätt genom vilket en klient kan erhålla en transportadress från vilken den kan ta emot media från vilken peer som helst som kan skicka paket till det offentliga Internet. Detta kan endast åstadkommas genom att vidarebefordra data via en server som finns på det offentliga Internet. Traversal Using Relay NAT (TURN) är ett protokoll som tillåter en klient att få IP-adresser och portar från ett sådant relä.
Även om TURN nästan alltid tillhandahåller anslutning till en klient, är det resurskrävande för leverantören av TURN-servern. Det är därför önskvärt att endast använda TURN som en sista utväg och att föredra andra mekanismer (som STUN eller direktanslutning) när det är möjligt. För att uppnå det Interactive Connectivity Establishment (ICE) användas för att upptäcka det optimala sättet för anslutning.
Protokoll
Processen börjar när en klientdator vill kontakta en peer-dator för en datatransaktion, men inte kan göra det på grund av att både klient och peer ligger bakom respektive NAT. Om STUN inte är ett alternativ eftersom en av NAT:erna är en symmetrisk NAT (en typ av NAT som är känd för att vara icke-STUN-kompatibel), måste TURN användas.
Först kontaktar klienten en TURN-server med en "Allokera"-förfrågan. Allokeringsförfrågan ber TURN-servern att allokera några av sina resurser för klienten så att den kan kontakta en peer. Om allokering är möjlig, tilldelar servern en adress som klienten kan använda som relä, och skickar klienten ett "Allokering framgångsrikt"-svar, som innehåller en "tilldelad vidarebefordrad transportadress" som finns på TURN-servern.
För det andra skickar klienten in en CreatePermissions-förfrågan till TURN-servern för att skapa ett behörighetskontrollsystem för peer-server-kommunikation. Med andra ord, när en peer slutligen kontaktas och skickar information tillbaka till TURN-servern för att vidarebefordras till klienten, använder TURN-servern behörigheterna för att verifiera att peer-to-TURN-serverkommunikationen är giltig.
Efter att behörigheter har skapats har klienten två val för att skicka den faktiska datan, (1) den kan använda sändningsmekanismen, eller (2) den kan reservera en kanal med ChannelBind-förfrågan. Sändmekanismen är mer enkel, men innehåller en större rubrik, 36 byte, som avsevärt kan öka bandbredden i en TURN-reläkonversation. Däremot är ChannelBind-metoden lättare: rubriken är bara 4 byte, men den kräver att en kanal reserveras som måste uppdateras med jämna mellanrum, bland annat.
Genom att använda endera metoden, Send eller kanalbindning, tar TURN-servern emot data från klienten och vidarebefordrar den till peeren med hjälp av UDP-datagram, som innehåller den "Allokerade vidarebefordrade transportadressen" som källadress. Peeren tar emot datan och svarar, återigen med ett UDP-datagram som transportprotokoll, och skickar UDP-datagrammet till reläadressen på TURN-servern.
TURN-servern tar emot peer-UDP-datagrammet, kontrollerar behörigheterna och om de är giltiga skickar den vidare till klienten.
Denna process kommer runt även symmetriska NAT:er eftersom både klienten och peer åtminstone kan prata med TURN-servern, som har allokerat en relä-IP-adress för kommunikation.
Medan TURN är mer robust än STUN genom att det hjälper till att passera fler typer av NAT:er, vidarebefordrar en TURN-kommunikation hela kommunikationen genom servern som kräver mycket mer serverbandbredd än STUN-protokollet, som vanligtvis bara löser IP-adresser och reläer som vänder sig till allmänheten. informationen till klienten och peer för dem att använda i direkt kommunikation. Av denna anledning kräver ICE-protokollet STUN-användning som en första utväg, och TURN-användning endast när man hanterar symmetriska NAT:er eller andra situationer där STUN inte kan användas.