Tunelis pērk topoloģiju, ne šifrēšanu vai latentumu

Pieņēmums ir tāds, ka tunelis ir privāts, ātrs vads: jūs to uzbūvējat, un iekšienē esošā plūsma ir šifrēta, ceļš ir īsāks, un saite uzvedas kā kabelis starp divām vietām. Katra šī pieņēmuma daļa ir atsevišķa īpašība, un tunelis sniedz tikai pirmo lietu, ko tam lūdzāt, proti, loģisku ceļu. Viss pārējais ir jāizvēlas un jākonfigurē apzināti. Īpašību sajaukšana ir tas, kā projekts nonāk pie šifrētas saites, kuru neviens nevar diagnosticēt, un latentuma solījuma, kuru neviens nevar izpildīt.

Mīts: viens tunelis, trīs garantijas

Tunelis droši dara vienu lietu. Tas liek diviem galapunktiem, kas nav tieši savienoti, uzvesties tā, it kā tie būtu blakus kādam mērķim, kamēr starpējais tīkls pārvadā ārējos paketes. Tā ir topoloģijas izmaiņa, un tā pati par sevi patiešām ir noderīga.

Šifrēšana, protokolu pārvadāšana un pārsūtīšanas izolācija ir atsevišķi lēmumi, kas tiek likti virsū. GRE tunelim kriptogrāfiskā nozīmē nav neviena no trim, un IP-in-IP tunelis ir derīgs projekts pilnīgi bez konfidencialitātes. Neviens no tiem nav kļūda; tie ir tuneļi, kas dara tieši to, ko dara tuneļi. Etiķete diagrammā nepasaka, kādas īpašības ir.

Kad īpašības ir atdalītas, jautājumi kļūst atbildami: vai šis tunelis pārvadā maršrutēšanas blakusumu, vai pārvadā kadrus, vai slēpj iekšējās adreses, vai sola kaut ko par aizturi? Tie ir četras dažādas atbildes ar četrām dažādām konfigurācijas sekām.

Ko tunelis patiešām pievieno kartei

Galapunkti iegūst ceļu, kāds tiem iepriekš nebija. Vai šis ceļš uzvedas kā maršrutēts lēciens vai kā Ethernet segments, pilnībā atkarīgs no iekapsulēšanas, un atšķirība maina to, ko abas vietas ar to var darīt. Maršrutēts tunelis dod jums nākamo lēcienu un prefiksu; Ethernet paplašinājums dod apraides uzvedību un daudz lielāku kļūmju domēnu.

IP tunelis automātiski nepadara attālo vietu par daļu no tā paša apakštīkla un neliek maršrutēšanas protokolam darboties tam pāri, ja vien ieviešana neatbalsta šo blakusumu. Multicast ir vēl viens atsevišķs jautājums ar savu atbildi.

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

Šīs komandas atbild uz dažādām jautājuma daļām. Pirmā pasaka, kāda veida saskarne pastāv, otrā pasaka, kuru ceļu izvēlētos kodols, un pēdējās divas parāda apakšējā slāņa faktisko uzvedību, nevis etiķetes solījumu.

Pārvadāšana ir atsevišķs lēmums no sasniedzamības

Tunelis var pārvadāt protokolu, ko apakšējais slānis nepārsūta. IPv6 pa IPv4 ceļu ir klasiskais gadījums, un tas darbojas, jo galapunkti saprot abas saimes, kamēr maršrutētājiem starp tiem ir tikai jāpiegādā ārējie paketes. Apakšējam slānim vajag strādājošu ceļu līdz tuneļa galam un neko vairāk.

Tomēr galapunktiem vajag pilnu atbalstu: pārsūtīšanu, adreses un lietojumprogrammu, kas patiešām izmanto iekšējo saimi. IPv6 prefiksa piešķiršana tunelim nepadara pakalpojumu, kas darbojas tikai ar IPv4, sasniedzamu caur IPv6, un nepadara apakšējo slāni dual-stack.

Kadru pārvadāšana ir lielāks pienākums nekā protokolu pārvadāšana. Apraides domēna paplašināšana pāri tunelim līdzi pārvieto spanning tree uzvedību, ARP un kļūmju izplatīšanos, kas ir projektēšanas lēmums, nevis funkcijas slēdzis.

Izolācija nav konfidencialitāte

Pakalpojumu sniedzēja VPN tur klientu maršrutus un plūsmu atsevišķos pārsūtīšanas kontekstos, un šī atdalīšana ir reāla un vērtīga. Tā nav šifrēšana. BGP/MPLS VPN specifikācija skaidri saka, ka tās privātums nāk no pārsūtīšanas modeļa, nevis no kriptogrāfijas, un tieši šī atšķirība pazūd slaidā, kas tikai saka VPN.

Ja jums vajag konfidencialitāti, jums vajag kriptogrāfisku mehānismu ar autentifikāciju un atslēgu pārvaldību, un jums jāzina, kur tas beidzas. Tunelis, kas nodrošina atdalīšanu, un tunelis, kas nodrošina šifrēšanu, var būt viens un tas pats tunelis, bet tikai tad, kad kāds ir konfigurējis abus.

Praktiskā sekas ir tā, ka „tas ir VPN“ atbild uz jautājumu par maršrutēšanas kontekstu un nepasaka neko par to, kas var lasīt ceļa baitus. Divas komandas var abas būt pareizas un tomēr aprakstīt dažādas lietas. Kad rodas drošības jautājums, jautājiet kur beidzas kriptogrāfija un kas autentificē partnerus, nevis vai tunelis pastāv.

Aizture un QoS seko apakšējam slānim

Loģiskā mala nav īsāks fiziskais ceļš. Ārējie pakešu joprojām šķērso tos pašus savienojumus, rindas un pakalpojumu sniedzējus, un iekapsulēšana pievieno papildu izmaksas uz pakešu un apstrādi abos galos. Tunelis var būt ātrs tāpēc, ka apakšējais slānis ir labs, nekad tāpēc, ka tas ir tunelis.

Pakalpojuma kvalitātes apstrāde ir vēl sliktāka, jo tā ir atkarīga no administratīviem domēniem, kurus jūs, iespējams, nekontrolējat. Iekšējie marķējumi ir apzināti jāattēlo uz ārējiem, un katram ceļā esošajam pakalpojumu sniedzējam ir jāpiedāvā apstrāde, kuru jūs gaidāt. Šifrēšana nerada prioritāti; tā slēpj lauku, ko starpniekierīce varēja izmantot plūsmas klasificēšanai.

Izmēriet apakšējo slāni pirms kaut ko solāt. Ziņojums, kas parāda stabilu aizturi un nekādus zudumus ārējā ceļā, ir pierādījums; diagramma ar tuneli tajā nav.

Izvēlieties tuneli vajadzīgajai tīkla attiecībām, pēc tam atsevišķi norādiet šifrēšanu, piekļuves politiku, pakešu lielumu un veiktspēju. Četri lēmumi, četri pierādījumi un neviena etiķete, kas stāvētu kādas no tām vietā.