L2TP, GRE sau IPsec: ce strat ar trebui să transporte sesiunea?

Două întrebări se încurcă ori de câte ori L2TP, GRE și IPsec ajung în aceeași notă de proiectare: ce sesiune transport și ce strat o protejează? Dacă prima e greșită, tot ce urmează rămâne coerent intern în timp ce se rezolvă problema greșită — o suprapunere rutată construită acolo unde utilizatorii trebuiau să formeze apel, sau un concentrator de acces telefonic care ține locul unei porți sit-la-sit. Foaia de lucru de mai jos impune această distincție înainte ca cineva să se conecteze la un echipament. Completați-o în ordine și fiecare rând devine ceva ce puteți testa separat.

Începeți de la sesiune, nu de la lista de protocoale

Un utilizator la distanță cu o sesiune PPP și o suprapunere rutată între două porți sunt relații de rețea diferite, chiar dacă ambele ajung împachetate în IPsec. Prima termină o legătură per utilizator și cere alocare de adrese, autentificarea unei persoane sau a unui dispozitiv și o politică ce numește rețelele interne pe care acel utilizator le poate atinge. A doua transmite pachete între situri în care nimeni nu formează apel.

Scrieți o propoziție care numește pe care dintre cele două o construiți, apoi citiți-o ca și cum ați fi persoana care trebuie să o opereze. Dacă propoziția are nevoie de cuvântul „și”, construiți ambele, iar foaia are nevoie de două coloane în locul unei coloane de compromis care servește pe jumătate fiecare parte. Dacă numește un utilizator dar niciun pool de adrese, sau un prefix dar nicio politică de forwarding, propoziția este încă incompletă. Formularea sună birocratic, dar este locul cel mai ieftin de a prinde un proiect pe care altfel l-ar descoperi un tichet la suport.

Dați fiecărui strat exact o sarcină

L2TPv2 transportă sesiuni PPP între cele două capete ale sale. PPP rulează negocierea legăturii și, când aceasta este negociată, autentificarea utilizatorului; L2TP nu adaugă nicio criptografie, așa că un demon L2TP gol nu implementează nicio parte a relației de securitate IPsec și aparține doar în interiorul unei legături în care aveți deja încredere.

GRE este o încapsulare între două adrese. Transportă pachete de nivel rețea printr-o suprapunere logică și, singur, nu oferă nici confidențialitate, nici o identitate de peer autentificată. Nu este un defect: antetul a fost proiectat simplu ca să rămână ieftin de procesat pe hardware de forwarding. Consecința este că GRE răspunde la „cum mut acest pachet între două adrese” și la nimic altceva — exact întrebarea pe care ar trebui să i-o puneți.

Asta lasă IPsec ca stratul care selectează traficul, autentifică peerii și criptează ce i s-a spus să protejeze. Ce trafic protejează este o decizie de configurare care trebuie să corespundă încapsulării pe care capetele o generează efectiv, fiindcă o politică scrisă pentru adresa externă a GRE se comportă diferit de una scrisă pentru prefixele interne. Specificația GRE ține vizibil separate payloadul, antetul GRE și protocolul de livrare extern, iar politica voastră are nevoie de aceeași separare.

Scrieți calea pachetului înainte de configurare

Luați un pachet și enumerați fiecare antet adăugat, în ordinea în care este adăugat, numind dispozitivul care îl adaugă. Pentru un utilizator de acces telefonic este de obicei PPP în L2TP în IPsec; pentru o suprapunere de situri, pachetul IP intern în GRE în IPsec. Dacă două dispozitive adaugă același antet, aveți o buclă sau un tunel duplicat, iar nicio editare de politică nu repară asta.

Aceeași listă decide MTU-ul, fiindcă dimensiunea internă utilizabilă este MTU-ul de cale măsurat minus antetele pe care tocmai le-ați enumerat și nimic altceva. Nu copiați un număr dintr-o postare de forum: adunați overhead-ul IP extern, UDP și ESP, apoi GRE sau L2TP, apoi PPP unde se aplică, și scădeți din MTU-ul de cale pe care l-ați măsurat efectiv. Simptomele care apar doar la transferuri mari, sau sesiunile care se stabilesc și apoi mor la primul răspuns mare, duc de obicei înapoi la acea adunare făcută din ochi.

Verificați fiecare strat separat, dinspre exterior spre interior

Rulați verificările în ordine și opriți-vă la prima care eșuează. Fiecare rând răspunde la o întrebare diferită, așa că un eșec indică o coloană a foii în loc să spună că tunelul este stricat.

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?

Pe un echipament Cisco echivalentul depinde de rol, iar sintaxa exactă variază cu platforma și versiunea: show crypto session pentru peerii IPsec, contoare de interfață pentru interfața GRE sau tunel, și verificarea VPDN sau PPP pentru rolul de acces telefonic. Un set de comenzi care termină PPP nu dovedește nimic despre suportul GRE, iar o interfață GRE funcțională nu dovedește nimic despre serviciul PPP, așa că verificați rolul pe care l-ați configurat efectiv, nu pe cel din diagramă.

Notați fiecare ieșire lângă rândul foii căruia îi aparține. Notele luate cât timp defectul este activ valorează mai mult decât o topologie redesenată ulterior din memorie.

Ordonați demontarea, apoi verificați din nou

Demontarea se face în ordine inversă dintr-un motiv: scoateți traficul protejat din politica IPsec înainte de a elimina încapsularea pentru care a fost scrisă, altfel politica continuă să arate spre o interfață care nu mai există, iar următoarea încărcare de configurație eșuează într-un loc care pare fără legătură. Pe Linux asta înseamnă ștergerea intrărilor de stare și politică înaintea interfeței de tunel; pe un router, eliminarea intrării crypto map sau profile înaintea tunelului.

După reconstrucție, repetați cele patru observații de acceptare unul câte unul: accesibilitate externă, o asociere IPsec stabilită, o sesiune PPP stabilită acolo unde proiectul include una, și forwarding intern către o adresă de destinație reală. O lumină verde nu este dovadă pentru celelalte trei, iar acel gol este defecțiunea care supraviețuiește cel mai mult în producție — un tunel care este sus, criptat și nu transmite nimic pentru că ruta internă nu a fost adăugată niciodată.

Păstrați foaia completată lângă configurația echipamentului. Orice coloană pe care nu o puteți completa este un strat fără sarcină atribuită, iar un strat fără sarcină atribuită este de obicei un strat care nu ar trebui să fie în stivă.