VPN oturum açma uyarıları: bunları asıl hangi olay tetiklemeli?
Kimlik doğrulama başarısı, kurulmuş bir tünel ve bir RADIUS accounting Start üç farklı iddiadır. Alıcınızın harekete geçebileceği iddiayı seçin ve ardından bunları ilişkilendirin.
Kimlik doğrulama başarısı, kurulmuş bir tünel ve bir RADIUS accounting Start üç farklı iddiadır ve bir giriş e-postası ancak bunlardan birini seçtiğinizde anlam kazanır. VPN uyarı tasarımlarının çoğu üçünü karıştırır ve kimsenin güvenmediği bir gelen kutusu üretir. Karar, uyarıyı kimin okuduğuna ve sonraki beş dakikada ne yapabileceğine bağlıdır. Bunu yanlış yaparsanız uyarı, ihtiyaç duyduğunuz tek olayı gizleyen gürültüye dönüşür.
Tetikleyiciyi üç soru belirler
Kimin alacağını, ne yapacağını ve eylemin ne kadar hızlı gerçekleşmesi gerektiğini sorun. Kimlik bilgilerinin kötüye kullanımını izleyen bir güvenlik ekibi, tek bir hesaptan dakikalar içinde başarısızlık ve ardından başarı örüntüsü ister. Kapasiteyi izleyen bir operasyon ekibi, oturum açmaları değil oturum süresini ve bağlantı kesilme nedenlerini ister. Bir yardım masası, bir bilete eşleştirebilmek için oturum kimliğini ister.
Bu yanıtlar farklı olaylara işaret eder ve tek bir kural üçünü de karşılamaz. Alıcının eylemi «kullanıcıyı ara» ise kimlik doğrulama yeterlidir. Eylem «bir lisansı serbest bırak» veya «tünelin trafik taşıdığını doğrula» ise yalnızca kurulum veya accounting Start işe yarar. Eylem «süreyi faturala» ise oturum açma yerine Stop kayıtlarına ihtiyacınız olur.
Bir şey yapılandırmadan önce yanıtı tek bir cümle olarak yazın. «Bu e-posta, nöbetçi mühendise X hesabının Z saatinde Y ağından bir tünel açtığını söyler; böylece bakım penceresinin kullanılıp kullanılmadığını kontrol edebilir.» Her alanı dolduramıyorsanız tetikleyici henüz seçilmemiştir.
Olayı, öne sürdüğünüz iddiayla eşleştirin
| 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 |
Tablo bir bağımlılığı gizler: her satır yalnızca ağ geçidi onu güvenilir biçimde yayımlıyorsa ve toplayıcınız ihtiyaç duyduğunuz alanı saklıyorsa güvenilirdir. Çalıştırdığınız tam sürüm için olay tanımını okuyun, çünkü «oturum kuruldu» adı sürümler arasında değişir ve anlam addan daha sık değişir. Tanım belirsizse etiketten tahmin etmek yerine bir oturum kaydı isteyin.
Bir Access-Accept'i sonrasındaki her şeyin tamamlanması olarak görmek en yaygın hatadır. Bu, kimlik bilgileri hakkında bir hükümdür, oturum değil. Ayna hatası, bir kural eşleşebilse ve sonraki adım yine de başarısız olabilecekken ilke eşleşmesini yetkilendirme kanıtı olarak okumaktır.
Bir oturum, bir bildirim
Bir hesap, birkaç cihaz, yeniden iletimler ve yeniden bağlanmalar: olay başına bir e-posta her iki yönde de yanlış olur, bir oturumu çoğaltırken diğerini böler. Bildirimin anahtarını ağ geçidi artı oturum tanımlayıcısı yapın ve hesap adını anahtar değil nitelik olarak ele alın. Dizüstü bilgisayarı ve telefonu olan bir kullanıcı aynı anda iki tünel tutabilir ve ikisi de kendi satırını hak eder.
Yeniden iletilen muhasebe kayıtları normaldir, bu nedenle mesajı oluşturmadan önce oturum kimliği ve zaman damgasına göre yinelenenleri kaldırın. Aynı cihazdan ardışık oturumlar ayrı kalmalı ve bir bakım penceresi sırasındaki yeniden bağlanma öncekine karışmak yerine görünür kalmalıdır. Toplayıcınız alım sırasında zaman damgalarını yeniden yazıyorsa, yinelenenleri saklanan alanlara göre değil özgün kaydın alanlarına göre kaldırın.
Eksik bir Stop kaydı belirsizliktir, kalıcı bir oturum değil. Ağ geçidi yeniden başlatmaları, toplayıcı kesintileri ve UDP kaybı boşluklar bırakır, bu nedenle uyarının, biri tünelin hâlâ açık olduğu sonucuna varmadan önce canlı oturum tablosunu sorgulayan bir mutabakat yoluna ihtiyacı vardır.
Denetimi ve bildirimi ayrı tutun
Denetim akışı ve uyarı akışı farklı işlere sahiptir. Ham kayıtları, hesap, ağ geçidi, oturum kimliği, zaman damgaları ve sonlandırma nedeni dahil olmak üzere saklayın; rutin e-postalar gruplandığında, bastırıldığında veya küçük bir nöbet listesine gönderildiğinde bile. Önem eşiği bir teslimat filtresidir, duyurmak istediğiniz yaşam döngüsü olayının seçimi değildir.
Alıcının korunan kaydı bulmak için ihtiyaç duyduğu asgari bağlamı gönderin. Hesap adları, iç adresler ve oturum ayrıntıları hassastır ve iyi yönlendirilen bir e-posta iyi sızan bir e-postadır.
Sonra bunu uçtan uca kanıtlayın. Normal bir giriş ve çıkış, bir yeniden bağlanma, iki eşzamanlı oturum ve zorunlu bir teslimat hatası çalıştırın ve bir olayı ağ geçidinden toplayıcı üzerinden teslim edilen mesaja kadar izleyin. E-posta oturum kimliği olmadan gelirse sözleşme eksiktir. İki e-posta bir oturumu anlatıyorsa ilişkilendirme bozuktur. Tek test ettiğiniz şey posta teslimatının çalışması olduğunda bu iki sorunun hiçbiri görünmez.