Radek Tománek napsal/wrote, On 09/19/07 13:40:
> nechal jsem ho poslouchat na tap0 a packety, které jsem zachytil
> byly normálně čitelné.
> 1. tunel je navázán ale nešifruje
> 2. wireshark získá packety až po jejich rozšifrování
2 je spravne. A taky 3 je spravne (WireShark ziskava pakety pred jejich
zasifrovanim).
Paket (nesifrovany, poslany nejakou (aplikaci) prijde pres nejakou
sitovou kartu a vstoupi do jadra. To na zaklade routovaci tabulky a
dalsich pravidel zjisti, ze "next-hop" je intervace tap0 a paket (stale
nesifrovany) na nej preda. Tento interface nereprezentuje skutecny
hardware, nicmene, an jeho miste sedi software, ktere s paketem cosi
udela (zasifruje) a vytvori z nej bezny aplikacni datovy paket, ktery ze
sitoveho socketu odesle - paket (ted uz zasifrovany) vstoupi pres sitovy
socket dojadra, to zjisti, ze next-hop je sitova karta "do sveta" a pres
tu ho odesle.
V opacnem smeru aket prijde pres "vnejsi" sitovou kartu do jadra
(zasifrovany). Podle cilove adresy jadro zjisti, ze paket patri lokalni
aplikaci (OpenVPN) a pres sitovy socket ji ho (stale zasifrovany)
preda.OpenVPN s paketem udela co uzna za vhodne (desifruje) a protoze
ono je "hardwarem" sitove kartu tun0, ktery jakoby paket prave prijal z
venku, nesifrovany paket vstupuje do jadra znovu, tenkrat jako paket
prijaty interfacem tun0. Jazdro zjisti kam (nesifrovany_ paket patri a
tam ho odesle.
WireShark ziskava pakety prostrednictvim BPF, ktere pakety "krade" na
rozhrani mezi sitovou kartou a jadrem. Pokud tedy poslouchas na rozhrani
tap0 a jadra musis videt pakety nesifrovane. Sifrovane bys je videl na
vystupnim sitovem interfacu ...
Dan
--
Dan Lukes SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
