Az alagút topológiát ad, nem titkosítást vagy késleltetést
Az alagút logikai útvonalat ad, és talán külön továbbítási kontextust. Önmagában nem titkosít, és nem ígér késleltetést.
A feltevés az, hogy az alagút egy privát, gyors vezeték: megépíted, és a benne lévő forgalom titkosított, az útvonal rövidebb, a kapcsolat pedig úgy viselkedik, mint egy kábel két telephely között. Ennek a feltevésnek minden része külön tulajdonság, és az alagút csak az első dolgot adja, amit kértél tőle, vagyis egy logikai útvonalat. Minden mást szándékosan kell kiválasztani és beállítani. A tulajdonságok összekeverése az, ahogyan egy tervezés végül egy olyan titkosított kapcsolathoz jut, amit senki nem tud hibakeresni, és egy olyan késleltetési ígérethez, amit senki nem tud betartani.
A mítosz: egy alagút, három garancia
Az alagút egy dolgot tesz megbízhatóan. Két végpontot, amelyek nincsenek közvetlenül összekötve, úgy viselkedtet, mintha valamilyen célból szomszédosak lennének, miközben a közbeeső hálózat a külső csomagokat szállítja. Ez topológiaváltozás, és önmagában valóban hasznos.
A titkosítás, a protokollszállítás és a továbbítás elkülönítése külön döntések, amelyek erre épülnek. A GRE-alagútnak kriptográfiai értelemben egyik sincs meg, az IP-in-IP-alagút pedig érvényes tervezés mindenféle bizalmasság nélkül. Egyik sem hiba; ezek alagutak, amelyek pontosan azt teszik, amit az alagutak tesznek. A diagramon lévő címke nem mondja meg, mely tulajdonságok vannak jelen.
Ha szétválasztod a tulajdonságokat, a kérdések megválaszolhatóvá válnak: szállít-e ez az alagút útválasztási szomszédságot, szállít-e kereteket, elrejti-e a belső címeket, ígér-e bármit a késleltetésről? Ez négy különböző válasz, négy különböző konfigurációs következménnyel.
Mit ad valójában az alagút a térképhez
A végpontok olyan útvonalat kapnak, amely korábban nem volt. Hogy ez az útvonal útválasztott ugrásként vagy Ethernet-szegmensként viselkedik, teljesen a csomagolástól függ, és a különbség megváltoztatja, mit tehet a két telephely vele. Az útválasztott alagút következő ugrást és előtagot ad; az Ethernet-kiterjesztés sugárzási viselkedést és sokkal nagyobb hiba tartományt ad.
Az IP-alagút nem teszi automatikusan a távoli telephelyet ugyanannak az alhálózatnak a részévé, és nem indít el rajta útválasztási protokollt, hacsak a megvalósítás nem támogatja ezt a szomszédságot. A Multicast egy másik külön kérdés, saját válasszal.
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
Ezek a parancsok a kérdés különböző részeire válaszolnak. Az első megmondja, milyen típusú interfész létezik, a második megmondja, melyik útvonalat választaná a kernel, az utolsó kettő pedig az alsó réteg tényleges viselkedését mutatja a címke ígéret helyett.
A szállítás külön döntés az elérhetőségtől
Az alagút olyan protokollt szállíthat, amelyet az alsó réteg nem továbbít. Az IPv6 IPv4-es útvonalon a klasszikus eset, és működik, mert a végpontok mindkét családot értik, míg a köztük lévő útválasztóknak csak a külső csomagokat kell kézbesíteniük. Az alsó rétegnek működő útvonalra van szüksége az alagút végpontjáig, és semmi többre.
A végpontoknak azonban teljes támogatásra van szükségük: továbbításra, címekre és olyan alkalmazásra, amely valóban használja a belső családot. Egy IPv6-előtag alagúthoz rendelése nem teszi a csak IPv4-en működő szolgáltatást elérhetővé IPv6-on keresztül, és nem teszi az alsó réteget kettős veremmé.
A keretszállítás nagyobb elkötelezettség, mint a protokollszállítás. Egy sugárzási tartomány alagúton át történő kiterjesztése magával viszi a feszítőfa viselkedését, az ARP-t és a hiba terjedését, ami tervezési döntés, nem funkciókapcsoló.
Az elkülönítés nem bizalmasság
A szolgáltatói VPN-ek külön továbbítási kontextusokban tartják az ügyfélútvonalakat és a forgalmat, és ez az elkülönítés valódi és értékes. Ez nem titkosítás. A BGP/MPLS VPN specifikáció kimondja, hogy a magánjellege a továbbítási modellből jön, nem a kriptográfiából, és pontosan ez a megkülönböztetés vész el egy olyan dián, amely csak annyit mond, hogy VPN.
Ha bizalmasságra van szükséged, kriptográfiai mechanizmusra van szükséged hitelesítéssel és kulcskezeléssel, és tudnod kell, hol végződik. Az elkülönítést nyújtó alagút és a titkosítást nyújtó alagút ugyanaz az alagút lehet, de csak akkor, ha valaki mindkettőt beállította.
A gyakorlati következmény az, hogy a „VPN-ben van” egy útválasztási kontextusra vonatkozó kérdésre válaszol, és semmit nem mond arról, ki olvashatja az útvonalon lévő bájtokat. Két csapat egyszerre lehet igaz, és mégis különböző dolgokat írhat le. Amikor felmerül a biztonsági kérdés, kérdezd meg, hol végződik a kriptográfia, és mi hitelesíti a partnereket, ne azt, hogy létezik-e alagút.
A késleltetés és a QoS az alsó réteget követi
A logikai él nem rövidebb fizikai útvonal. A külső csomagok továbbra is ugyanazokon a kapcsolatokon, sorokon és szolgáltatókon haladnak át, a csomagolás pedig csomagonkénti többletterhet és mindkét végén feldolgozást ad hozzá. Az alagút lehet gyors, mert az alsó réteg jó, soha nem azért, mert alagút.
A szolgáltatásminőség kezelése ennél is rosszabb, mert olyan adminisztratív tartományoktól függ, amelyeket lehet, hogy nem ellenőrzöl. A belső jelöléseket szándékosan kell a külső jelölésekre leképezni, és az útvonal minden szolgáltatójának nyújtania kell a várt kezelést. A titkosítás nem hoz létre prioritást; elrejti azt a mezőt, amelyet egy köztes eszköz a folyam osztályozására használhatott.
Mérd meg az alsó réteget, mielőtt bármit ígérsz. Az a jelentés, amely stabil késleltetést és veszteség nélküli külső útvonalat mutat, bizonyíték; egy alagutat ábrázoló diagram nem az.
Válaszd az alagutat a szükséges hálózati viszonyhoz, majd külön add meg a titkosítást, a hozzáférési szabályzatot, a csomagméretet és a teljesítményt. Négy döntés, négy bizonyíték, és egyetlen címke sem áll helyt egyik helyett sem.