Schemele din manuale asociază modul transport cu două gazde și modul tunel cu două gateway-uri, iar această regulă ține până la prima implementare care o încalcă. Modul descrie ce înfășoară pachetul ESP, nu cine sunt părțile. Un gateway poate proteja traficul în modul transport, iar o pereche de gazde poate folosi modul tunel dacă așa alege. Trei întrebări stabilesc de ce are nevoie o implementare anume.

Modul este o așezare, nu o topologie

În modul transport, antetul ESP vine după antetul IP și înaintea încărcăturii utile a stratului următor, astfel încât antetul IP original rămâne afară și vizibil. În modul tunel, conținutul protejat este un pachet IP complet, iar un antet exterior nou numește cele două părți IPsec.

ModeWhat follows the outer IP headerHeaders a capture shows
TransportESP, then the next-layer payloadOne IP header
TunnelESP, then a whole inner IP packetOuter and inner headers

Când se alege confidențialitatea, regiunea protejată din modul tunel include acel antet IP interior, motiv pentru care o captură nu poate spune punctele finale reale fără chei. Antetul exterior rămâne lizibil în ambele cazuri, și exact aceasta face posibilă depanarea.

Prima întrebare: ce se află exact în interiorul ESP

Priviți pachetul pe care îl produce aplicația și întrebați ce graniță îl protejează. Dacă răspunsul este încărcătura de transport între două adrese deja corecte, modul transport se potrivește fără a inventa un al doilea antet. Dacă conținutul protejat are nevoie de adrese proprii, pentru că punctele finale reale diferă de părțile care transportă traficul, modul tunel face treaba. Ambele cazuri există în aceeași organizație, motiv pentru care o singură declarație de politică acoperă rar totul.

La această întrebare se poate răspunde dintr-o captură și dintr-un tabel de rutare. Nu se poate răspunde dintr-un desen care etichetează casetele drept client și server. O captură făcută la oricare dintre părți arată în câteva secunde pe care dintre cele două îl priviți.

A doua întrebare: există deja un tunel înăuntru

L2TP este contraexemplul istoric care demonstrează ideea. Serviciul transportă PPP într-o sesiune L2TP, iar IPsec protejează acel schimb; așezarea specifică modul transport, modul tunel fiind permis ca opțiune. Rezultatul vizibil este un tunel la nivel de serviciu a cărui protecție exterioară folosește modul transport.

Așadar prezența cuvântului tunel într-o descriere de produs nu spune nimic despre modul stratului de dedesubt. Notați ce întrebare a decis, pentru că următorul recenzent va întreba același lucru. Citiți specificația acelei combinații în loc să raționați după nume, fiindcă acest obicei evită majoritatea disputelor despre ce trebuie să accepte un produs.

A treia întrebare: ce cere partea

Două părți trebuie să fie de acord, iar o propunere care oferă un mod în timp ce cealaltă cere al doilea eșuează în timpul negocierii, în loc să se degradeze în tăcere. Întrebați proprietarul capătului îndepărtat ce mod numește politica, și verificați propunerea, nu rezumatul documentației.

Mediile mixte sunt frecvente: un gateway încheie sesiuni de mod transport pentru un produs vechi și sesiuni de mod tunel pentru o legătură de sit. Modul este per asociere, nu per dispozitiv. Cereți lista asocierilor, nu numele funcției, pentru că numele călătorește mai repede decât configurația.

Citirea asocierii care există

Pentru o revizuire, enumerați părțile, modul, selectorii și protocolul stratului următor, apoi adăugați orice încapsulare înfășurată în jurul rezultatului. Traducerea adreselor adaugă propria vedere exterioară și nu este un mod; un flux tradus poate fi în continuare oricare dintre cele două. Lista este singurul artefact care arată asocierea așa cum este instalată, nu așa cum a fost intenționată.

Încheiați cu întrebarea despre rutare și autorizare, pentru că o așezare corectă a pachetului nu vă spune nimic despre ce subrețele sunt permise sau dacă există calea de răspuns. Acelea trăiesc în politică și în tabelul de rutare, și niciuna nu schimbă argumentul despre mod.

Articole similare