Saan susubaybayan ang trapiko ng isang OpenVPN client sa gateway

Gusto mong malaman kung aling mga destinasyon ang naaabot ng konektadong client, kaya magbubukas ka ng shell sa VPN server at ita-type ang ss. Walang kapaki-pakinabang na lumilitaw, at ang konklusyon na sira ang tunnel ay dumarating nang medyo masyadong madali. Ang naka-ruta na OpenVPN gateway ay nagpapasa ng mga packet ng client; hindi nito tinatapos ang kanilang mga koneksyon sa TCP at wala itong mga socket para sa kanila. Ang ebidensya ay naninirahan sa ibang lugar, at kung saan ay depende sa kung paano hinahawakan ang trapiko kapag lumabas ito sa tunnel.

Magpasya kung aling kaayusan ang tinitingnan mo

Dalawang karaniwang anyo ang nagbibigay ng lubos na magkaibang ebidensya. Ang routing gateway ay nagde-decapsulate, nagpapasa at maaaring gumawa ng source-NAT, kaya ang koneksyon ng client ay patuloy na umiiral mula dulo hanggang dulo nang walang lokal na socket.

Ang proxy ay nagtatapos ng trapiko: tinatanggap nito ang koneksyon, pagkatapos ay binubuksan ang sarili nitong pataas na koneksyon. Sa kaayusang iyon may dalawang koneksyon para sa isang kahilingan, at ang kaugnayan sa pagitan ng mga ito ay umiiral lamang sa sariling mga talaan ng proxy. Ang pag-alam kung alin sa dalawang ito ang inilagay mo ay nagpapasya kung dapat mong basahin ang estado ng daloy ng kernel o ang mga log ng aplikasyon.

Karamihan ng pagkalito ay nagmumula sa paghula. Kumpirmahin ang anyo bago pumili ng kasangkapan. Basahin muna ang konfigurasyon ng server para sa direktiba ng proxy, dahil binabago ng presensya nito ang bawat susunod na hakbang. Kung wala ito, ang landas ng packet ay routing at ang estado ng daloy ng kernel ang iyong ebidensya.

Ikabit muna ang address sa isang session

Magsimula sa estado ng mga session ng server at tukuyin ang kasalukuyang panloob na address ng client. Ang mga address sa pool ay nire-recycle, kaya ang address lamang ay isang pag-upa, hindi isang tao.

Itala ang oras at ang na-authenticate na pagkakakilanlan nang magkasama, at pansinin kung may buong LAN na nagtatago sa likod ng client na iyon. Kung ang malayong dulo ay nag-ruruta ng subnet, ang mga panloob na address na nakikita mo ay maaaring orihinal na host o isinalin.

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

Ang pares na iyon ay sumasagot sa dalawang tanong nang sabay: aling prefix ang pinagsisilbihan ng interface ng tunnel, at aling session ang aktibo sa pagitan na mahalaga sa iyo. Gawin ito bago bigyang-kahulugan ang anumang entry ng daloy, dahil ang isang nakakumbinsing tuple na nakakabit sa maling session ay mas masahol kaysa sa walang ebidensya.

Basahin ang talahanayan ng daloy sa routing gateway

Kapag naitatag na ang address at pagitan, ang listahang basahin-lamang ng mga sinusubaybayang koneksyon ay nagpapakita kung ano ang ipinapasa ng gateway para dito. I-filter sa orihinal na pinagmulan upang hindi mabasa ang buong talahanayan.

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

Ang bawat entry ay may dalawang tuple, orihinal at tugon, na siyang dalawang direksyon ng isang daloy at hindi dalawang aplikasyon. Sa landas na may source-NAT, pinapanatili ng orihinal na tuple ang address ng tunnel habang ang panig ng tugon ay nagpapakita ng isinaling address ng gateway, at iyon mismo ang dahilan kung bakit ang output ay mukhang mali sa unang tingin.

Ituring ang listahan bilang buhay na estado at hindi bilang kasaysayan. Ang maiikling daloy ay maaaring nag-expire na, ang trapikong hindi sinusubaybayan ay hindi kailanman lumilitaw, at ang ibang namespace ng network ay nagpapakita ng ibang talahanayan. Ang reference ng conntrack ay nagdodokumento ng mga filter at ng dalawang-direksyong output.

Isang limitadong paghuli upang kumpirmahin ang pagbasa

Kung ang interface ng tunnel ay nakikita sa kinatatayuan mo, ang isang limitadong paghuli ay nagpapasya kung ang mga packet na tinukoy mo ay ang mga nasa kawad. Panatilihing makitid ang filter at maliit ang limitasyon ng packet.

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

Ihambing ang mga timestamp, protocol at port sa entry ng daloy at sa kahilingang ginawa mo bilang pagsubok. Ang paghuling kinuha pagkatapos ng NAT ay nagpapakita lamang ng pampublikong address ng gateway, habang ang panig ng tunnel ay maaaring nagpapakita pa ng sa client, at ang pagkakaibang iyon ay impormasyon at hindi pagkakasalungatan.

Kung wala itong nakikita ang interface, suriin ang landas ng data bago magpasyang walang ginagawa ang client: ang trapiko ng client-sa-client at ilang landas ng offload ay hindi kailanman dumadaan sa puntong binabantayan mo.

Mga log ng proxy, at ang mga hangganan ng nakita mo

Kapag may proxy sa landas, ang mga pataas na socket nito ay nakikita sa talahanayan ng socket ngunit hindi ito nagmamapa ng isa-sa-isa sa mga kliyente ng VPN, lalo na sa pooling o multiplexing. Gamitin ang naka-configure na log ng transaksyon ng proxy upang iugnay ang pagkakakilanlan ng client, destinasyon, timestamp at anumang identifier ng kahilingang itinatala nito.

Suriin ang konfigurasyon ng pag-log ng naka-deploy na bersyon sa halip na ipagpalagay na bawat kahilingan ay naka-log bilang default.

Sa huli, maging tumpak tungkol sa saklaw. Ang address ng destinasyon at port ay metadata, hindi URL at hindi nilalaman ng pahina, dahil pinapanatili ng panloob na session ng HTTPS ang sarili nitong proteksyon anuman ang tunnel. Iulat ang naobserbahan mo, mula sa aling punto ng obserbasyon, at sa anong oras.