Grupa politiko de NPS ne estas devigo de VPN-risurcoj

Du grupoj, du alirprofiloj, unu VPN-enirejo, kaj ambaŭ grupoj finfine atingas la samajn servilojn. La kutima kaŭzo ne estas rompita politiko, sed mankanta dua duono de la dezajno: NPS decidas, kiu rajtas starigi seancon, kaj io alia devas decidi, kion tiu seanco rajtas atingi. Kiam ekzistas nur la unua duono, la rajtigo sukcesas por ĉiu, kiu aŭtentikiĝas. La politiko faras sian taskon, kaj la dezajno ankoraŭ estas nekompleta.

Retpolitiko kongrua al grupo estas pruvo pri akcepto. Ĝi ne estas pruvo pri pakaĵoj, kaj la breĉo inter tiuj du asertoj estas kie okazas la plej granda parto de ĉi tiu laboro.

Trovu la politikon, kiu efektive akceptis la seancon

NPS pritaksas ordigitajn retpolitikojn, kaj gajnas la unua ebligita regulo, kies kondiĉoj kongruas. Kondiĉoj povas inkluzivi membrecon en grupo de uzanto aŭ komputilo, konektotipon, tempon kaj staton de la aparato. Tial larĝa politiko metita pli frue en la listo akceptas konekton antaŭ ol pli mallarĝa regulo pli malsupre eĉ estas konsiderata. La ordo ne estas detalo de la interfaco; la ordo estas la politiko.

Legu la liston laŭ ordo kaj identigu la kongruan, poste notu, kiujn agordojn ĝi redonis. La grupa nomo en la redaktilo ne estas la rezulto; la rezulto estas la rajtigo, kiun ricevis la servilo. Tenu uzantan rajtigon kaj aparatan rajtigon aparte tie, kie la efektivigo uzas ambaŭ, ĉar konto, kiu rajtas malfermi tunelon, ne aŭtomate estas konto, kiu devus atingi ĉiun internan servon.

La respondo de RADIUS estas instrukcio, ne filtrilo

Atributo Filter-Id portas la nomon de filtrila listo. Ĝi ne liveras porteblan aron da pakaĵfiltrilaj reguloj, kiujn komprenas ĉiu ricevanto, kaj sendi nomon, kiun la enirejo neniam difinis, devigas tute nenion. La sama singardemo validas por atributoj de VLAN: atribui tunelan seancon al VLAN mem ne estas enkursigita alirregulo por tiu uzanto.

Ĉi tie dezajno, kiu aspektas kompleta ĉe la flanko de NPS, silente faras nenion. Konfirmu per la dokumentaro de la enireja vendanto, kiuj rajtigaj atributoj estas subtenataj kaj kion la ricevanto faras kun ĉiu el ili, anstataŭ supozi, ke norma atributa nomo implicas norman konduton.

Metu la devigon tien, kie la trafiko pasas

Enirejo, kiu prilaboras la pakaĵojn de la uzanto, povas apliki filtrilon por ĉiu seanco, mapi grupon al enireja politiko, aŭ doni al la seanco adreson el apartigita provizo, kiun fajroŝirmilo traktas alie. Ĉiu el tiuj povas funkcii, kaj ili malsukcesas laŭ diversaj manieroj. Determinu, kiun mekanismon via enirejo subtenas, antaŭ ol skribi la politikon, kiu nomas ĝin. Poste skribu, kio okazas al seanco, kiam tiu mekanismo mankas, ĉar silento estas la defaŭlto.

Priskribu la celatan permeson en kvar partoj: identeco de fonto aŭ grupo, celo, protokolo kaj pordo. Aldonu la dependecojn, kiujn la uzanto vere bezonas, kiel DNS aŭ aŭtentikiga servo, alie la limigo rompos ensalutajn fluojn, kiujn neniu pensis testi. Skribu la regulon kontraŭ la interfaco, kiu efektive filtras, ne kontraŭ la interfaco, kiu hazarde estas malfermita en la redaktilo.

Konsideru ankaŭ tradukadon. Se malsupra fajroŝirmilo vidas unu tradukitan fontadreson por ĉiu tunela uzanto, ĝi ne povas distingi individuojn nur per tiu adreso, kaj regulo skribita kvazaŭ ĝi povus estos aŭ senutila aŭ tro larĝa.

Klientaj profiloj vivas ĉe la nefidinda flanko

Administrata VPN-profilo povas puŝi enkursigojn, regulojn de dividita tunelo aŭ aplikaĵfiltrilojn, kaj tiuj formigas, kiel kondutas bone edukita aparato. Ili ne estas protekto por la servo, ĉar la kliento estas la partio, kiun vi provas limigi. Forigi enkursigon en profilo ankaŭ ne estas rajtigo, ĉar kliento povas havi alian vojon al la sama celo.

Traktu klientajn agordojn kiel komforton kaj enirejajn agordojn kiel regadon. Kiam la du malkonsentas, la enirejo pravas, ĉar ĝi estas tiu, kiu vidas la pakaĵojn.

Akceptu per du kontoj, poste spuru laŭorde

Kreu du ordinarajn testkontojn kun malsamaj celataj permesoj, starigu freŝajn seancojn kaj kontrolu la efikan enirejan politikon por ĉiu. Poste testu unu sendanĝeran permesitan operacion kaj unu specife rifuzitan risurcon. Malsukcesa ping pruvas mem tre malmulte, ĉar ICMP povas esti filtrita dum la TCP-servo malantaŭ ĝi ĝoje respondas.

Kiam ambaŭ kontoj ankoraŭ ricevas larĝan aliron, spuru laŭ fiksa ordo: kiu politiko kongruis, kian rajtigon portis la respondo kaj kion la enirejo faris kun ĝi. Aldoni pli da NPS-atributoj antaŭ konfirmi, ke la ricevanto ilin efektivigas, estas la maniero, kiel malgranda rajtiga problemo fariĝas ŝanĝa fenestro sen rezulto.