L2TP, GRE vai IPsec: kuram slānim jānes sesija?

Divi jautājumi sapinas katru reizi, kad L2TP, GRE un IPsec nonāk vienā projektēšanas piezīmē: kuru sesiju es nesu un kurš slānis to aizsargā? Ja pirmais ir nepareizs, viss tālāk paliek iekšēji konsekvents, bet risina nepareizo problēmu – maršrutēts pārklājums, uzbūvēts tur, kur lietotājiem vajadzēja zvanīt iekšā, vai zvana koncentrators, kas stāv vietā, kur vajadzētu vietnes-uz-vietni vārteju. Zemāk esošā darba lapa piespiež šo atšķirību pirms kāds piesakās ierīcē. Aizpildiet to secībā, un katra rinda kļūs par kaut ko, ko varat pārbaudīt atsevišķi.

Sāciet ar sesiju, nevis ar protokolu sarakstu

Attālināts lietotājs ar PPP sesiju un maršrutēts pārklājums starp divām vārtejām ir dažādas tīkla attiecības, pat ja abas galu galā tiek ietītas IPsec. Pirmā izbeidz savienojumu katram lietotājam un prasa adrešu piešķiršanu, personas vai ierīces autentifikāciju un politiku, kas nosauc, kuros iekšējos tīklos šis lietotājs var nokļūt. Otrā pārsūta paketus starp vietnēm, kurās neviens nezvana iekšā.

Uzrakstiet vienu teikumu, kas nosauc, kuru no diviem jūs būvējat, un pēc tam izlasiet to vēlreiz tā, it kā jūs būtu cilvēks, kuram tas jāekspluatē. Ja teikumam vajag vārdu „un“, jūs būvējat abus, un darba lapai vajag divas kolonnas vienas kompromisa kolonnas vietā, kas katram pasniedz pusi. Ja tas nosauc lietotāju, bet ne adrešu kopu, vai prefiksu, bet ne pārsūtīšanas politiku, teikums joprojām ir nepilnīgs. Formulējums skan birokrātiski, bet šī ir lētākā vieta, kur noķert projektu, kas citādi tiks atklāts ar atbalsta dienesta biļeti.

Dodiet katram slānim tieši vienu uzdevumu

L2TPv2 nes PPP sesijas starp saviem diviem galapunktiem. PPP vada saites sarunas un, kad tās ir sarunātas, lietotāja autentifikāciju; L2TP nepievieno nekādu kriptogrāfiju, tāpēc kails L2TP dēmons neievieš nevienu IPsec drošības attiecības daļu un pieder tikai saitei, kurai jau uzticaties.

GRE ir iekapsulējums starp divām adresēm. Tas nes tīkla slāņa paketus pāri loģiskam pārklājumam un pats par sevi nepiedāvā ne konfidencialitāti, ne autentificētu partnera identitāti. Tas nav defekts: galvene tika veidota vienkārša, lai paliktu lēta apstrādē pārsūtīšanas aparatūrā. Sekas ir tādas, ka GRE atbild tikai uz jautājumu, kā pārvietot šo paketu starp divām adresēm, un ne uz ko citu, un tas ir tieši tas jautājums, kas tam jāuzdod.

Paliek IPsec kā slānis, kas atlasa satiksmi, autentificē partnerus un šifrē to, kam tam tika likts aizsargāt. Kādu satiksmi tas aizsargā, ir konfigurācijas lēmums, kam jāatbilst iekapsulējumam, ko galapunkti faktiski ģenerē, jo politika, kas rakstīta GRE ārējai adresei, uzvedas citādi nekā tā, kas rakstīta iekšējiem prefiksiem. GRE specifikācija skaidri atdala kravu, GRE galveni un ārējo piegādes protokolu, un jūsu politikai vajag tādu pašu atdalījumu.

Uzrakstiet paketa ceļu pirms konfigurācijas

Paņemiet vienu paketu un uzskaitiet katru pievienoto galveni tādā secībā, kādā tā tiek pievienota, nosaucot ierīci, kas to pievieno. Zvanošam lietotājam tas parasti ir PPP L2TP iekšpusē, bet šis – IPsec iekšpusē; vietnes pārklājumam tas ir iekšējais IP pakets GRE iekšpusē, bet šis – IPsec iekšpusē. Ja divas ierīces pievieno vienu un to pašu galveni, jums ir cilpa vai dublēts tunelis, un nekāda politikas rediģēšana to neizlabos.

Tas pats saraksts nosaka MTU, jo izmantojamais iekšējais izmērs ir izmērītais ceļa MTU mīnus tikko uzskaitītās galvenes un nekas cits. Nekopējiet skaitli no foruma ziņas: saskaitiet ārējā IP, UDP un ESP papildu apjomu, tad GRE vai L2TP, tad PPP kur tas attiecas, un atņemiet no ceļa MTU, ko faktiski izmērījāt. Simptomi, kas parādās tikai lielos pārsūtījumos, vai sesijas, kas izveidojas un pēc tam mirst pirmajā lielajā atbildē, parasti ved atpakaļ pie tā, ka šī saskaitīšana veikta minējumiem.

Pārbaudiet katru slāni atsevišķi, no ārpuses uz iekšu

Izpildiet pārbaudes secībā un apstājieties pie pirmās, kas neizdodas. Katra rinda atbild uz citu jautājumu, tāpēc kļūme norāda uz vienu darba lapas kolonnu, nevis pasaka, ka tunelis ir salūzis.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Cisco kastē ekvivalents ir atkarīgs no lomas, un precīzā sintakse ir atkarīga no platformas un izlaiduma: show crypto session IPsec partneriem, saskarnes skaitītāji GRE vai tuneļa saskarnei, un VPDN vai PPP pārbaude zvana lomai. Komandu kopums, kas izbeidz PPP, neko nepierāda par GRE atbalstu, un strādājoša GRE saskarne neko nepierāda par PPP pakalpojumu, tāpēc pārbaudiet lomu, ko faktiski konfigurējāt, nevis to, kas ir diagrammā.

Ierakstiet katru izvadi blakus darba lapas rindai, pie kuras tā pieder. Piezīmes, kas veiktas, kamēr kļūme ir aktīva, ir vērtīgākas par topoloģiju, kas vēlāk no jauna zīmēta no atmiņas.

Sakārtojiet demontāžas secību un pēc tam pārbaudiet vēlreiz

Demontāža notiek apgrieztā secībā iemesla dēļ: izņemiet aizsargāto satiksmi no IPsec politikas pirms noņemat iekapsulējumu, kam tā tika rakstīta, citādi politika turpina norādīt uz saskarni, kuras vairs nav, un nākamā konfigurācijas ielāde neizdodas vietā, kas izskatās nesaistīta. Linux tas nozīmē dzēst stāvokļa un politikas ierakstus pirms tuneļa saskarnes; maršrutētājā – noņemt kriptogrāfijas karti vai profila ierakstu pirms tuneļa.

Pēc pārbūves atkārtojiet četrus pieņemšanas novērojumus pa vienam: ārējā sasniedzamība, izveidota IPsec asociācija, izveidota PPP sesija tur, kur projekts to ietver, un iekšēja pārsūtīšana uz īstu galamērķa adresi. Viena zaļa gaisma nav pierādījums pārējām trim, un tieši šī plaisa ir kļūme, kas ražošanā izdzīvo visilgāk – tunelis, kas ir augšā, šifrēts un neko nepārsūta, jo iekšējais maršruts nekad netika pievienots.

Glabājiet aizpildīto darba lapu blakus ierīces konfigurācijai. Jebkura kolonna, ko nevarat aizpildīt, ir slānis bez piešķirta uzdevuma, un slānis bez uzdevuma parasti ir slānis, kam nevajadzētu būt kaudzē.