IPsec med dvema gostiteljema: kje se zaščita začne in kje konča
Par gostiteljev lahko ščiti izbrane tokove brez prehoda. Določite končne točke, pravilnik, ki izbira promet, in dovoljenja, ki ostanejo ločena.
Zaščita na paru gostiteljev se začne tam, kjer se varnostna asociacija konča, in to je dejstvo, ki ga intuicija, oblikovana s prehodi, najpogosteje spregleda. Aplikacijski strežnik in njegov strežnik podatkovne baze lahko svoj pogovor zaščitita neposredno, brez kakršnega koli koncentratorja za oddaljeni dostop na poti, in meja zaščite potem leži znotraj vsakega gostitelja in ne v požarnem zidu. Kar to prinese, je pokritost od konca do konca za izbrane tokove. Česar to ne prinese, je odločitev o tem, kdo sme brati katero vrstico.
Meja je tam, kjer se SA konča
RFC 4301 opisuje varnostne asociacije v transportnem načinu kot ureditev, ki se običajno uporablja med parom gostiteljev za zaščito od konca do konca. Ta dva gostitelja imata ključe in vsak odloči, kateri od njegovih lastnih paketov vstopijo v asociacijo. Tunel prehoda se konča povsem drugje in doseže gostitelja prek dodatnega notranjega segmenta, kar je druga meja zaupanja, tudi ko je paket šifriran večino svoje poti.
Gostitelj-na-gostitelja in transportni način pa nista sopomenki. Dva gostitelja lahko enako pravilno zgradita asociacijo v tunelskem načinu med seboj, zato najprej izberite način in nato opišite končne točke. Zapišite oboje v projektno opombo poleg naslovov partnerjev, ker bo recenzent, ki pozna samo način, predpostavil drugega.
SPD odloči o zaščiti, pot odloči o smeri
Usmerjevalna tabela odgovarja na to, kam gre paket. Podatkovna baza varnostnega pravilnika odgovarja na to, kako izbrani promet prečka mejo zaščite, in to počne za vsako smer z lastnimi izbirniki. Ta ločitev je razlog, da delujoča pot do podatkovne baze nič ne dokaže o tem, ali je bila zahteva zaščitena, in razlog, da vzpostavljena pogajanja nič ne dokažejo o tem, ali se je ta konkretna aplikacija z njimi ujemala. Primerjajte izbirnike, preden primerjate števce, ker števci opisujejo le tokove, ki so prišli tako daleč.
V Linuxu ip xfrm policy izpiše te vnose z njihovo smerjo, prioriteto, izbirnikom in dejanjem dovoli, blokiraj ali ujemi, medtem ko ip xfrm state prikaže nastale asociacije in njihove števce. Branje obojega skupaj je način, kako najdete tok, ki je tiho obšel tunel, ker se je širši vnos dovoljenja ujemal prvi.
Vrstni red prioritet je del pravilnika, ne podrobnost izvedbe. Ozak vnos, ki bi moral zaščititi vrata podatkovne baze, izgubi proti širšemu vnosu z višjo prioriteto, in okvara je videti, kot da pravilnik ni bil nikoli vprašan.
Transportni način pokriva naslednji sloj, ne glave IP
| Transport mode | Tunnel mode | |
|---|---|---|
| Original IP header | kept for routing the flow | replaced by an outer header |
| What ESP protects | the carried next-layer payload | the whole inner IP packet |
| Where it terminates | commonly the two hosts | gateway pair, or a host pair |
V transportnem načinu glava ESP sedi med glavo IP in koristno obremenitvijo, in naslovna polja te glave ostanejo vidna vsaki napravi na poti. To je v redu, ko naslovi niso skrivnost in obremenitev je. To je napačna izbira, če morate skriti tudi notranjo topologijo, ker samo tunelski način zavije izvirno glavo v novo.
Oba načina lahko prenašata več protokolov naslednjega sloja, in ESP bo zaščitil tisto, kar se ujema z izbirnikom, ne vsega, kar gostitelj pošlje.
Izbor je ožji od povezave
Ena asociacija lahko prenaša več tokov, a le tiste, ki jih izbere pravilnik. Zabeležite identitete partnerjev, izvorne in ciljne naslove, protokol in obseg storitve za razmerje, ki ga nameravate, nato pa ločeno odločite, ali sme neujemajoči promet iti odkrito, ali mora biti zaščiten, ali mora biti zavržen, ko asociacija ni na voljo. Prav ta zadnja odločitev prinaša presenečenja, ker lahko pravilo, ki zahteva zaščito za napačen vir, blokira vaš lastni upravljalni dostop enako učinkovito, kot blokira vsiljivca.
Med spreminjanjem izvajanja ohranite odobreno zunajpasovno pot in jo preizkusite, preden jo potrebujete, ne šele potem, ko oba gostitelja postaneta nedosegljiva.
Identiteta stroja ni dovoljenje aplikacije
IPsec preveri konfiguriranega partnerja in zaščiti izbrane pakete. Ne odloča, kateri zapis v podatkovni bazi sme oseba urejati, in ne spremeni zaupanja vredne identitete strežnika v podelitev vseh aplikacijskih pravic. Računi aplikacije, vloge in avtorizacija ostanejo točno tam, kjer so bili, in zahteva po TLS na ravni aplikacije ohrani svoj namen, tudi ko je omrežna pot že zaščitena.
Sprejmite zasnovo z eno operacijo z nameravanega vira in eno, ki mora biti zavrnjena, in vključite, kaj se zgodi, ko zahtevane asociacije ni mogoče vzpostaviti. Običajen preizkus dosegljivosti vam pove, da se paketi premikajo; ne pove vam, da so se premikali po pravilniku, ki ste ga napisali.