L2TP, GRE ar IPsec: kuris sluoksnis turi nešti sesiją?

Du klausimai susipainioja kiekvieną kartą, kai L2TP, GRE ir IPsec atsiduria tame pačiame projektavimo užraše: kurią sesiją aš nešu ir kuris sluoksnis ją apsaugo? Jei pirmasis neteisingas, visa, kas toliau, išlieka viduje nuoseklu, bet sprendžia ne tą problemą – maršrutizuotas perdangas, pastatytas ten, kur vartotojams reikėjo skambinti, arba skambučių koncentratorius, stovintis vietoje svetainės-svetainės tinklų sietuvos. Žemiau pateiktas darbalapis priverčia šį skirtumą padaryti prieš kam nors prisijungiant prie įrenginio. Užpildykite jį iš eilės ir kiekviena eilutė taps tuo, ką galite patikrinti atskirai.

Pradėkite nuo sesijos, o ne nuo protokolų sąrašo

Nuotolinis vartotojas, laikantis PPP sesiją, ir maršrutizuotas perdangas tarp dviejų tinklų sietuvių yra skirtingi tinklo santykiai, net kai abu galiausiai apvyniojami IPsec. Pirmasis užbaigia kiekvieno vartotojo ryšį ir reikalauja adresų paskirstymo, asmens ar įrenginio autentifikavimo ir politikos, nurodančios, kuriuos vidinius tinklus tas vartotojas gali pasiekti. Antrasis persiunčia paketus tarp svetainių, į kurias niekas neskambina.

Parašykite vieną sakinį, kuris įvardija, kurią iš dviejų statote, o tada perskaitykite jį taip, lyg būtumėte žmogus, kuris turės jį eksploatuoti. Jei sakiniui reikia žodžio „ir“, statote abu, o darbalapiui reikia dviejų stulpelių vietoj vieno kompromisinio stulpelio, kuris kiekvienam tarnauja per pusę. Jei jis įvardija vartotoją, bet ne adresų telkinį, arba priešdėlį, bet ne persiuntimo politiką, sakinys vis dar nepilnas. Formuluotė skamba biurokratiškai, bet tai pigiausia vieta pagauti projektą, kuris kitu atveju bus atskleistas pagalbos tarnybos bilietu.

Kiekvienam sluoksniui duokite lygiai vieną užduotį

L2TPv2 neša PPP sesijas tarp savo dviejų galinių taškų. PPP vykdo ryšio derybas ir, kai jos suderėtos, vartotojo autentifikavimą; L2TP neprideda jokios kriptografijos, todėl plikas L2TP tarnyba neįgyvendina nė vienos IPsec saugumo santykio dalies ir priklauso tik į ryšį, kuriuo jau pasitikite.

GRE yra inkapsuliavimas tarp dviejų adresų. Jis neša tinklo lygio paketus per loginę perdangą ir pats savaime nesiūlo nei konfidencialumo, nei autentifikuoto partnerio tapatybės. Tai ne defektas: antraštė suprojektuota paprasta, kad išliktų pigi apdoroti persiuntimo aparatinėje įrangoje. Pasekmė ta, kad GRE atsako tik į klausimą, kaip perkelti šį paketą tarp dviejų adresų, ir į nieką daugiau, o tai būtent tas klausimas, kurį jam verta užduoti.

Lieka IPsec kaip sluoksnis, kuris parenka srautą, autentifikuoja partnerius ir užšifruoja tai, ką jam buvo liepta apsaugoti. Kokį srautą jis apsaugo, yra konfigūracijos sprendimas, kuris turi atitikti inkapsuliavimą, kurį galiniai taškai iš tikrųjų sukuria, nes politika, parašyta GRE išoriniam adresui, elgiasi kitaip nei parašytoji vidiniams priešdėliams. GRE specifikacija aiškiai atskiria naudingąją apkrovą, GRE antraštę ir išorinį pristatymo protokolą, o jūsų politikai reikia tokio pat atskyrimo.

Parašykite paketo kelią prieš konfigūraciją

Paimkite vieną paketą ir išvardykite kiekvieną pridedamą antraštę ta tvarka, kuria ji pridedama, nurodydami įrenginį, kuris ją prideda. Skambinančiam vartotojui tai paprastai PPP L2TP viduje, o šis – IPsec viduje; svetainės perdangai tai vidinis IP paketas GRE viduje, o šis – IPsec viduje. Jei du įrenginiai prideda tą pačią antraštę, turite kilpą arba dubliuotą tunelį, ir joks politikos redagavimas to nesutaisys.

Tas pats sąrašas nustato MTU, nes naudojamas vidinis dydis yra išmatuotas kelio MTU atėmus ką tik išvardytas antraštes ir nieko daugiau. Nekopijuokite skaičiaus iš forumo įrašo: sudėkite išorinio IP, UDP ir ESP sąnaudas, tada GRE arba L2TP, tada PPP kur taikoma, ir atimkite iš kelio MTU, kurį iš tikrųjų išmatavote. Simptomai, pasireiškiantys tik didelių perdavimų metu, arba sesijos, kurios susikuria ir paskui miršta per pirmą didelį atsakymą, dažniausiai kyla iš to, kad tas sudėjimas buvo atliktas spėjant.

Patikrinkite kiekvieną sluoksnį atskirai, iš išorės į vidų

Vykdykite patikras iš eilės ir sustokite ties pirmąja, kuri nepavyksta. Kiekviena eilutė atsako į kitą klausimą, todėl gedimas nurodo vieną darbalapio stulpelį, o ne pasako, kad tunelis sugedęs.

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 dėžėje atitikmuo priklauso nuo vaidmens, o tiksli sintaksė priklauso nuo platformos ir leidimo: show crypto session IPsec partneriams, sąsajos skaitikliai GRE arba tunelio sąsajai, ir VPDN arba PPP patikra skambučio vaidmeniui. Komandų rinkinys, kuris užbaigia PPP, nieko neįrodo apie GRE palaikymą, o veikianti GRE sąsaja nieko neįrodo apie PPP paslaugą, todėl tikrinkite vaidmenį, kurį iš tikrųjų sukonfigūravote, o ne tą, kuris yra schemoje.

Įrašykite kiekvieną išvestį šalia darbalapio eilutės, kuriai ji priklauso. Pastabos, padarytos gedimui esant aktyviam, vertingesnės už topologiją, vėliau perpieštą iš atminties.

Susitvarkykite išardymo tvarką, tada patikrinkite iš naujo

Išardymas vyksta atvirkštine tvarka dėl priežasties: išimkite apsaugotą srautą iš IPsec politikos prieš pašalindami inkapsuliavimą, kuriam ji buvo parašyta, kitaip politika toliau rodo į sąsają, kurios nebėra, ir kitas konfigūracijos įkėlimas nepavyksta ten, kas atrodo nesusiję. Linux atveju tai reiškia ištrinti būsenos ir politikos įrašus prieš tunelio sąsają; maršrutizatoriuje – pašalinti kriptografijos žemėlapį ar profilio įrašą prieš tunelį.

Po perstatymo pakartokite keturis priėmimo stebėjimus po vieną: išorinis pasiekiamumas, nustatytas IPsec susiejimas, nustatyta PPP sesija ten, kur projektas ją numato, ir vidinis persiuntimas į tikrą paskirties adresą. Viena žalia lemputė nėra įrodymas kitiems trims, ir būtent ši spraga yra gedimas, kuris gamyboje išlieka ilgiausiai – tunelis, kuris veikia, užšifruotas ir nieko nepersiunčia, nes vidinis maršrutas niekada nebuvo pridėtas.

Laikykite užpildytą darbalapį šalia įrenginio konfigūracijos. Bet kuris stulpelis, kurio negalite užpildyti, yra sluoksnis be paskirtos užduoties, o sluoksnis be užduoties paprastai yra sluoksnis, kurio neturėtų būti kaminoje.