VPN vagy TURN-relé: melyik viszi át valójában a WebRTC-hívást?
Az alagút megváltoztatja az útvonalat, amelyet az ICE lát; soha nem foglal le relét és nem nyújt jelzésátvitelt. Hasonlítsa össze, mit ad egy VPN-kimenet és egy TURN-kiszolgáló.
Az oldal VPN-en keresztül töltődik be, a hívás mégsem kapcsolódik soha: két különböző hiba ugyanabban a címsorban. Az alagút megváltoztatta az útvonalat, amelyet a böngésző használ; nem lett jelzésátviteli szolgáltatás, STUN-kiszolgáló vagy relé, és nem dönti el, melyik jelöltpárt választja az ICE. Éppen az egyes összetevők feladatának szétválasztása az, ami a homályos „a WebRTC blokkolva van” mondatot konkrét hibává alakítja.
Négy feladat, amelyek közül az alagút csak egyet érint
Az alkalmazás valamilyen jelzésátviteli megoldáson keresztül cseréli a munkamenet-információkat, és ez az első feladat. Az ICE jelöltcímeket gyűjt és párokat tesztel, amíg egy működik, ez a második. A STUN lehetővé teszi, hogy a partner megtudja, hogyan látszik a forgalma kívülről, a TURN pedig relét foglal le azokra az esetekre, amikor nincs közvetlen útvonal. Ez a négy szerep különbözik, és a VPN azokra a címekre és szűrésre hat, amelyekkel találkoznak, ahelyett hogy bármelyiket biztosítaná.
Ezért a sikeres bejelentkezés semmit sem mond a média útvonaláról. A jelzésátvitel általában ugyanazon a HTTPS-en halad, amelyet az oldal már használ, a 443-as porton, míg a média UDP-n keresztül teljesen más célpontra juthat.
A privát címzés csak fokozza a zavart. Az alagút cím csak akkor hasznos a partnernek, ha annak van tervezett visszaútja hozzá; az, hogy privát, nem bizonyítéka a kölcsönös elérhetőségnek, és a böngészők sem így kezelik, amikor elvetik azokat a jelölteket, amelyeket nem lehet ellenőrizni. Egy jelölt, amely Önnek helyinek tűnik, a másik oldalról ellenőrizhetetlen lehet. Érdemes kizárni ezt a rést, mielőtt arra a következtetésre jut, hogy az alagút elnyeli a médiát.
Hasonlítsa össze a VPN-kimenetet egy TURN-relével
Mindkettő továbbít csomagokat, ezért összekeverik őket, és a fenti összehasonlító táblázatot érdemes oszlopról oszlopra olvasni, nem pedig funkciólistaként. A reléfoglalás munkamenetenkénti objektum, amelyet hitelesített kérés hoz létre; az alagút útvonal. Az egyiknek lejáró hitelesítő adatai vannak, a másiknak olyan partner címe, amely vagy elérhető, vagy nem.
| 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 |
A portszámok konkréttá teszik a különbséget. A TURN alapértelmezés szerint a 3478-as porton figyel UDP és TCP esetén, és az 5349-es porton TLS esetén, és egy olyan hálózat, amely engedi a 443-at, de eldobja ezeket a portokat, meghiúsítja a relén átvitt hívásokat, miközben a böngészés normálisan folytatódik. A VPN portjának megváltoztatása ezek egyikét sem állítja be, mert a fontos portok a relészolgáltatáshoz tartoznak, nem az alagúthoz.
Olvassa el a diagnosztikát, majd tesztelje a hívást
A böngészők csomagrögzítés nélkül feltárják a szükséges információkat. Nyissa meg a böngészője WebRTC diagnosztikai oldalát, bonyolítsa le a hívást, és a gyűjtött lista helyett az olvassa le, hogy melyik jelöltpárt választották: milyen helyi és távoli jelölt típusokat választottak, milyen átvitelen és címcsaládon keresztül, és hogy az útvonal közvetlen vagy relén átvezető.
Két olvasatot érdemes előre ismerni. Ha a választott pár gazdagép-gazdagép privát címeken, a média olyan útvonalon marad, amelyről lehet érvelni; ha relé-relé, a hívás relékapacitást fogyaszt, és az adott szolgáltatás elérhetőségétől függ. Az a hiba, amely a „ellenőrzés” állapotban megáll választott pár nélkül, azt jelenti, hogy a jelölteket összegyűjtötték, de egyik sem ment át a kapcsolódási ellenőrzéseken.
Ezután hasonlítsa össze ugyanazt a két végpontot ugyanabban a hívásban úgy, hogy csak egy jóváhagyott feltételt változtat meg, és az eredményt kétirányú médián vagy adaton fogadja el, ne egy „csatlakozva” jelzőn. A jelöltgyűjtés sok olyan esetben sikerül, amely egyetlen hangkockát sem visz át. Ismételje meg a hívást a változtatás másik oldalán, és őrizze meg mindkét diagnosztikai felvételt, mert két futás összehasonlítása többet mond, mint bármelyik egyedüli olvasása. Ugyanazok a végpontok, ugyanaz a kodek, egy megváltoztatott változó.
Az az alkalmazás, amely szándékosan relay-re állítja az ICE átviteli szabályzatát, csak relé jelölteket kér. Ez a beállítás nem hoz létre relét és nem javítja a hiányzó hitelesítő adatokat; egyértelművé teszi a követelményt, ami akkor hasznos, ha valaki a VPN-t hibáztatja egy olyan szabályzatért, amelyet az oldal választott.
Tartsa a magánéleti állítást olyan szűken, mint a bizonyítékok
A jelöltek felfedése a böngésző és az alkalmazás szabályzatától függ, nem csak az alagút állapotától, és a W3C partnerkapcsolati specifikációja az IP-kezelést saját ügyének tekinti. Ezért egy csatlakoztatott VPN gyenge alapja annak az ígéretnek, hogy egy hívás csak egy kiválasztott címet fed fel. Két partner ugyanazon alagút mögött akár olyan útvonalat is választhat, amely soha nem hagyja el a gazdagépet, ami egyszerre a magánélet javítása és a kapcsolódás korlátozása.
Amit pontosan állíthat, az szűkebb és hasznosabb: melyik jelöltpárt választották, melyik átvitel szállította, és hogy az az útvonal az alagúton belül maradt-e. Jegyezze fel ezt a három tényt egy működő és egy meghiúsuló hívásnál, és a különbség általában megnevezi a javítandó összetevőt.
Amikor a kapcsolódás működik, válassza szét a teljesítményt az elérhetőségtől. A veszteség, a késleltetés, a sorok és az MTU mind egy helyes jelöltpár alatt helyezkednek el, és egy akadozó hívás kapcsolódási hibaként kezelése ok nélkül küldi vissza a jelöltlistához.