RADIUS Wi-Fi-saluto kontraŭ HTTP-prokura aŭtentigo
Decidu, ĉu RADIUS-pruvoj celas retan aliron, prokuran rajtigon aŭ tempan korelacion de protokoloj.
Sukcesa Wi-Fi-saluto ne aŭtomate respondas la defion 407 de retprokurilo. RADIUS interparolas kun retalira servilo; HTTP-prokura aŭtentigo estas alia interparolo inter la kliento kaj la prokurilo.
Decidu, kiun el ĉi tiuj taskoj vi bezonas antaŭ ol kunligi la rikordojn:
| Celo | Bezonata pruvo aŭ integriĝo |
|---|---|
| Rajtigi Squid-peton laŭ nomita konto aŭ grupo | Identiga mekanismo disponebla por tiu peto, ekzemple subtenata integra prokura aŭtentigo |
| Raporti, kiu reta sesio rilatis al pasinta prokura trafiko | Tempmarkitaj sesiaj kaj adresatribuaj rikordoj korelaciitaj kun la prokura okazaĵo |
Por raportado konservu la RADIUS-sesian identigilon, la sesiajn horojn, la atribuitajn adresojn kaj la rilatan DHCP- aŭ atribuan historion. Squid-aliro-rikordo priskribas HTTP-okazaĵon; RADIUS-kontado priskribas retan sesion.
Supozu, ke unu tekkomputilo liberigas adreson kaj alia ricevas ĝin. Kunligi nur laŭ la adreso atribuas la trafikon de la dua aparato al la unua. NAT, dividitaj laborstacioj, tuneloj kaj samtempe validaj adresoj aldonas plian malklarecon.
Priskribu la korelacion kiel trafikon asociitan kun reta sesio laŭ deklaritaj mapreguloj. Ĝi povas esti utila sen esti aŭtentigita prokura identeco ligita al la transakcio. Eĉ samaj uzantnomoj en la du sistemoj ne provizas la mankan integriĝon je peta nivelo.