Jotkut yhteysongelmat eivät johdu käyttämästäsi sovelluksesta. Ne tulevat laitteiden väliseltä verkkopolulta.

Saatat huomata tämän, kun puhelu yhdistetään välittömästi kotipuhelimella Wi-Fi, mutta hotelli Wi-Fi vaikeutuu, kun peliaula toimii yhdelle pelaajalle ja epäonnistuu toisella tai kun tietosuojatyökalu toimii eri tavalla, kun siirryt mobiilidatasta toimistoverkkoon. Yksi yleinen syy on NAT: verkko-osoitteiden käännöskerros, jonka avulla monet laitteet voivat jakaa yhden julkisen Internet-osoitteen.

Tässä artikkelissa selitetään, mitä NAT:n läpikulku on, miksi UDP-rei’itys on olemassa, milloin releen varauksista tulee hyödyllisiä ja miksi VPN Satelites-lukijoiden tulisi käsitellä näitä käsitteitä yhteyskontekstina eikä taikatakuina.

Mitä NAT tekee jokapäiväisissä verkoissa

Useimmat ihmiset käyttävät yksityisiä verkkoja ajattelematta niitä. Kannettava tietokone, puhelin, tabletti ja televisio voivat kaikki olla saman reitittimen takana. Kodin sisällä jokaisella laitteella on oma yksityinen osoite. Laajemmassa Internetissä ne näyttävät usein jakavan yhden julkisen osoitteen.

Tuo käännös on hyödyllinen. Se auttaa verkkoja säilyttämään julkiset IPv4-osoitteet ja pitämään normaalin kotireitityksen hallittavana. Mutta se luo myös käytännön ongelman: verkon ulkopuolella oleva laite ei yleensä voi vain avata suoraa yhteyttä verkossasi olevaan laitteeseen, ellei reititin tiedä, minne tulevan liikenteen pitäisi mennä.

Tavalliseen web-selailuun se on yleensä hyvä. Laitteesi käynnistää yhteyden ulospäin, reititin muistaa kartoituksen ja vastaukset tulevat takaisin tätä väliaikaista polkua pitkin. Sovelluksissa, jotka tarvitsevat kaksi päätepistettä kommunikoidakseen suoremmin, etenkin UDP:n kautta, tilanne voi olla vähemmän ennustettavissa.

Tämä on NAT-läpiviennin perusasetus.

Mikä on NAT Traversal?

NAT traversal on yleinen nimi tekniikoille, jotka auttavat sovelluksia kommunikoimaan verkkojen välillä, joissa yksi tai molemmat päätepisteet sijaitsevat NAT:n takana.

Selkeästi englanniksi sovellus yrittää vastata käytännölliseen kysymykseen: ”Löytävätkö nämä kaksi laitetta toimivan polun toisiinsa, vaikka niiden reitittimet kääntävät osoitteita ja suodattavat saapuvaa liikennettä?”

Ei ole yhtä yleistä vastausta, koska NAT:n käyttäytyminen vaihtelee. Standardit, kuten IETF RFC 4787, kuvaavat NAT:n toimintaa UDP:lle ja selittävät, miksi johdonmukaisuus on tärkeää reaaliaikaisissa sovelluksissa, kuten multimediaviestinnässä ja verkkopelaamisessa. Sama laaja ongelma esiintyy monissa nykyaikaisissa sovellusluokissa: puhelut, yhteistyötyökalut, pelit, etäkäyttötyökalut, vertaistyyppiset järjestelmät ja VPN:n kaltaiset sovellukset voivat vaikuttaa verkkojen liikenteen käsittelyyn.

VPN Satelites-lukijoiden hyödyllinen ominaisuus on yksinkertainen: jos yhteys toimii eri tavalla eri verkoissa, se voi kuvastaa reitittimen käyttäytymistä, operaattoritason NAT:tä, palomuurikäytäntöä, pakettisuodatusta, ruuhkaa tai muita polkuolosuhteita. Sitä ei pitäisi automaattisesti lukea todisteeksi siitä, että yksi sovellusasetus on rikki.

Mikä on UDP-rei’itys?

UDP:tä käytetään usein reaaliaikaisissa sovelluksissa, koska se voi välttää osan yhteyssuuntautuneeseen liikenteeseen liittyvästä viiveestä ja ylikuormituksesta. Mutta UDP ei luo pitkäikäistä istuntoa samalla tavalla kuin monet ihmiset kuvittelevat perinteisen yhteyden.

UDP-rei’itys on NAT-läpikulkutekniikka, jossa kaksi päätepistettä lähettää kumpikin lähteviä UDP-paketteja, joten niiden NAT-laitteet luovat väliaikaisia kartoituksia. Jos ajoitus ja NAT-käyttäytyminen kohtaavat, liikenne toiselta puolelta voi palata näiden kartoitusten kautta.

Lause kuulostaa aggressiiviselta, mutta konsepti on tavallisempi kuin nimi antaa ymmärtää. Kyse on työskentelystä reitittimen olemassa olevien lähtevän ja paluuliikenteen sääntöjen kanssa. Bryan Ford:n, Pyda Srisuresh:n ja Dan Kegel:n perustavanlaatuisen tutkimuksen mukaan rei’itys on käytännöllinen lähestymistapa, jota käytetään UDP-pohjaisissa sovelluksissa, mutta samalla se korostaa keskeistä rajoitusta: mikään läpikulkutekniikka ei toimi kaikissa NAT-asennuksissa.

Tällä rajoituksella on merkitystä. Jotkut verkot käyttävät kartoituksia hyödyllisellä tavalla. Toiset luovat kartoituksia, jotka on sidottu suppeammin tiettyyn kohteeseen. Jotkut verkot lisäävät palomuuritoiminnan NAT:n päälle. Jotkut mobiili- ja ISP-verkot sijoittavat käyttäjät operaattoritason NAT:n taakse, jolloin käyttäjä ei hallitse ylävirran käännöskerrosta ollenkaan.

Joten kun joku kysyy, mitä on UDP-rei’itys, lyhyt vastaus on: se on tapa sovelluksille yrittää suoraa UDP-polkua NAT-luomien kartoitusten kautta. Varovainen vastaus on: se voi toimia hyvin monissa ympäristöissä, mutta se ei ole takuu.

Miksi suorat yhteydet joskus epäonnistuvat

Suora yhteys voi epäonnistua useista tavallisista syistä:

Reititin ei saa käyttää samaa ulkoista porttikartoitusta uudelleen, kun sovellus ottaa yhteyttä eri kohteisiin.
Verkko saattaa suodattaa saapuvat UDP-paketit tiukemmin kuin toinen verkko.
Operaattoritason NAT-kerros voi olla käyttäjän ja julkisen Internetin välissä.
Työpaikka, koulu, hotelli tai tapahtumapaikkaverkosto voi rajoittaa liikennettä oman käytäntönsä mukaisesti.
Matkaviestinverkko voi muuttaa polkuja signaalin laadun tai verkkoliitännäisten muuttuessa.
Tietoturvatuote tai paikallinen palomuuri voi estää liikenteen ennen kuin se saavuttaa sovelluksen.

Mikään näistä tapauksista ei tarkoita, että käyttäjien pitäisi yrittää ohittaa sääntöjä, joita he eivät hallitse. Käytännön pointti on ymmärtää, että yhteyden käyttäytyminen riippuu useammasta kuin yhdestä sovelluksen mieltymyksestä. Jos verkko tarkoituksella estää tai rajoittaa tietyntyyppistä liikennettä, oikea seuraava askel on yleensä käyttää sallittua verkkoa, tarkistaa palveluehdot tai keskustella verkon ylläpitäjän kanssa.

Missä Relay Fallbacks sopii

Kun suora yhteys on epäluotettava, jotkin järjestelmät käyttävät välitystä: molemmat päätepisteet muodostavat yhteyden ulospäin välipalvelimeen ja palvelin välittää liikennettä niiden välillä. IETF RFC 5766 kuvaa TURN:n, joka on lyhenne sanoista läpikulku käyttämällä NAT:n ympärillä olevia releitä, protokollana releavusteiseen tiedonsiirtoon, kun suora vertaisviestintä ei ole mahdollista tietyissä NAT-tilanteissa.

Releet ratkaisevat eri ongelman kuin suora NAT-läpikulku. Rele voi parantaa tavoitettavuutta, koska molempien laitteiden tarvitsee vain tavoittaa välityspalvelu. Kompromissi on, että liikenne vie ylimääräistä polkua, mikä voi lisätä latenssia, kaistanleveyden kustannuksia ja toiminnan monimutkaisuutta.

Tästä syystä monet liitäntämallit haluavat kokeilla ensin suoraa polkua ja palata sitten takaisin tarvittaessa. IETF RFC 8445 kuvailee ICE:n standardin jäljitysmenetelmänä NAT:n läpikulkuun UDP-pohjaisessa viestinnässä, joka käyttää STUN- ja TURN-konsepteja mahdollisten polkujen löytämiseen ja testaamiseen. Tämä ei tarkoita, että kaikki VPN:hen liittyvät työkalut käyttävät ICE:tä, STUN:tä tai TURN:tä. Se näyttää yksinkertaisesti yleisen suunnittelumallin: testaa, mikä polku toimii, ja käytä sitten varavaihtoehtoa, jos suoraa yhteyttä ei ole saatavilla.

Lukijoille tärkeä opetus on realististen odotusten asettaminen. Releen palautus voi mahdollistaa yhteyden muodostamisen tilanteissa, joissa suora reitti epäonnistuu, mutta se ei ole sama asia kuin jokaisen verkkotilanteen katoaminen.

Mitä tämä tarkoittaa VPN Satelites-lukijoiden kannalta

VPN Satelites-sisältö on usein lähellä aiheita, kuten yksityisyyttä, yhteyksiä, Internet-reititystä ja käyttäjien odotuksia. NAT traversal kuuluu samaan koulutusalueeseen, koska se selittää, miksi sovelluksen ympärillä oleva verkko voi olla yhtä tärkeä kuin itse sovellus.

Tässä aiheessa on tärkeää pitää tuotteen liitäntä vaatimattomana. Tämä artikkeli ei väitä, että VPN Satelites käyttäisi mitään tiettyä NAT-läpikulkumenetelmää, välitysarkkitehtuuria, portin edelleenlähetysasetuksia, staattista IP-vaihtoehtoa tai protokollapinoa. Arvoa tässä on käytännön lukutaito: termien ymmärtäminen auttaa sinua lukemaan vianetsintäohjeet tarkemmin ja arvioimaan yhteysongelmia odottamatta minkään VPN:hen liittyvän sovelluksen ohittavan jokaisen verkkosäännön.

Jos yhteys on epävakaa, muutama vähäriskinen tarkistus voi auttaa sinua erottamaan sovelluksen toiminnan verkon toiminnasta:

Kokeile toista sallittua verkkoa, kuten koti-Wi-Fi ja mobiilidata, ja huomioi, seuraako ongelma sovellusta vai verkkoa.
Käynnistä paikallinen reititin uudelleen, jos hallitset sitä ja normaali yhteys näyttää heikentyneeltä.
Tarkista, hallinnoiko verkkoa työpaikka, koulu, hotelli, tapahtumapaikka tai Internet-palveluntarjoaja, jolla on liikennerajoituksia.
Pidä sovellus ja käyttöjärjestelmä ajan tasalla, koska yhteydenkäsittely voi vaihdella versioittain.
Vältä reitittimen tai palomuurin lisäasetusten muuttamista, ellet ymmärrä vaikutusta tai sinulla on järjestelmänvalvojan hyväksyntä.

Nämä vaiheet eivät ohita rajoituksia. Ne auttavat tunnistamaan, mistä yhteysongelma voi johtua.

Kuinka lukea NAT:n läpikulkuväitteet huolellisesti

Kun näet tuotteen, protokollan tai sovelluksen puhuvan NAT-läpikulusta, lue väite tarkasti.

Hyödyllisiä kysymyksiä ovat mm.

Koskeeko väite yleistä verkkotekniikkaa vai vahvistettua tuotteen ominaisuutta?
Selittääkö se, mitä verkkoehtoja tuetaan ja mitä ei?
Mainitseeko se varakäyttäytymisen lupaamatta täydellistä tavoitettavuutta?
Vältetäänkö siinä ehdotuksia, että käyttäjät voisivat jättää huomiotta työpaikan, koulun, Internet-palveluntarjoajan, alustan tai lailliset rajoitukset?
Erottaako se tietosuojavaatimukset yhteysvaatimuksista?

Tämä viimeinen kohta on helppo missata. Ominaisuus, joka auttaa kahta päätepistettä yhdistämään, ei ole automaattisesti tietosuojatakuu. Tietosuojaominaisuus ei automaattisesti takaa yhteystakuuta. Hyvän dokumentoinnin pitäisi pitää nämä ideat erillään.

UKK

Onko NAT:n läpikulku sama kuin VPN:n?

Ei. NAT traversal on joukko verkkotekniikoita osoitteenmuunnoksen ja päätepisteiden välisen suodatuksen käsittelyyn. VPN on laajempi luokka teknologiaa suojattujen verkkotunnelien luomiseen. Joidenkin VPN:n kaltaisten sovellusten on ehkä otettava huomioon NAT:n käyttäytyminen, mutta käsitteet eivät ole samat.

Toimiiko UDP-rei’itys aina?

Ei. UDP-rei’itys riippuu NAT-käyttäytymisestä, suodatussäännöistä, ajoituksesta ja verkkotopologiasta. Tutkimus ja standardikeskustelut viittaavat samaan käytännön todellisuuteen: NAT:n käyttäytyminen on vaihtelevaa, joten varapolkuja saatetaan tarvita.

Ovatko välitysvarat parempia kuin suorat kytkennät?

Ne ovat erilaisia. Rele voi auttaa, kun suora yhteys ei ole mahdollista, mutta se voi lisätä latenssia, kaistanleveyden käyttöä ja käyttökustannuksia. Suora polku voi olla tehokkaampi, kun se toimii, mutta se voi epäonnistua tiukemmissa verkoissa.

Sanotaanko tässä artikkelissa, että VPN Satelites käyttää STUN:tä, TURN:tä, ICE:tä, releitä tai portin edelleenohjausta?

Ei. Näitä termejä käsitellään yleisinä verkottumiskäsitteinä ja standardien taustana. Tässä artikkelissa ei esitetä VPN Satelites:n tuotekohtaisia toteutusväitteitä.

Voiko NAT:n läpikulku ohittaa verkon säännöt?

Tämä artikkeli ei tarjoa ohitusohjeita. NAT-läpikulku voi auttaa selittämään yhteyden käyttäytymistä, mutta käyttäjien tulee noudattaa sovellettavia lakeja, palveluehtoja ja verkkokäytäntöjä.

Bottom Line

NAT:n läpikulku on tärkeää, koska Internet-polku kahden laitteen välillä ei ole aina suora tai ennustettavissa. UDP-rei’itys voi auttaa joitain sovelluksia muodostamaan suoran yhteyden NAT:n välillä, kun taas releen varmistukset voivat auttaa suorien polkujen epäonnistuessa. Molemmat ideat ovat hyödyllisiä, mutta kumpikaan ei ole universaali ratkaisu.

VPN Satelites-lukijoiden käytännöllisin opetus on realististen odotusten asettaminen. Yhteyden luotettavuus riippuu sovelluksesta, laitteesta, paikallisesta verkosta, ylävirran verkkokäytännöistä ja laajemmasta päätepisteiden välisestä reitistä. Näiden tasojen ymmärtäminen tekee vianetsinnästä rauhallisempaa ja tuoteväitteet on helpompi lukea kriittisesti.