Kaj zabeležiti pri VPN med lokacijama: selektorji in obseg

Šest mesecev po vzpostavitvi tunela nova podomrežje ne ustreza več politiki, edini dokument v skupni mapi pa pravi le VPN pisarne. To je napaka, ki jo zapis o selektorjih preprečuje, in je konkretna: nabor naslovov se je spremenil, dokumentacija pa ne. Zapis pravilno napisati pomeni vedeti, kateri od več naborov naslovov opisujete, in zabeležiti tistega, ki ga druga stran dejansko uveljavlja, ne tistega, ki ste ga konfigurirali.

Konfigurirano ni dogovorjeno

V tunelu IPsec, ki temelji na politikah, vsaka stran predlaga selektorje prometa: obsege vira in cilja za podrejeno povezavo. Stran, ki odgovarja, sme ta predlog zožiti, zato lahko nameščena povezava pokriva manj, kot navaja konfiguracija. Zapis, ki kopira konfiguracijo, opisuje namero, ne trenutnega obsega zaščite. Oba se tiho razhajata in nič na strani stanja tunela na to ne opozori.

Ohranite oba stolpca z datumom, ko ste jih opazovali. Konfigurirani selektor je tisto, kar ste nameravali; dogovorjeni je tisto, kar jedro uveljavlja prav zdaj. Ko se razlikujeta, ta razlika pojasni presenetljivo napako veliko pogosteje kot napaka pri usmerjanju.

Ena povezava tudi ne predstavlja vsakega konfiguriranega para. Tunel z več kombinacijami selektorjev lahko dobi več podrejenih povezav, zapis, ki navaja eno od njih, pa je nepopoln seznam. Naštejte jih, namesto da jih povzemate.

Tuneli, ki temeljijo na poteh, izbirajo drugače

Pri vmesniku, ki temelji na poteh, odloča o tem, kaj vstopi v tunel, usmerjevalna tabela, selektorji pa so lahko namerno široki. To je legitimna zasnova in ne malomarnost, zato jo mora zapis tako opisati. Zapišite pot, vmesnik, na katerega kaže, in politiko požarnega zidu, ki omejuje dosegljive storitve. Obseg zaščite je namerno širok, zožitev pa opravi obseg storitev.

Kopiranje predloge, ki temelji na politikah, na tunel, ki temelji na poteh, ustvari dokument, ki opisuje mehanizem, ki ga uvedba ne uporablja. Naslednji inženir nato išče selektorje, ki jih tam nikoli ne bi smelo biti, in sklene, da je tunel napačno konfiguriran, čeprav je le slabo dokumentiran.

Prevod naslovov sodi v isto tabelo

Ko NAT drugi strani predstavi drug obseg, zapišite izvirne in prevedene predpone skupaj. Zabeležite fazo, v kateri se selektorji in pravila dostopa ujemajo z njimi, ker vrstni red odloča, ali bo oddaljena stran kdaj videla naslov, ki ste ga zapisali. Tabela le z enim od dveh obsegov je slabša od nobene tabele, saj je videti popolna.

To je podrobnost, ki po spremembi NAT pokvari delujoč tunel: selektor se še vedno ujema z izvirno predpono, druga stran zdaj prejme prevedeno, njena povratna pot pa kaže na naslov, ki ne obstaja več. Nič ne zabeleži napake v trenutku, ko se oba prenehata ujemati.

Zasebni DNS sodi na isto mesto. Ime, ki se razreši v naslov, neuporaben s te lokacije, je napaka v dokumentaciji s priloženo zahtevo za podporo, krivda pa bo padla na tunel.

Priložite zahtevo po storitvi

Zaščiten obseg ni seznam dovoljenj. Zapišite, katere storitve naj bodo dosegljive iz katerega vira in kdo je lastnik aplikacije za njimi. Ti dve polji odgovarjata na različni vprašanji, njuno mešanje pa povzroči, da se varnostni pregled na koncu prepira o usmerjanju namesto o dostopu.

Nato navedite skrbnika omrežja, ki vzdržuje pravilo. Seznam selektorjev brez lastnika tiho zastara, zastarelo pa je nemogoče ločiti od napačnega, ko tunel ob dveh zjutraj pade. Lastnik je tudi oseba, ki lahko potrdi, da je bila sprememba namerna.

Spremenite zapis v načrt testiranja

Za vsako potrebno pot izberite reprezentativnega gostitelja vira in cilja ter zabeležite pričakovano pot, storitev in prehod odgovora. To spremeni dokument v načrt testiranja, ne v opis. Preberite dejavno povezavo s spodnjim ukazom in jo primerjajte z dogovorjeno vrstico, ki ste jo zapisali.

swanctl --list-sas

Okvir s petimi vrsticami običajno zadostuje, da zapis ostane pošten. Različica spodaj se brez obrezovanja prilega zahtevi za spremembo:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Ping samo do prehoda ni sprejemni test. Nikoli ne preizkusi tranzitne poti, zato lahko uspe, medtem ko vsak posredovani tok ne uspe. Testirajte z gostitelja na eni strani do storitve na drugi in potrdite, da odgovor pride skozi tunel. Če uspe le ping, je zapis pravkar našel težavo s posredovanjem, ki naj bi jo preprečil. Dokumentacija strongSwan o posredovanju pojasnjuje, kako selektorji, poti in posredovanje delujejo skupaj na vozlišču Linux.