Transporta vai tuneļa režīms: izšķiriet pēc paketes, nevis pēc shēmas
Transports un tunelis apraksta, kas ir ESP iekšpusē, nevis to, vai iesaistīts ir resursdators vai vārteja. Trīs jautājumi nosaka, kāds režīms nepieciešams izvietojumam.
Mācību grāmatu shēmas transporta režīmu saista ar diviem resursdatoriem, bet tuneļa režīmu ar divām vārtejām, un šis īkšķa noteikums paliek spēkā līdz pirmajam izvietojumam, kas to lauž. Režīms apraksta, ko ESP pakete ietin, nevis kas ir puses. Vārteja var aizsargāt datplūsmu transporta režīmā, un resursdatoru pāris var izmantot tuneļa režīmu, ja tā izvēlas. Trīs jautājumi nosaka, kas nepieciešams konkrētam izvietojumam.
Režīms ir izkārtojums, nevis topoloģija
Transporta režīmā ESP galvene nāk pēc IP galvenes un pirms nākamās kārtas lietderīgās kravas, tāpēc sākotnējā IP galvene paliek ārpusē un ir redzama. Tuneļa režīmā aizsargātais saturs ir pilnīga IP pakete, un jauna ārējā galvene nosauc abus IPsec partnerus.
| Mode | What follows the outer IP header | Headers a capture shows |
|---|---|---|
| Transport | ESP, then the next-layer payload | One IP header |
| Tunnel | ESP, then a whole inner IP packet | Outer and inner headers |
Kad izvēlēta konfidencialitāte, aizsargātā zona tuneļa režīmā ietver šo iekšējo IP galveni, tāpēc ieraksts bez atslēgām nevar pateikt īstos galapunktus. Ārējā galvene abos gadījumos paliek lasāma, un tieši tas vispār padara iespējamu problēmu novēršanu.
Pirmais jautājums: kas tieši ir ESP iekšpusē
Apskatiet paketi, ko veido lietojumprogramma, un jautājiet, kura robeža to aizsargā. Ja atbilde ir transporta lietderīgā krava starp divām jau pareizām adresēm, transporta režīms der bez otrās galvenes izgudrošanas. Ja aizsargātajam saturam vajadzīgas savas adreses, jo īstie galapunkti atšķiras no partneriem, kas pārvadā datplūsmu, darbu veic tuneļa režīms. Abi gadījumi pastāv vienā organizācijā, tāpēc viens politikas paziņojums reti aptver visu.
Uz šo jautājumu var atbildēt pēc ieraksta un maršrutēšanas tabulas. Uz to nevar atbildēt pēc zīmējuma, kas lodziņus dēvē par klientu un serveri. Ieraksts, kas ņemts jebkurā pusē, dažu sekunžu laikā parāda, uz kuru no diviem jūs skatāties.
Otrais jautājums: vai iekšpusē jau ir tunelis
L2TP ir vēsturiskais pretpiemērs, kas to parāda. Pakalpojums pārvadā PPP L2TP sesijas iekšpusē, un IPsec aizsargā šo apmaiņu; izkārtojums nosaka transporta režīmu, bet tuneļa režīms ir atļauts kā opcija. Redzamais rezultāts ir tunelis pakalpojuma līmenī, kura ārējā aizsardzība izmanto transporta režīmu.
Tātad vārds tunelis produkta aprakstā neko nepasaka par apakšējā slāņa režīmu. Pierakstiet, kurš jautājums to noteica, jo nākamais recenzents jautās to pašu. Lasiet šīs kombinācijas specifikāciju, nevis spriediet pēc nosaukuma, jo šis ieradums novērš lielāko daļu strīdu par to, kas produktam jāatbalsta.
Trešais jautājums: ko prasa partneris
Diviem partneriem jāvienojas, un priekšlikums, kas piedāvā vienu režīmu, kamēr otrs pieprasa otro, izgāžas sarunu laikā, nevis klusi pasliktinās. Jautājiet tālā gala īpašniekam, kuru režīmu nosauc politika, un pārbaudiet priekšlikumu, nevis dokumentācijas kopsavilkumu.
Jauktas vides ir ierastas: viena vārteja pārtrauc transporta režīma sesijas vecam produktam un tuneļa režīma sesijas vietnes savienojumam. Režīms ir katrai asociācijai, nevis ierīcei. Pieprasiet asociāciju sarakstu, nevis funkcijas nosaukumu, jo nosaukums ceļo ātrāk par konfigurāciju.
Esošās asociācijas lasīšana
Pārskatam uzskaitiet partnerus, režīmu, selektorus un nākamās kārtas protokolu, pēc tam pievienojiet jebkuru iekapsulējumu, kas aptīts ap rezultātu. Adrešu tulkošana pievieno savu ārējo skatījumu un nav režīms; tulkotā plūsma joprojām var būt jebkurš no diviem. Saraksts ir vienīgais artefakts, kas parāda asociāciju tādu, kāda tā instalēta, nevis kāda tā iecerēta.
Pabeidziet ar maršrutēšanas un autorizācijas jautājumu, jo pareizs paketes izkārtojums neko nepasaka par to, kuras apakštīkli atļauti vai vai pastāv atbildes ceļš. Tie dzīvo politikā un maršrutēšanas tabulā, un neviens nemaina argumentu par režīmu.