Kiun adreson vi registras kiel la NPS RADIUS-kliento?

VPN-pordego, kiu transdonas aŭtentikigon al Windows NPS, bezonas unu objekton ĉe la NPS-flanko antaŭ ol iu ajn uzantpolitiko funkciu: RADIUS-klientan enskribon por la pordego. Plej multaj malsukcesaj provoj registras la malĝustan adreson, ĉar la grava adreso estas tiu, kiun la pordego uzas sur sia backend-vojo, ne la hostnomo, kiun la personaro tajpas en sian VPN-aplikaĵon. Se tiu valoro malĝustas, NPS silente forĵetas la peton, kio de la klienta flanko aspektas kiel malbona pasvorto. Tri kondiĉoj decidas, kiu adreso apartenas al la kampo, do klarigu ilin antaŭ ol malfermi la konzolon.

Registru la pordegon, ne la tekkomputilojn aŭ la klientaron

La RADIUS-klienta objekto reprezentas la retan aliraranĝaĵon, kiu sendas aŭtentikigajn petojn. Tio estas la VPN-pordego, ne ĉiu tekkomputilo rulanta la klienton, kaj ne la adresaro disdonata ene de tuneloj.

Tiuj tunelaj adresoj neniam aperas kiel fonto de RADIUS-peto, ĉar la peto vojaĝas laŭ la propra reta vojo de la pordego. Registri klientaran enskribon produktas politikon, kiu neniam povas kongrui, dum la vera peto alvenas de adreso, pri kiu NPS neniam aŭdis. La sama konfuzo kondukas homojn aldoni la hejman IP de ĉiu dungito, kio estas samtempe neprizorginda kaj malĝusta.

Tri kondiĉoj decidas la adreson, kiun vi entajpas

Unue, trovu la fontan adreson, kiun la pordego efektive uzas direkte al NPS. Pordego kun pluraj interfacoj ofte sendas el administra aŭ backend-interfaco anstataŭ el sia publika VPN-aŭskultanto. Due, kontrolu ĉu estas NAT inter ili: se la peto estas tradukata, NPS vidas la tradukitan adreson, kaj tio estas la valoro registrenda. Trie, se du pordegoj dividas la rolon, ĉiu peta fonto bezonas sian propran klientan enskribon, ĉar unu objekto kun unu adreso kovras nur unu el ili.

Rikordo kun du finoj tenas la paron rekta. La suba tabelo uzas privatajn adresojn kiel ilustraĵon, do anstataŭigu ilin per tiuj, kiujn via vojo efektive uzas.

Konfirmu la fonton anstataŭ diveni ĝin. Observu la protokolon de NPS aŭ fajroŝirmilo dum unu provo, aŭ kaptu sur la NPS-gastiganto per sudo tcpdump -ni any udp port 1812. La adreso en tiu kaptaĵo estas la sola defendebla respondo por la klienta enskribo. Se la pordego havas plurajn eblajn fontojn, registru ĉiun sub sia propra amika nomo.

La komuna sekreto estas valoro inter la pordego kaj NPS

La komuna sekreto aŭtentikigas la rilaton de la aparatoj. Ĝi ne estas uzanta pasvorto kaj neniam estas disdonata al la personaro aŭ enigita en klientajn profilojn.

Elektu unu valoron, entajpu ĝin en ambaŭ lokoj, kaj konservu ĝin tie, kie loĝas la sekurkopio de la pordega agordo. Miskongruo produktas peton, kiun NPS forĵetas sen utila eraro, kaj tio ne estas distingebla de neatingebla servilo en la pordega protokolo. Rotaciu ĝin dum bontenada fenestro kaj ĝisdatigu ambaŭ finojn en la sama ŝanĝo.

Konfirmu per unu permesita peto

Uzu kontrolitan konton kaj kunligu unu provon ĉe ambaŭ flankoj. Ĉe la pordego, konfirmu ke la peto foriris al la celita servilo; ĉe NPS, konfirmu ke ĝi alvenis de la registrita kliento kaj kongruis kun la atendita politiko de konekta peto. Tempolimo kaj malakcepto signifas malsamajn aferojn, kaj trakti ambaŭ kiel legitimilan problemon malŝparas la sekvan horon. Poste testu validan sed neelektindan konton kaj malĝustan pasvorton, ĉar politiko, kiu akceptas ĉion, trapasas ankaŭ la unuan teston.

Fine, kontrolu, kion la pordego faras kun la redonita rajtigo. Registri RADIUS-klienton nur permesas al la aparato partopreni; ĝi ne donas al ĉiu rezulta seanco aliron al la LAN.

Tenu diagnostikan eligon limigita: neniuj komunaj sekretoj, neniuj uzantaj pasvortoj, neniuj plenaj pakaĵaj utilŝarĝoj en subtena bileto. Se la dezajno postulas, ke la NPS-servilo legu adresarajn atributojn, tiu permeso estas aparta administra tasko disde la klienta registrado, kaj mankante ĝi malsukcesas alimaniere.