Ang patakaran ng pangkat ng NPS ay hindi pagpapatupad ng mga mapagkukunang VPN
Ang pagpayag sa isang pangkat na kumonekta ay hindi paglilimita sa naaabot nito. I-verify ang tumutugmang patakaran, ang ibinalik na awtorisasyon at ang sariling pagpapatupad ng gateway.
Dalawang pangkat, dalawang profile ng pag-access, isang gateway ng VPN, at sa huli ay naaabot ng dalawang pangkat ang parehong mga server. Ang karaniwang dahilan ay hindi sirang patakaran kundi nawawalang ikalawang kalahati ng disenyo: pinagpapasyahan ng NPS kung sino ang makakapagtatag ng sesyon, at ibang bagay ang dapat magpasiya kung ano ang maaabot ng sesyong iyon. Kapag ang unang kalahati lang ang umiiral, nagtatagumpay ang awtorisasyon para sa lahat ng nagpapatunay. Ginagawa ng patakaran ang trabaho nito, at ang disenyo ay hindi pa kumpleto.
Ang patakaran ng network na tumutugma sa isang pangkat ay ebidensiya tungkol sa pagtanggap. Hindi ito ebidensiya tungkol sa mga pakete, at ang agwat ng dalawang pahayag na iyon ang lugar kung saan nangyayari ang malaking bahagi ng gawaing ito.
Hanapin ang patakarang talagang tumanggap sa sesyon
Sinusuri ng NPS ang mga patakaran ng network na nakaayos, at nananalo ang unang naka-enable na tuntunin na tumutugma ang mga kundisyon. Maaaring kabilang sa mga kundisyon ang pagiging kasapi sa pangkat ng user o computer, uri ng koneksyon, oras at kalagayan ng device. Kaya ang malawak na patakarang inilagay nang mas maaga sa listahan ay tumatanggap ng koneksyon bago pa man isaalang-alang ang mas makitid na tuntunin sa ibaba. Ang pagkakasunod-sunod ay hindi detalye ng interface; ang pagkakasunod-sunod ay ang patakaran.
Basahin ang listahan ayon sa pagkakasunod-sunod at tukuyin ang tumugma, pagkatapos itala kung anong mga setting ang ibinalik nito. Ang pangalan ng pangkat sa editor ay hindi ang resulta; ang resulta ay ang awtorisasyong natanggap ng server. Panatilihing hiwalay ang awtorisasyon ng user at awtorisasyon ng device kung saan ginagamit ng deployment ang dalawa, dahil ang account na maaaring magbukas ng tunnel ay hindi awtomatikong account na dapat umabot sa bawat panloob na serbisyo.
Ang sagot ng RADIUS ay tagubilin, hindi filter
Ang attribute na Filter-Id ay may dalang pangalan ng listahan ng filter. Hindi ito nagpapadala ng naikakargang hanay ng mga tuntunin sa pag-filter ng pakete na nauunawaan ng bawat tatanggap, at ang pagpapadala ng pangalan na hindi kailanman tinukoy ng gateway ay walang pinapatupad na anuman. Ang parehong pag-iingat ay nalalapat sa mga attribute ng VLAN: ang pagtatalaga ng sesyon ng tunnel sa isang VLAN ay hindi, sa sarili nito, isang naka-rutang tuntunin ng pag-access para sa user na iyon.
Dito ang isang disenyong mukhang kumpleto sa panig ng NPS ay tahimik na walang ginagawa. Kumpirmahin sa dokumentasyon ng vendor ng gateway kung aling mga attribute ng awtorisasyon ang sinusuportahan at ano ang ginagawa ng tatanggap sa bawat isa, sa halip na ipagpalagay na ang karaniwang pangalan ng attribute ay nangangahulugan ng karaniwang pag-uugali.
Ilagay ang pagpapatupad kung saan dumadaan ang trapiko
Ang gateway na nagpoproseso ng mga pakete ng user ay maaaring maglapat ng filter bawat sesyon, magmapa ng pangkat sa patakaran ng gateway, o magbigay sa sesyon ng address mula sa hiwalay na pool na iba ang trato ng firewall. Alinman sa mga ito ay maaaring gumana, at nabibigo sila sa iba't ibang paraan. Tukuyin kung aling mekanismo ang sinusuportahan ng iyong gateway bago isulat ang patakarang nagpapangalan dito. Pagkatapos itala kung ano ang nangyayari sa sesyon kapag wala ang mekanismong iyon, dahil ang katahimikan ang default.
Ilarawan ang nilalayong pahintulot sa apat na bahagi: pagkakakilanlan ng pinagmulan o pangkat, destinasyon, protocol at port. Idagdag ang mga dependency na talagang kailangan ng user, tulad ng DNS o serbisyo ng pagpapatunay, kung hindi ay sisirain ng paghihigpit ang mga daloy ng pag-login na walang naisip na subukan. Isulat ang tuntunin laban sa interface na talagang nag-filter, hindi laban sa interface na nagkataong bukas sa editor.
Isaalang-alang din ang pagsasalin ng address. Kung ang firewall sa ibaba ay nakakakita ng isang naisaling address ng pinagmulan para sa bawat user ng tunnel, hindi nito makikilala ang mga indibidwal mula sa address na iyon lamang, at ang tuntuning isinulat na parang kaya ito ay magiging walang silbi o masyadong malawak.
Ang mga profile ng kliyente ay naninirahan sa hindi mapagkakatiwalaang panig
Ang pinamamahalaang profile ng VPN ay maaaring magtulak ng mga ruta, tuntunin ng split tunnel o mga filter ng aplikasyon, at hinuhubog ng mga ito kung paano kumikilos ang isang maayos na device. Hindi ito proteksyon para sa serbisyo, dahil ang kliyente ang partidong sinusubukan mong limitahan. Ang pag-alis ng ruta sa isang profile ay hindi rin awtorisasyon, dahil maaaring may ibang landas ang kliyente patungo sa parehong destinasyon.
Tratuhin ang mga setting ng kliyente bilang kaginhawahan at ang mga setting ng gateway bilang kontrol. Kapag hindi sila magkasundo, tama ang gateway, dahil ito ang nakakakita ng mga pakete.
Tanggapin gamit ang dalawang account, pagkatapos subaybayan sa pagkakasunod-sunod
Gumawa ng dalawang ordinaryong test account na may magkaibang nilalayong pahintulot, magtatag ng mga bagong sesyon at suriin ang epektibong patakaran ng gateway para sa bawat isa. Pagkatapos subukan ang isang hindi nakakapinsalang pinapayagang operasyon at isang partikular na tinanggihang mapagkukunan. Ang nabigong ping ay kakaunti ang pinapatunayan sa sarili nito, dahil maaaring na-filter ang ICMP habang masayang tumutugon ang serbisyong TCP sa likod nito.
Kapag nakakakuha pa rin ng malawak na access ang dalawang account, subaybayan sa takdang pagkakasunod-sunod: aling patakaran ang tumugma, anong awtorisasyon ang dala ng sagot at ano ang ginawa ng gateway dito. Ang pagdaragdag ng mas maraming attribute ng NPS bago kumpirmahin na ipinapatupad ng tatanggap ang mga ito ay ang paraan kung paano nagiging window ng pagbabago na walang resulta ang isang maliit na problema sa awtorisasyon.