Hol figyeljük az OpenVPN-kliens forgalmát az átjárón

Szeretné tudni, mely célokat éri el egy csatlakozott kliens, ezért shellt nyit a VPN-kiszolgálón, és beírja: ss. Semmi hasznos nem jelenik meg, és az a következtetés, hogy az alagút elromlott, kicsit túl könnyen jön. Az útválasztó OpenVPN-átjáró továbbítja a kliens csomagjait; nem bontja meg a TCP-kapcsolataikat, és nem tart fenn socketet számukra. A bizonyíték máshol él, és hogy hol, az attól függ, hogyan kezelik a forgalmat, miután elhagyja az alagutat.

Döntse el, melyik elrendezést látja

Két gyakori forma teljesen eltérő bizonyítékot ad. Az útválasztó átjáró dekapszulál, továbbít és esetleg forrás-NAT-ot végez, így a kliens kapcsolata végponttól végpontig fennmarad helyi socket nélkül.

A proxy lezárja a forgalmat: elfogadja a kapcsolatot, majd megnyitja a saját felfelé irányuló kapcsolatát. Ebben az elrendezésben egy kéréshez két kapcsolat tartozik, és a köztük lévő kapcsolat csak a proxy saját nyilvántartásában létezik. Hogy melyiket telepítette, eldönti, a kernel folyamállapotát vagy az alkalmazásnaplókat kell-e olvasnia.

A zavar nagy része találgatásból ered. Erősítse meg a formát, mielőtt eszközt választ. Először olvassa el a kiszolgáló konfigurációjában a proxy-direktívát, mert a jelenléte minden későbbi lépést megváltoztat. Anélkül a csomagok útja útválasztás, és a kernel folyamállapota a bizonyítéka.

Először kösse a címet egy munkamenethez

Kezdje a kiszolgáló munkamenet-állapotával, és azonosítsa a kliens jelenlegi belső címét. A készlet címei újrahasznosulnak, ezért egy cím önmagában bérlet, nem személy.

Jegyezze fel együtt az időt és a hitelesített identitást, és figyelje meg, hogy egy egész LAN rejtőzik-e a kliens mögött. Ha a távoli vég alhálózatot útválaszt, a látott belső címek eredeti gazdagépek vagy lefordítottak lehetnek.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Ez a pár egyszerre két kérdésre válaszol: melyik előtagot szolgálja ki az alagút interfésze, és melyik munkamenet volt aktív az Önt érdeklő intervallumban. Tegye ezt még bármely folyambejegyzés értelmezése előtt, mert a rossz munkamenethez kapcsolt meggyőző tuple rosszabb, mint a semmilyen bizonyíték.

Olvassa a folyamtáblát egy útválasztó átjárón

Miután a cím és az intervallum megvan, a követett kapcsolatok csak olvasható listája megmutatja, mit továbbít az átjáró számára. Szűrjön az eredeti forrásra, hogy ne az egész táblát olvassa.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Minden bejegyzés két tuple-t tartalmaz, az eredetit és a választ, amelyek egy folyam két iránya, nem két alkalmazás. Forrás-NAT útvonalon az eredeti tuple megtartja az alagút címét, míg a válasz oldal a lefordított átjárócímet mutatja, és éppen ez teszi a kimenetet első pillantásra hibásnak.

Kezelje a listát élő állapotként, ne történetként. A rövid folyamok már lejárhattak, a nem követett forgalom soha nem jelenik meg, és egy másik hálózati névtér más táblát mutat. A conntrack-referencia dokumentálja a szűrőket és a kétirányú kimenetet.

Egy korlátozott felvétel az olvasás megerősítéséhez

Ha az alagút interfésze látható ott, ahová néz, egyetlen korlátozott felvétel eldönti, hogy az azonosított csomagok-e a vezetéken lévők. Tartsa szűken a szűrőt és kicsin a csomaglimitet.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Hasonlítsa össze az időbélyegeket, a protokollt és a portokat a folyambejegyzéssel és a tesztként küldött kéréssel. A NAT után készült felvétel csak az átjáró nyilvános címét mutatja, míg az alagút oldala még a kliensét mutathatja, és ez a különbség információ, nem ellentmondás.

Ha az interfész semmit nem lát, ellenőrizze az adatutat, mielőtt arra jutna, hogy a kliens tétlen: a kliens-kliens forgalom és egyes tehermentesítési utak soha nem haladnak át a megfigyelt ponton.

Proxy-naplók, és a látottak korlátai

Ha proxy áll az útvonalon, felfelé irányuló socketjei láthatók a socket-táblában, de nem képeződnek le egy-az-egyben a VPN-kliensekre, különösen csoportosítás vagy multiplexelés esetén. Használja a proxy beállított tranzakciónaplóját az ügyfélidentitás, a cél, az időbélyeg és a rögzített kérésazonosítók összekapcsolására.

Ellenőrizze a telepített verzió naplózási konfigurációját, ahelyett hogy feltételezné, minden kérés alapértelmezés szerint naplózódik.

Végül legyen pontos a hatókörben. A célcím és a port metaadat, nem URL és nem oldaltartalom, mert a belső HTTPS-munkamenet az alagúttól függetlenül megőrzi a saját védelmét. Jelentse, mit figyelt meg, melyik megfigyelési pontból és mikor.