Mit árulnak el a helyi rendszernaplók egy VPN-kapcsolatról
Az operációs rendszer rögzíti a szolgáltatásindításokat, adapterváltozásokat és útvonalhibákat, amelyeket egy alkalmazás soha nem ír le. Olvasson el egy szűk időablakot, és korrelálja.
Minden asztali gép saját feljegyzést vezet arról, mit tett egy VPN, és az alkalmazás exportja általában ezek közül a legkevésbé teljes. A szolgáltatáskezelők feljegyzik, mikor indult el egy egység, a kernel feljegyzi, mikor jelent meg egy interfész, és a hálózati verem feljegyzi, mikor nem sikerült útvonalakat alkalmazni. Egyik ilyen eszköz sem tudja, mit szándékozott a kliens, és a kliens nem tudja, mit tett a kernel a kérésével.
Egy ilyen feljegyzés elszigetelt olvasása a rossz következtetés felé visz. Olvasson kettőt, ugyanabból a percből, és a sorrend láthatóvá válik.
Három eszköz, három szókincs
Linuxon a systemd naplója az egység életciklus-üzeneteit fogja el a wg-quick@wg0 vagy a NetworkManager VPN-bővítményétől, és a kernel gyűrűpuffere hordozza az interfész- és útvonal-üzeneteket. Windowson az eseménynapló a történetet rendszer-, WLAN- és távoli hozzáférés-szolgáltatókra osztja, mindegyiknek saját azonosítói vannak. macOS-en az egységes napló alrendszerre korlátozott üzeneteket hordoz, amelyeket a grafikus Console csak részben tár fel.
A szókincsek nem fordíthatók. Az egyik platform eseményazonosítója a másikon semmit nem jelent, és egy Windows-párbeszédablak képernyőképe semmit nem bizonyít egy Linux-egységről.
Amit mindhárman megosztanak, az az időbélyeg, a forrás és a súlyosság, és éppen ez a trió teszi lehetővé a kliensnapló és az operációs rendszer feljegyzése közötti korrelációt. Az elérhetőség is változik: egy napló nélküli konténer, egy csonkolt Windows-lemezkép vagy a build során csökkentett naplózási szint egy egész réteget elrejthet.
| Facility | What it records | What it cannot show |
|---|---|---|
| systemd journal | Unit start and stop, helper output, exit status | Whether packets actually reached the peer |
| Kernel and netlink | Interface creation, address assignment, route changes | Why the client asked for that configuration |
| Windows event log | Provider-specific connection and adapter events | Anything the provider chose not to log |
Mit bizonyít egy csatlakozott sor, és mit nem
A szolgáltatásindítási esemény rögzíti, hogy a helyi egységet indításra kérték, és hogy nem lépett ki azonnal. Nem rögzít befejezett kézfogást, érvényes partnerkulcsot vagy működő útvonalat. Ezt a sort az alagút bizonyítékának tekinteni e naplók leggyakoribb félreolvasása. A sor a szándékot és a folyamat állapotát bizonyítja, és semmit sem az elérhetőségről.
A továbbítási állapot külön megfigyelés, és az útvonaltáblából származik, nem valamelyik naplóból.
Egy adapteresemény megmagyarázhat egy csendes hibát: az interfész feljött, a cím hozzárendelődött, és az útvonalak soha nem települtek, mert egy házirend-szabály elutasította őket. Ebben a sorrendben minden látható sor egészségesnek tűnik, miközben semmi nem irányítódik, és ezt csak úgy láthatja meg, ha a napló időbélyegeit ugyanabban a pillanatban összeveti az útvonaltáblával. Tartsa a kliens saját eseménysorrendjét mindkettő mellett, mert a kliens az egyetlen forrás, amely tudja, mit kért. A két tény, amelyre együtt szüksége van, szinte soha nem ugyanabban a sorban jelenik meg.
Egy későbbi újracsatlakozás felülírja a kép érdekes részét, ezért az első hibánál rögzítse az ablakot, nem három próbálkozás után.
Korreláljon egy szűk ablakot
Jegyezze fel a kísérlet idejét az időzónájával, majd húzza elő a körülötte lévő néhány percet. Az ablak első hibája szinte mindig megelőzi azt a bontási sort, amelyet a támogatási jegyek idéznek.
journalctl -u wg-quick@wg0 --since "today 09:00" --until "today 09:20" ip route show table all | grep wg0 log show --last 20m --predicate 'subsystem == "com.apple.network"'
Minden parancs a kérdés más részére válaszol: az első az életciklust adja, a második a továbbítási állapotot, a harmadik a macOS hálózati alrendszerét. Windowson szűrje a rendszernaplót szolgáltatónév szerint, ahelyett hogy a teljes csatornát görgetné, és csak az egyező eseményeket exportálja.
Tartsa a kivonatot elég kicsinek ahhoz, hogy egy olvasó követni tudja. Egy húszperces ablak négy releváns eseménnyel alátámaszt egy következtetést; egy egész napra szóló, több ezer soros export semmit nem támaszt alá.
Hol érnek véget ezek a feljegyzések
A helyi feljegyzések az eszközt írják le, nem az útvonalat. Nem tudják megmutatni, mit tárolt egy szolgáltató, hogy egy munkamenetet hozzákapcsoltak-e egy fiókhoz, vagy hogy mit látott egy cél. Egy szolgáltató nyilatkozata arról, hogy nem vezet naplókat, semmit nem mond a laptopja operációs rendszeréről, és egy helyi esemény semmit nem bizonyít a szolgáltató történelmi feljegyzéseiről.
Több személyes adatot is hordoznak a vártnál: felhasználónevek, gazdagépnevek, csatolási útvonalak és eszközazonosítók jelennek meg közönséges rendszerüzenetekben akkor is, ha nincs böngészési tartalom. Távolítsa el ezeket, mielőtt bármit egy jegyhez csatolna, és az eredetit normál hozzáférés-ellenőrzés alatt tartsa.
Kezelt eszközön kérje el a megfelelő kivonatot az IT-tól ahelyett, hogy megpróbálná törölni a szervezeti naplózást. A diagnosztikai cél egyetlen szűk kérdés, amelyre két forrás válaszol, nem a gép teljes története.