AH edo ESP? Erabaki paketeak zer babestu behar duen jakinda
AH-k paketearen zati handiagoa egiaztatzen du eta ez du ezer enkriptatzen; ESP-k enkriptatu eta egiaztatu dezake. Babestu behar dituzun eremuen arabera aukeratu, eta gero adostu modua.
Bi IPsec proposamenek SHA-n oinarritutako osotasun-algoritmo bera adierazi dezakete eta, hala ere, babes-protokolo desberdinak eskatu. AH eta ESP ez dira autentifikazio-ezarpen baten bi idazkera. Irakurri lehenengo protokoloa, gero bere algoritmoak, gero bere modua, eta anbiguotasunaren zatirik handiena desagertzen da. AH-k paketea autentifikatzen du, bidean aldatu gabe geratzen diren IP goiburuaren eremuak barne, eta ESP-k enkapsulatzen duena autentifikatu eta enkriptatzen du, kanpoko goiburua bakean utzita. Aldea horrek hash-izen edozeinek baino hedapen gehiago erabakitzen ditu.
AH-k zer estaltzen duen eta ESP-k ez
AH-k osotasuna, datuen jatorriaren autentifikazioa eta berak definitutako errepikapenaren aurkako zerbitzua ematen ditu, eta ez du inolako isilpekotasunik. Bere estaldurak goi-mailako datuak eta bere arauek aldaezintzat jotzen dituzten IP goiburuaren eremuak hartzen ditu, ESP-k garraio moduan kanpoan uzten duen zatia hain zuzen. Baldintza batek IP goiburua bera autentifikatu behar dela dioenean, AH da horri erantzuten dion protokoloa.
Estaldura hori da, halaber, AH eremuan hauskorra izatearen arrazoia. TTL, goiburuaren egiaztapen-batuketa eta aukera batzuk eremu aldakorrak direnez ezin dira autentifikatu, bideratzaileek berridatz baititzakete, beraz protokoloak zerora eramaten ditu egiaztapena kalkulatu aurretik. Beraz, helbideak berridazten dituen edozein gauzak kalkulua hausten du, ez politika soilik.
NAT-k aukera murrizketa bihurtzen du
Helbide-itrzulpenak AH-k une honetan autentifikatu duen IP goiburuko jatorria edo helburua berridazten du, beraz osotasun-egiaztapenak huts egiten du urrutiko muturrean, eta protokolo-errore gisa huts egiten du, irakur daitekeen mezu gisa ez. ESP-k ez du kanpoko goiburua autentifikatzen, horregatik ESP-k NAT zeharkatzearekin funtzionatzen du eta NAT atzean AH-k ez. Bi muturrak bideratzaile arrunten atzean dituen tunela da hori lehenengo agertzen den tokia. Beraz, lehen galdera ez da zein protokolo den indartsuena, baizik eta muturren artean itzultzaile bat dagoen.
Badago, AH kanpoan geratzen da, eta elkarrizketa ESP-ra eta haren algoritmo-aukeretara pasatzen da. Hori murrizketa da, ez lehentasuna, eta horregatik erabakiaren hasieran dago, ez amaieran.
Moduak galdera biderkatzen du
ESP-k garraio moduan goi-mailako karga erabilgarria babesten du eta IP goiburua bakean uzten du; tunel moduan barneko pakete osoa enkapsulatzen du, barneko IP goiburua barne, eta hura babesten du. AH-k bi modu berak ditu, beraz AH edo ESP lau konbinazio dira algoritmoa aukeratu aurretik.
Modu konbinatuko ESP algoritmoek osotasuna bigarren protokolorik gabe erabakitzen dute. AES-GCM eta ChaCha20-Poly1305 eraikuntza bakarrean autentifikatzen eta enkriptatzen dute, beraz AH gainean gehitzeak ez du ezer erosten baina beste goiburu bat eta beste negoziazio bat kostatzen ditu. Arkitekturak AH eta ESP elkarrekin onartzen ditu, eta galdera praktikoa da zure atebideak eta bertsioak konbinazioa onartzen duten eta norbaitek gero mantendu ahal izango duen.
AH hutsarentzako ordezko zintzoa
Osotasun hutseko ESP aldaerak algoritmoa gordetzen du eta enkriptatze-aldarrikapena faltsutu beharrean uzten du, eta NAT zeharkatzen du. Diseinu zahar batek AH erabili bazuen isilpekotasunik gabeko autentifikazioa behar zuelako, aldaera hori da itzulpen zuzena, ez ohar erantsia duen tunel enkriptatua.
Proposamen batean ESP ikustea ere ez da enkriptatzearen froga. Irakurri enkriptatze-algoritmoa: NULL sarrera batek osotasun soila esan nahi du, eta modu konbinatuko sarrerak biak.
Erabaki hiru galderatan
Galdetu behar den isilpekotasuna, bidean itzultzaile bat dagoen eta zein goiburu-eremu autentifikatu behar diren. Hiru erantzun horiek protokolo bat eta modu bat seinalatzen dituzte, eta idazteak RFCak beranduago berriz irakurtzea baino denbora gutxiago hartzen du.
Gero egiaztatu onartu dena eta ez proposatu dena. ip xfrm state erakusten du instalatutako elkartearen protokoloa, modua eta algoritmoak, eta desadostasun batek ez du ezer instalatzen, hau da, nahi zenun babesa gabe igotzen den tunel bat baino hutsegite garbiagoa.
Eduki autentifikazio-hutsegiteak, hautatzaileen estaldura eta bideratze-erroreak aukera honetatik bereizita. Sintoma desberdinak sortzen dituzte, eta hautatzaile arazo batengatik protokoloa erruztatzea arrazoirik gabe hashak aldatzen egun bat emateko modu segurua da.