En tunnel köper topologi, inte kryptering eller latens

Antagandet är att en tunnel är en privat, snabb ledning: du bygger en, och trafiken inuti är krypterad, vägen är kortare och länken beter sig som en kabel mellan två platser. Varje del av det antagandet är en separat egenskap, och tunneln levererar bara det första du bad den om, nämligen en logisk väg. Allt annat måste väljas och konfigureras med avsikt. Att blanda ihop egenskaperna är hur en design slutar med en krypterad länk som ingen kan felsöka och ett latenslöfte som ingen kan hålla.

Myten: en tunnel, tre garantier

En tunnel gör en sak pålitligt. Den får två ändpunkter som inte är direkt sammankopplade att bete sig som om de vore angränsande för något syfte, medan nätet däremellan bär de yttre paketen. Det är en topologiförändring, och den är verkligen användbar i sig.

Kryptering, protokolltransport och vidarebefordringsisolering är separata beslut ovanpå. En GRE-tunnel har ingen av de tre i kryptografisk mening, och en IP-in-IP-tunnel är en giltig design helt utan sekretess. Ingen av dem är ett misstag; de är tunnlar som gör exakt det tunnlar gör. Etiketten på diagrammet berättar inte vilka egenskaper som finns.

När du separerar egenskaperna blir frågorna besvarbara: bär den här tunneln ett routinggrannskap, bär den ramar, döljer den de inre adresserna, lovar den något om fördröjning? Det är fyra olika svar med fyra olika konfigurationskonsekvenser.

Vad tunneln faktiskt tillför kartan

Ändpunkterna får en väg de inte hade tidigare. Om den vägen beter sig som ett routat hopp eller som ett Ethernet-segment beror helt på inkapslingen, och skillnaden ändrar vad de två platserna kan göra med den. En routad tunnel ger dig ett nästa hopp och ett prefix; en Ethernet-utökning ger dig broadcastbeteende och en mycket större felddomän.

En IP-tunnel gör inte automatiskt den avlägsna platsen till en del av samma subnät, och den får inte ett routingprotokoll att köra över den om inte implementeringen stöder det grannskapet. Multicast är en annan separat fråga med sitt eget svar.

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

De kommandona besvarar olika delar av frågan. Den första säger vilken typ av gränssnitt som finns, den andra säger vilken väg kärnan skulle välja, och de två sista visar underlagets faktiska beteende i stället för etikettens löfte.

Transport är ett separat beslut från räckvidd

En tunnel kan bära ett protokoll som underlaget inte vidarebefordrar. IPv6 över en IPv4-väg är det klassiska fallet, och det fungerar eftersom ändpunkterna förstår båda familjerna medan routrarna däremellan bara behöver leverera de yttre paketen. Underlaget behöver en fungerande väg till tunnelns ändpunkt och inget mer.

Ändpunkterna behöver dock fullt stöd: vidarebefordran, adresser och en applikation som faktiskt använder den inre familjen. Att tilldela ett IPv6-prefix till en tunnel gör inte en tjänst som bara kör IPv4 nåbar över IPv6, och det gör inte underlaget dual-stack.

Ramtransport är ett större åtagande än protokolltransport. Att utöka en broadcastdomän över en tunnel flyttar spanning tree-beteende, ARP och felutbredning med sig, vilket är ett designbeslut och inte en funktionsbrytare.

Isolering är inte sekretess

Leverantörs-VPN håller kundernas rutter och trafik i separata vidarebefordringskontexter, och den separationen är verklig och värdefull. Det är inte kryptering. BGP/MPLS VPN-specifikationen säger uttryckligen att dess integritet kommer från vidarebefordringsmodellen och inte från kryptografi, och det är precis den skillnaden som går förlorad i en bild som bara säger VPN.

Om du behöver sekretess behöver du en kryptografisk mekanism med autentisering och nyckelhantering, och du måste veta var den slutar. En tunnel som ger separation och en tunnel som ger kryptering kan vara samma tunnel, men bara när någon har konfigurerat båda.

Den praktiska konsekvensen är att «det är i ett VPN» besvarar en fråga om routingkontexten och inte säger dig något om vem som kan läsa byten på vägen. Två team kan båda ha rätt och ändå beskriva olika saker. När säkerhetsfrågan kommer upp, fråga var kryptografin slutar och vad som autentiserar parterna, inte om det finns en tunnel.

Latens och QoS följer underlaget

En logisk kant är inte en kortare fysisk väg. De yttre paketen passerar fortfarande samma länkar, köer och leverantörer, och inkapsling lägger till overhead per paket plus bearbetning i båda ändar. En tunnel kan vara snabb för att underlaget är bra, aldrig för att den är en tunnel.

Behandlingen av tjänstekvalitet är värre än så, eftersom den beror på administrativa domäner du kanske inte kontrollerar. Inre markeringar måste medvetet mappas till yttre markeringar, och varje leverantör på vägen måste erbjuda den behandling du förväntar dig. Kryptering skapar ingen prioritet; den döljer fältet som en mellanliggande burk hade kunnat använda för att klassificera flödet.

Mät underlaget innan du lovar något. En rapport som visar stabil fördröjning och ingen förlust på den yttre vägen är bevis; ett diagram med en tunnel på är det inte.

Välj tunneln för den nätverksrelation du behöver och ange sedan kryptering, åtkomstpolicy, paketstorlek och prestanda var för sig. Fyra beslut, fyra bevis och ingen enda etikett som står i stället för något av dem.