Šta treba zabilježiti za VPN između lokacija: selektori i obuhvat

Šest mjeseci nakon puštanja tunela u rad, nova podmreža prestaje da se poklapa sa politikom, a jedini dokument na dijeljenom disku kaže „VPN kancelarije“. Upravo takvu grešku sprečava zapis o selektorima, i ona je konkretna: skup adresa se promijenio, a dokumentacija nije. Ispravno napisati zapis znači znati koji od nekoliko skupova adresa opisujete, i zabilježiti onaj koji druga strana stvarno primjenjuje, a ne onaj koji ste konfigurisali.

Konfigurisano nije dogovoreno

U IPsec tunelu zasnovanom na politikama, svaka strana predlaže selektore saobraćaja: raspone izvora i odredišta za podređenu asocijaciju. Strana koja odgovara smije suziti taj predlog, tako da instalirana asocijacija može pokrivati manje nego što konfiguracija navodi. Zapis koji prepisuje konfiguraciju opisuje namjeru, a ne trenutni obuhvat zaštite. Njih dvoje se tiho razilaze, i ništa na stranici stanja tunela to ne pokazuje.

Držite obje kolone, sa datumom kada ste ih posmatrali. Konfigurisani selektor je ono što ste mislili; dogovoreni je ono što kernel primjenjuje upravo sada. Kada se razlikuju, ta razlika objašnjava neočekivani kvar mnogo češće nego greška u rutiranju.

Jedna asocijacija takođe ne predstavlja svaki konfigurisani par. Tunel sa nekoliko kombinacija selektora može završiti sa nekoliko podređenih asocijacija, a zapis koji navodi jednu od njih je djelimičan popis. Popišite ih umjesto da ih sažimate.

Tuneli zasnovani na rutama biraju drugačije

Sa interfejsom zasnovanim na rutama, tabela rutiranja odlučuje šta ulazi u tunel, a selektori mogu namjerno biti široki. To je legitiman projekat, a ne nemar, i zapis to tako mora opisati. Zapišite rutu, interfejs na koji pokazuje, i politiku zaštitnog zida koja ograničava koji su servisi dostupni. Obuhvat zaštite je namjerno širok, a sužavanje obavlja obuhvat servisa.

Prepisivanje šablona zasnovanog na politikama na tunel zasnovan na rutama daje dokument koji opisuje mehanizam koji primjena ne koristi. Sljedeći inženjer zatim traži selektore kojih nikada nije trebalo biti, i zaključi da je tunel pogrešno konfigurisan, iako je samo loše dokumentovan.

Prevođenje pripada istoj tabeli

Kada NAT predstavi drugoj strani drugačiji raspon, zapišite originalne i prevedene prefikse zajedno. Zabilježite fazu u kojoj se selektori i pravila pristupa poklapaju s njima, jer redoslijed odlučuje da li će udaljena strana uopšte vidjeti adresu koju ste zapisali. Tabela sa samo jednim od dva raspona gora je od nikakve tabele, jer izgleda potpuna.

Ovo je detalj koji lomi tunel koji radi nakon promjene NAT-a: selektor se još poklapa sa originalnim prefiksom, druga strana sada prima prevedeni, a njena povratna ruta pokazuje na adresu koja više ne postoji. Ništa ne bilježi grešku u trenutku kada prestanu da se slažu.

Privatni DNS spada na isto mjesto. Ime koje se razrješava u adresu neupotrebljivu sa relevantne lokacije je greška u dokumentaciji sa priloženim tiketom podrške, i bit će okrivljen tunel.

Priložite zahtjev za servis

Zaštićeni raspon nije spisak dozvola. Zapišite koji servisi treba da budu dostupni iz kojeg izvora, i ko je vlasnik aplikacije iza njih. Ta dva polja odgovaraju na različita pitanja, a njihovo miješanje je način na koji sigurnosna provjera završi raspravom o rutiranju umjesto o pristupu.

Zatim imenujte mrežnog administratora koji održava pravilo. Popis selektora bez vlasnika tiho zastarijeva, a zastarjelo se ne razlikuje od pogrešnog kada tunel pukne u dva ujutro. Vlasnik je i osoba koja može potvrditi da je promjena bila namjerna.

Pretvorite zapis u plan testiranja

Za svaku potrebnu putanju izaberite reprezentativni host-izvor i host-odredište i zabilježite očekivanu rutu, servis i gejtvej odgovora. To pretvara dokument u plan testiranja, a ne u opis. Pročitajte aktivnu asocijaciju komandom ispod i uporedite je sa dogovorenim redom koji ste zapisali.

swanctl --list-sas

Skelet od pet redova obično je dovoljan da zapis ostane pošten. Verzija ispod staje u tiket za promjenu bez skraćivanja:

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 gejtveja nije prihvatni test. On nikada ne prolazi kroz tranzitnu putanju, pa može proći dok svaki proslijeđeni tok ne uspijeva. Testirajte sa hosta na jednoj strani do servisa na drugoj i potvrdite da odgovor stiže kroz tunel. Ako prođe samo ping, zapis je upravo pronašao problem sa prosljeđivanjem koji je trebalo da spriječi. strongSwan dokumentacija o prosljeđivanju objašnjava kako selektori, rute i prosljeđivanje djeluju zajedno na Linux čvoru.