Tunneli ostaa topologiaa, ei salausta tai viivettä

Oletus on, että tunneli on yksityinen ja nopea johto: rakennat sen, ja sisällä oleva liikenne on salattua, polku on lyhyempi ja linkki käyttäytyy kuin kaapeli kahden toimipisteen välillä. Jokainen tämän oletuksen osa on erillinen ominaisuus, ja tunneli tarjoaa vain sen ensimmäisen asian, jota siltä pyysit, eli loogisen polun. Kaikki muu on valittava ja määritettävä tarkoituksella. Ominaisuuksien sekoittaminen johtaa siihen, että suunnittelu päätyy salattuun linkkiin, jota kukaan ei osaa vianmäärittää, ja viivelupaukseen, jota kukaan ei pysty pitämään.

Myytti: yksi tunneli, kolme takuuta

Tunneli tekee yhden asian luotettavasti. Se saa kaksi suoraan yhteydessä olevaa päätepistettä käyttäytymään kuin ne olisivat vierekkäisiä jotain tarkoitusta varten, samalla kun välissä oleva verkko kuljettaa ulommat paketit. Se on topologian muutos, ja se on itsessään todella hyödyllinen.

Salaus, protokollien kuljetus ja välityksen eristäminen ovat erillisiä päätöksiä sen päällä. GRE-tunnelissa ei ole yhtäkään niistä salauksen merkityksessä, ja IP-in-IP-tunneli on kelvollinen suunnittelu täysin ilman luottamuksellisuutta. Kumpikaan ei ole virhe; ne ovat tunneleita, jotka tekevät täsmälleen sen, mitä tunnelit tekevät. Kaavion merkintä ei kerro, mitkä ominaisuudet ovat läsnä.

Kun erotat ominaisuudet, kysymyksiin voi vastata: kuljettaako tämä tunneli reitityksen naapuruutta, kuljettaako se kehyksiä, piilottaako se sisäiset osoitteet, lupasiko se mitään viiveestä? Ne ovat neljä eri vastausta ja neljä erilaista määritysseurausta.

Mitä tunneli todella lisää kartalle

Päätepisteet saavat polun, jota niillä ei ollut ennen. Käyttäytyykö tämä polku reititettynä hyppynä vai Ethernet-segmenttinä, riippuu täysin kapseloinnista, ja ero muuttaa sitä, mitä kaksi toimipistettä voi tehdä sillä. Reititetty tunneli antaa sinulle seuraavan hypyn ja etuliitteen; Ethernet-laajennus antaa sinulle lähetyskäyttäytymisen ja paljon suuremman vikaantumisalueen.

IP-tunneli ei tee kaukaisesta toimipisteestä automaattisesti saman aliverkon osaa eikä saa reititysprotokollaa kulkemaan sen yli, ellei toteutus tue tätä naapuruutta. Multicast on toinen erillinen kysymys omalla vastauksellaan.

ip -d link show type gre
ip route get 10.20.0.5
traceroute -n -T -p 443 10.20.0.5
mtr -n --report -c 20 10.20.0.5

Nämä komennot vastaavat kysymyksen eri osiin. Ensimmäinen kertoo, millainen rajapinta on olemassa, toinen kertoo, minkä polun ydin valitsisi, ja kaksi viimeistä näyttävät alustan todellisen käyttäytymisen merkinnän lupauksen sijaan.

Kuljetus on erillinen päätös tavoitettavuudesta

Tunneli voi kuljettaa protokollaa, jota alusta ei välitä. IPv6 IPv4-polun yli on klassinen tapaus, ja se toimii, koska päätepisteet ymmärtävät molemmat perheet, kun taas niiden väliset reitittimet tarvitsevat vain ulompien pakettien toimittamisen. Alusta tarvitsee toimivan polun tunnelin päätepisteeseen eikä mitään muuta.

Päätepisteet tarvitsevat kuitenkin täyden tuen: välityksen, osoitteet ja sovelluksen, joka todella käyttää sisäistä perhettä. IPv6-etuliitteen antaminen tunnelille ei tee vain IPv4:llä toimivaa palvelua tavoitettavaksi IPv6:n kautta eikä tee alustasta kaksipinoista.

Kehysten kuljetus on suurempi sitoumus kuin protokollien kuljetus. Lähetysalueen laajentaminen tunnelin yli siirtää mukanaan spanning tree -käyttäytymisen, ARP:n ja vikojen leviämisen, mikä on suunnittelupäätös eikä ominaisuuskytkin.

Eristäminen ei ole luottamuksellisuutta

Palveluntarjoajien VPN:t pitävät asiakkaiden reitit ja liikenteen erillisissä välityskonteksteissa, ja tämä erottelu on todellista ja arvokasta. Se ei ole salausta. BGP/MPLS VPN -määrittely sanoo selvästi, että sen yksityisyys tulee välitysmallista eikä salauksesta, ja juuri tämä ero katoaa diassa, joka vain sanoo VPN.

Jos tarvitset luottamuksellisuutta, tarvitset salausmekanismin, jossa on todennus ja avainten hallinta, ja sinun on tiedettävä, mihin se päättyy. Erottelun tarjoava tunneli ja salauksen tarjoava tunneli voivat olla sama tunneli, mutta vain kun joku on määrittänyt molemmat.

Käytännön seuraus on, että „se on VPN:ssä“ vastaa kysymykseen reitityskontekstista eikä kerro sinulle mitään siitä, kuka voi lukea polun tavut. Kaksi tiimiä voivat olla molemmat oikeassa ja silti kuvata eri asioita. Kun turvallisuuskysymys tulee esiin, kysy mihin salaus päättyy ja mikä todentaa vastapuolet, älä sitä, onko tunneli olemassa.

Viive ja QoS seuraavat alustaa

Looginen reuna ei ole lyhyempi fyysinen polku. Ulommat paketit kulkevat edelleen samoja linkkejä, jonoja ja palveluntarjoajia pitkin, ja kapselointi lisää pakettikohtaisen ylimääräisen rasituksen sekä käsittelyn molemmissa päissä. Tunneli voi olla nopea, koska alusta on hyvä, ei koskaan siksi, että se on tunneli.

Palvelun laadun käsittely on vielä huonompaa, koska se riippuu hallinnollisista alueista, joita et ehkä hallitse. Sisäiset merkinnät on kartoitettava ulkoisiksi tarkoituksella, ja jokaisen polun palveluntarjoajan on tarjottava odottamasi käsittely. Salaus ei luo prioriteettia; se piilottaa kentän, jota välilaite olisi voinut käyttää vuon luokitteluun.

Mittaa alusta ennen kuin lupaat mitään. Raportti, joka osoittaa vakaan viiveen ja nollan häviön ulommalla polulla, on todiste; kaavio, jossa on tunneli, ei ole.

Valitse tunneli tarvitsemasi verkkosuhteen mukaan ja määritä sitten salaus, käyttöoikeuskäytäntö, pakettikoko ja suorituskyky erikseen. Neljä päätöstä, neljä todistetta, eikä yhtään yksittäistä merkintää minkään niiden sijasta.