VPN saio-hasieraren alertak: zein gertaerek abiarazi behar dituzte benetan?
Autentifikazioaren arrakasta, ezarritako tunel bat eta RADIUS accounting Start hiru baieztapen desberdin dira. Aukeratu zure hartzaileak jardun dezakeen baieztapena, eta gero korrelaitu itzazu.
Autentifikazioaren arrakasta, ezarritako tunel bat eta RADIUS accounting Start hiru baieztapen desberdin dira, eta saio-hasierako mezu batek zerbait esan nahi du horietako bat aukeratzen duzunean soilik. VPN alerten diseinu gehienek hirurak nahasten dituzte eta inork fidatzen ez duen sarrera-ontzia sortzen dute. Erabakia alerta nork irakurtzen duen eta hurrengo bost minutuetan zer egin dezakeen araberakoa da. Hori gaizki eginez gero, alerta behar zenuen gertaera bakarra ezkutatzen duen zarat bihurtzen da.
Hiru galderak erabakitzen dute abiarazlea
Galdetu nork jasoko duen, zer egingo duen eta ekintzak zenbaterainoko bizkortasunez gertatu behar duen. Kredentzialen erabilera okerra zaintzen duen segurtasun-talde batek kontu batetik huts egin eta gero arrakasta izango duen eredua nahi du minutu gutxiren buruan. Edukiera zaintzen duen eragiketa-talde batek saioaren iraupena eta deskonexio-arrazoiak nahi ditu, ez saio-hasierak. Laguntza-mahai batek saioaren identitatea nahi du, txartel batekin parekatu ahal izateko.
Erantzun horiek gertaera desberdinetara bideratzen dute, eta arau bakar batek ere ez ditu hirurak betetzen. Hartzailearen ekintza «deitu erabiltzaileari» bada, autentifikazioa nahikoa da. Ekintza «askatu lizentzia bat» edo «egiaztatu tunelak trafikoa eraman duen» bada, ezarpenak edo accounting Start-ek soilik balioko du. Ekintza «fakturatu denbora» bada, Stop erregistroak behar dituzu, saio-hasiera bat ez.
Idatzi erantzuna esaldi bakarrean ezer konfiguratu aurretik. «Mezu honek guardiako ingeniariari esaten dio X kontuak Y saretik tunel bat ireki zuela Z orduan, mantentze-leihoa erabili den egiazta dezan.» Koadro bakoitza bete ezin baduzu, abiarazlea ez dago oraindik aukeratuta.
Egin bat gertaera egiten ari zaren baieztapenarekin
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
Taulak mendekotasun bat ezkutatzen du: errenkada bakoitza fidagarria da atebideak modu fidagarrian igortzen badu eta zure biltzaileak behar duzun eremua gordetzen badu. Irakurri gertaeraren definizioa exekutatzen duzun bertsio zehatzerako, «saioa ezarrita» izenak bertsioen artean aldatzen baita eta esanahiak izenak baino maizago aldatzen baita. Definizioa lausoa denean, eskatu saio-kaptura bat, ez asmatu etiketaren arabera.
Access-Accept bat ondorengo guztiaren amaiera gisa tratatzea da akats ohikoena. Kredentzialen gaineko epaia da, ez saio bat. Ispilu-akatsa politika-bat etortzea baimenaren froga gisa irakurtzea da, arau bat etor daitekeenean eta hurrengo urratsak huts egin dezakeenean.
Saio bat, jakinarazpen bat
Kontu bat, hainbat gailu, berbidalketak eta berrorkonexioak: gertaera bakoitzeko mezu batek bi norabideetan huts egingo du, saio bat bikoiztuz eta beste bat zatituz. Jarri jakinarazpenaren gakoa atebidea gehi saio-identifikatzailea, eta tratatu kontuaren izena atributu gisa, ez gako gisa. Gaineko ordenagailua eta telefonoa dituen erabiltzaile batek bi tunel eduki ditzake aldi berean, eta biek merezi dute beren lerroa.
Berbidalitako kontabilitate-erregistroak normalak dira, beraz, kendu bikoiztuak saio-idaren eta denbora-markaren arabera mezua errendatu aurretik. Gailu beraren ondorengo saioek bereizita jarraitu behar dute, eta mantentze-leiho batean zeharreko berrorkonexioak ikusgai egon behar du aurrekoan kolapsatu beharrean. Zure biltzaileak denbora-markak berridazten baditu sarreran, kendu bikoiztuak jatorrizko erregistroaren eremuen arabera, ez gordetakoen arabera.
Stop erregistro bat falta izatea ziurgabetasuna da, ez saio iraunkor bat. Atebidearen berrabiarazteek, biltzailearen matxurek eta UDP galerak hutsuneak uzten dituzte, beraz, alertak adiskidetze-bide bat behar du, saio bizien taula kontsultatzen duena inork tunela oraindik martxan dagoela ondorioztatu aurretik.
Eduki auditoretza eta jakinarazpena bereizita
Auditoretza-fluxuak eta alerta-fluxuak lan desberdinak dituzte. Gorde erregistro gordinak, kontua, atebidea, saio-identifikatzailea, denbora-markak eta amaitze-arrazoia barne, errutinazko mezuak biltzen, ezabatzen edo guardiako zerrenda txiki batera bidaltzen direnean ere. Larritasun-atalasea entregatze-iragazki bat da, ez iragarri nahi zenuen bizi-zikloaren gertaeraren hautaketa.
Bidali hartzaileak erregistro babestua aurkitzeko behar duen testuinguru minimoa. Kontuen izenak, barne-helbideak eta saioaren xehetasunak sentikorrak dira, eta ondo birbidaltzen den mezu bat ondo iragaten duen mezu bat da.
Gero frogatu mutur batetik bestera. Egin saio-hasiera eta amaiera normal bat, berrorkonexio bat, bi saio aldi berean eta behartutako entrega-matxura bat, eta jarraitu gertaera bat atebidetik biltzailearen bidez entregatutako mezura arte. Mezua saio-idarik gabe iristen bada, kontratua osatugabea da. Bi mezu saio bat deskribatzen badute, korrelazioa hautsita dago. Bi arazo horietako bat ere ez da agertzen probatzen duzun gauza bakarra posta-entregak funtzionatzen duela denean.