ipsec na 2.6.3 a iptables

[Zdenek Prchal]

> To ovšem nic nemění na tom, že je problém, jak filtrovat příchozí provoz;
> netfilterem to asi nepůjde. Takže bude potřeba rozlišovat až na úrovni
> jednotlivých aplikací. Spoofingu se není třeba bát, protože pokud při
> definování příslušné security policy dáte 'require', mělo by to znamenat,

Ja to resim pres netfilter takhle (pouzivam shorewall, takze jsou ty
pravidla
zbytecne slozity a to jsem je jeste ocesal - zajimavy jsou pouze chainy
FORWARD a INPUT na smeru z verejneho interface wlan0, kde je potreba povolit
mimo jine prichozi pakety z ipsec tunelu):

Chain FORWARD (policy DROP 14 packets, 840 bytes)
 pkts bytes target     prot opt in     out     source
destination
    0     0 DROP      !icmp --  any    any     anywhere             anywhere
state INVALID
 656K  510M wlan0_fwd  all  --  wlan0  any     anywhere             anywhere

Chain wlan0_fwd (1 references)
 pkts bytes target     prot opt in     out     source
destination
10550 7176K vpn_frwd   all  --  any    any     192.168.0.0/16       anywhere
 646K  503M net2loc    all  --  any    eth0    anywhere             anywhere
(chain net2loc forwarduje SNATovany a DNATovany provoz z internetu
do privatni site - mimo ipsec tunel)

Chain vpn_frwd (1 references)
 pkts bytes target     prot opt in     out     source
destination
10550 7176K vpn2all    all  --  any    eth0    anywhere             anywhere

Chain vpn2all (3 references)
 pkts bytes target     prot opt in     out     source
destination
10570 7180K ACCEPT     all  --  any    any     anywhere             anywhere
state RELATED,ESTABLIS
   10   606 ACCEPT     all  --  any    any     anywhere             anywhere

No a chain INPUT (z verejneho interface) vypada takhle:
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
 1946  240K ACCEPT     all  --  lo     any     anywhere             anywhere
    0     0 DROP      !icmp --  any    any     anywhere             anywhere
state INVALID
19549 9489K wlan0_in   all  --  wlan0  any     anywhere             anywhere

Chain wlan0_in (1 references)
 pkts bytes target     prot opt in     out     source
destination
16983 9219K dynamic    all  --  any    any     anywhere             anywhere
state NEW
   30  3870 vpn2all    all  --  any    any     192.168.0.0/16       anywhere
19519 9485K net2fw     all  --  any    any     anywhere             anywhere
(tady do chainu vpn2all jdou pakety z tunelu, ktere konci na firewallu)
btw, neni mi jasny ten target dynamic - prislusny chain existuje, ale je
prazdny
jak se to vlastne chova?

no a chain net2fw resi vlastni input z internetu:
Chain net2fw (1 references)
 pkts bytes target     prot opt in     out     source
destination
 2071  237K ACCEPT     all  --  any    any     anywhere             anywhere
state RELATED,ESTABLIS
 2403  193K newnotsyn  tcp  --  any    any     anywhere             anywhere
state NEW tcp flags:!S
12360 8692K ACCEPT     ipv6-crypt--  any    any     linux.vtdata.cz
anywhere
    0     0 ACCEPT     ipv6-auth--  any    any     linux.vtdata.cz
anywhere
   12  1152 ACCEPT     udp  --  any    any     linux.vtdata.cz      anywhere
udp spt:isakmp dpt:isa
   16   872 ACCEPT     tcp  --  any    any     anywhere             anywhere
multiport dports domai
    1    46 ACCEPT     udp  --  any    any     anywhere             anywhere
multiport dports domai
 2656  361K net2all    all  --  any    any     anywhere             anywhere

ten ipv6-crypt- protokol jsou tusim ESP pakety z druheho konce tunelu, pak
je tam jeste povoleny udp isakmp, zbytek udp a tcp portu, ktery chci mit
otevreny a to co jde do newnotsyn a net2all se loguje a zahazuje.
A funguje to <g>

> IP adresou. Problematická je ale situace, kdy mezi koncovými body někdy
> VPN je a někdy není. To šlo s FreeS/WAN podstatně pohodlněji.

Jo - proste se nastavily pravidla podle interface a bylo vymalovano.

BTW - prekvapko bylo pro me taky v tom, ze overlapped subnety tunelovat
nejdou - mel jsem proste jeden /24 subnet lokalni a vsechno ostatni /16
za tunelem a routovalo se to vcelku logicky podle routovaci tabulky
kernelu. Ted sice takhle tunel fungoval taky, ale nemohl jsem se vubec
dostat z lokalniho subnetu primo na firewall, nejak jsem sice detailne
nezjistil proc, ale protoze jsem pritom videl nejake pakety z lokalniho
subnetu na druhym konci tunelu, tak si myslim, ze se jich chopil iniciativne
ipsec a bez ohledu na routovaci tabulku kernelu je podle vlastniho
pravidla pro 'vsechno ostatni' /16 nacpal do tunelu ;)

	Zdenek Prchal