Тунелът дава топология, а не криптиране или латентност

Предположението е, че тунелът е частен, бърз проводник: изграждате го и трафикът вътре е криптиран, пътят е по-кратък, а връзката се държи като кабел между два обекта. Всяка част от това предположение е отделно свойство, а тунелът доставя само първото нещо, което сте поискали от него, а именно логически път. Всичко останало трябва да бъде избрано и конфигурирано нарочно. Объркването на свойствата е начинът, по който един проект стига до криптирана връзка, която никой не може да диагностицира, и до обещание за латентност, което никой не може да удържи.

Мифът: един тунел, три гаранции

Тунелът надеждно прави едно нещо. Кара две крайни точки, които не са пряко свързани, да се държат като съседни за някаква цел, докато междинната мрежа пренася външните пакети. Това е промяна в топологията и тя е наистина полезна сама по себе си.

Криптирането, пренасянето на протоколи и изолацията на препращането са отделни решения, наслоени отгоре. Тунелът GRE няма нито едно от трите в криптографския смисъл, а тунелът IP-in-IP е валиден дизайн напълно без поверителност. Нито едно от двете не е грешка; това са тунели, които правят точно това, което правят тунелите. Етикетът на диаграмата не показва кои свойства присъстват.

След като разделите свойствата, въпросите стават отговорими: носи ли този тунел съседство за маршрутизация, носи ли кадри, скрива ли вътрешните адреси, обещава ли нещо за закъснението? Това са четири различни отговора с четири различни последствия за конфигурацията.

Какво всъщност добавя тунелът към картата

Крайните точки получават път, който преди не са имали. Дали този път се държи като маршрутизиран хоп или като Ethernet сегмент, зависи изцяло от инкапсулацията и разликата променя какво могат да правят двата обекта с него. Маршрутизираният тунел ви дава следващ хоп и префикс; разширението на Ethernet ви дава поведение на широко излъчване и много по-голям домейн на отказ.

IP тунелът не прави отдалечения обект автоматично част от същата подмрежа и не кара протокол за маршрутизация да работи през него, освен ако реализацията не поддържа това съседство. Multicast е друг отделен въпрос със свой собствен отговор.

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

Тези команди отговарят на различни части от въпроса. Първата казва какъв тип интерфейс съществува, втората казва кой път би избрало ядрото, а последните две показват действителното поведение на долния слой, а не обещанието на етикета.

Пренасянето е отделно решение от достижимостта

Тунелът може да пренася протокол, който долният слой не препраща. IPv6 през път IPv4 е класическият случай и работи, защото крайните точки разбират и двете семейства, докато рутерите между тях трябва само да доставят външните пакети. Долният слой се нуждае от работещ път до крайната точка на тунела и нищо повече.

Крайните точки обаче се нуждаят от пълна поддръжка: препращане, адреси и приложение, което действително използва вътрешното семейство. Задаването на префикс IPv6 на тунел не прави услуга, работеща само с IPv4, достъпна през IPv6 и не прави долния слой двустеков.

Пренасянето на кадри е по-голям ангажимент от пренасянето на протоколи. Разширяването на домейн за широко излъчване през тунел премества заедно с него поведението на spanning tree, ARP и разпространението на откази, което е проектно решение, а не превключвател на функция.

Изолацията не е поверителност

Доставчиците на VPN държат маршрутите и трафика на клиентите в отделни контексти за препращане и това разделение е истинско и ценно. То не е криптиране. Спецификацията на BGP/MPLS VPN изрично казва, че нейната поверителност идва от модела на препращане, а не от криптографията, и точно това разграничение се губи в слайд, който просто казва VPN.

Ако имате нужда от поверителност, имате нужда от криптографски механизъм с удостоверяване и управление на ключове и трябва да знаете къде той завършва. Тунел, който осигурява разделение, и тунел, който осигурява криптиране, могат да бъдат един и същ тунел, но само когато някой е конфигурирал и двете.

Практическото следствие е, че „това е във VPN“ отговаря на въпрос за контекста на маршрутизация и не ви казва нищо за това кой може да чете байтовете по пътя. Два екипа могат да бъдат едновременно прави и пак да описват различни неща. Когато възникне въпросът за сигурността, питайте къде завършва криптографията и какво удостоверява партньорите, а не дали съществува тунел.

Латентността и QoS следват долния слой

Логическият ръб не е по-кратък физически път. Външните пакети все още преминават през същите връзки, опашки и доставчици, а инкапсулацията добавя разходи за всеки пакет плюс обработка в двата края. Тунелът може да е бърз, защото долният слой е добър, никога защото е тунел.

Обработката на качеството на услугата е по-лоша от това, защото зависи от административни домейни, които може да не контролирате. Вътрешните маркировки трябва да се съпоставят с външните умишлено и всеки доставчик по пътя трябва да предлага обработката, която очаквате. Криптирането не създава приоритет; то скрива полето, което междинно устройство може да е използвало, за да класифицира потока.

Измерете долния слой, преди да обещаете нещо. Доклад, който показва стабилно закъснение и липса на загуби по външния път, е доказателство; диаграма с тунел върху нея не е.

Изберете тунела за мрежовата връзка, от която се нуждаете, след което задайте отделно криптирането, политиката за достъп, размера на пакета и производителността. Четири решения, четири доказателства и нито един етикет, който да замества някое от тях.