IPv6 tunel & strongswan & pro celou síť

Dne 2015-11-01 22:54

Ahoj,

nedávno jsem si donesl také domů turris a ačkoliv ipv4 funguje out-of-the-box, s ipv6 se již nějaký den peru.

Protože můj poskytovatel (CZSpeed.net, kdyby se někdo ptal) nepodporuje ipv6, musím si vystačit s tunelem. To jsem dělal i v předchozím místě připojení (Koleje 17. listopadu, poskytuje MFF UK, které sice ipv6 "nějakou" mají, ale jenom občas a jenom /128, jej!). Tady taky, mám tedy funkční konfigurák pro strongswan, který mi funguje na dosavadním routeru.

Na turris jsem doinstaloval strongswan, tedy balíky strongswan-full, kmod-tun, strongswan-kmod-kernel-libipsec (poslední dva jsem musel nyní doinstalovat znovu, možná mi do toho sáhl updater, nebo já v rozespalosti včerejší noci, kdyžtak aktualizuji jak to vlastně je).

Konfigurace je taková:


config setup
  charondebug="ike 1, net 1, enc 1, knl 2, cfg 1"

conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    keyexchange=ikev2
    authby=psk
    mobike=no

conn net-net
    also=host-host
    leftsubnet=::/0
    rightsubnet=2a01:490:19:42::/64

conn host-host
    left=78.108.107.19
    leftid=@vpn.krakonos.org
    right=10.20.124.180
    rightid=@turris.vpn.krakonos.org
    auto=start
    rightupdown=/etc/ipsec.d/updown.sh

To docela chodí. v /etc/config/network mám navíc


config interface 'lan'
[.....]
  option ip6addr '2a01:490:19:42::1/64'
  option ip6assign '64'

Což samozřejmě funguje skoro dobře. IPSec se ověří a postaví tunel (ještě mi chyběly nějaké kernelové moduly, ale to si postěžovalo, a já si nenapsal které), ipv6 na turrisu funguje.


root@turris:~# ipsec status
no files found matching '/etc/strongswan.d/charon/*.conf'
no files found matching '/etc/strongswan.d/*.conf'
Security Associations (1 up, 0 connecting):
     net-net[1]: ESTABLISHED 18 minutes ago, 10.20.124.180[turris.vpn.krakonos.org]...78.108.107.19[vpn.krakonos.org]
     net-net{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: 066cafa9_i c8b8006d_o
     net-net{1}:   2a01:490:19:42::/64 === ::/0

Do sítě mi turris začně správně ohlašovat dostupný prefix, to vše chodí. Bohužel někde na něm se zaseknou pakety, které cestují z vnitřní sítě do tunelu, nebo naopak, a netuším kde. Proč to musí být tady? Protože tunel sestavený z mého starého routeru s přesně touhle konfigurací funguje.

Jedna věc, které je jiná, je updownscript, který mi přidával ručně policy povolující forward.

Co je zajímavé, ip xfrm pol mi ale žádné policy nevypíše, i když z turrisu ipv6 funguje a protože nemá jinudy, určitě teče tunelem.

Co je zajímavější, dal bych ruku do ohně, že před pár dny, když jsem to zkoušel, jsem nějaké standardní policy viděl. Když si nějakou ručně přidám, tak ji vidím a můžu s ní manipulovat (inu, abych to mohl udělat, musím si nainstalovat ip-full, a to pokaždé když auto-update se rozhodne aktualizovat ip...).

Díval jsem se do /etc/config/firewall a je tam spoustu podivných pravidel pro ipv6, nevím proč, pro ipv4 tam nejsou a nejsou to žádné specialitky. Nějaké nápady co s tím?

Nechtěl jsem dělat nic moc invazivního, přecejenom nejsem openwrt expert a už do toho šahá fortis...

Nápady? Vylepšení? Předělání?

PS: 6in4 spíš nechci, ač vím, že by to mělo být jednodušší a vypadá to, že je k tomu návod.

Od Michal Vaner (>>)

Dne 2015-11-02 09:47

Dobré ráno

Strongswan neznám, ale problém čuchám směrem od toho, že network skripty nic o tom rozhraní, které si strongswan vyrobí, netuší.

Mohlo by pomoct něco podobného, jako mám já v síťové konfiguraci (viz níž). Tím se řekne skriptům, že bude takové rozhraní existovat a že se narodí samo, ale že ho mají znát. Poté se v /etc/config/firewall dá přidat do zóny WAN, takže by to mělo začít routovat ‒ až se to rozhraní samo objeví, tak se firewall reloadne a zařídí tyto potřebné věci a pravidla.

config interface 'tun0'
  option proto 'none'
  option ifname 'tun0'
  option auto '1'

Od Ondřej Caletka (>>>)

Dne 2015-11-02 11:00

Díky za ukázku použití Strongswanu. Mám už leta v plánu to prozokoumat a stále jsem se k tomu nedostal :)

IPv6 stack v OpenWRT blokuje pomocí policy routingu (ip -6 rule) všechny IPv6 pakety, přicházející z adres, na kterých se nemají objevit. Seznam prefixů, které jsou na rozhraní přiděleny uvidíte třeba z ifstatus lan v rubrice ipv6-prefix-assignment.

Jak prefix na rozhraní přidělit? Tak že kolem IPSec upstreamu založíte logické WAN rozhraní, u kterého nastavíte volbu ip6prefix na prefix, který tímto rozhraním přichází. Na LAN rozhraní doporučuji adresu ip6addr nevyplňovat, nastaví se tam sama, poté co bude na rozhraní přidělen prefix (to se určí volbou ip6assign.

Tedy mělo by stači něco jako:


config interface wan6
  option ifname "<místní konec tunelu>"
  option proto static
  option ip6prefix "2a01:490:19:42::/64"

Od LadislavLaska

Dne 2015-11-11 19:58

Dobré vědět. Udělal jsem si opět trošku času na experimenty. Přidat interface wan6 (resp. změnit dosavadní "prázdnou" definici) prakticky nic nezměnilo, jenom v ip -6 rule přibyl řádek s daným prefixem. Několik zajímavých věcí, které jsem našel:

Routovací tabulka:


root@turris:~# ip -6 r
2a01:490:19:42::/64 dev br-lan  proto static  metric 1024
unreachable 2a01:490:19:42::/64 dev lo  proto static  metric 2147483647  error -101
fd2d:c5df:8520::/64 dev br-lan  proto static  metric 1024
unreachable fd2d:c5df:8520::/48 dev lo  proto static  metric 2147483647  error -101
fe80::/64 dev br-lan  proto kernel  metric 256
fe80::/64 dev eth2  proto kernel  metric 256
fe80::/64 dev wlan0  proto kernel  metric 256

Pravidla


root@turris:~# ip -6 rule
0:      from all lookup local
220:    from all lookup 220
32766:  from all lookup main
4200000000:     from 2a01:490:19:42::1/64 iif br-lan unreachable
4200000001:     from all iif lo failed_policy
4200000004:     from all iif eth2 failed_policy
4200000011:     from all iif br-lan failed_policy
4200000011:     from all iif br-lan failed_policy

Další zajímavé je, že pokud pingám turris ze sítě, na jeho v6 adrese ( 2a01:490:19:42::1 ), tak turris odpovídá, dokud nezapnu ipsec. Potom odpovědi letí do tunelu, ačkoliv routa nahoře říká, že to má jít do br-lan, a tedy poslat do vnitřní sítě.

Navíc, všechno tohle je stejné, nehledě na to, zda je ipsec zapnutý nebo ne.

Stále mi tedy není jasné, kde jsou pravidla, která posílají pakety tunelem. Stejnětak mi není jasné, kde je pravidlo, které řekne, že se odpověď na ping, na adresu lokální sítě, má poslat do tunelu. Nějaké nápady?

Mimochodem, dříve jsem musel ručně přidávat policy scriptem updown.sh

#!/bin/sh
POLICY_ADD="/usr/sbin/ip xfrm policy add"

case "${PLUTO_VERB}" in
"up-client-v6")
        if [ "${PLUTO_CONNECTION}" = "net-net" ]; then
                ${POLICY_ADD} src "${PLUTO_MY_CLIENT}" dst "${PLUTO_MY_CLIENT}" dir in action allow
                ${POLICY_ADD} src "${PLUTO_MY_CLIENT}" dst "${PLUTO_MY_CLIENT}" dir out action allow
        fi
        ;;
esac

Nyní jsem to ale nikam necpal, už jenom proto, že routing vypadá o poznání jinak a nechci moc rozbít pravidla openwrt... (a krom toho to nepomohlo, když jsem to vyzkoušel).

Od LadislavLaska

Dne 2016-01-26 18:26

Hotovo!

Dnes jsem to zprovoznil, snad napíšu, jak na to. Vycházím ze stavu, kde mám ipsec zprovozněný a mám funkční tunel.

Po nějakém laborování jsem si všiml, že turris všechny pakety posílá na ipsec rozhraní, včetně odpovědí, které se mají vrátit do lokální sítě. Díval jsem se na routy, a opravdu usilovně se divil proč, protože by měl zvolit tu nejvíce specifickou a moje routy vypadají takhle:

root@turris:/etc/config# route -A inet6
Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
...
::/0                                        ::                                      U     1024   0      107 ipsec0  
2a01:490:19:42::/64                         ::                                      U     1024   0        0 br-lan  
...

Proč to tedy posílá na ipsec0, když to je ta nejméně specifická routa, kterou jde vyrobit?

Je nutné si uvědomit, že StrongSwan vkládá routy do tabulky 220. Já si jí raději pojmenoval:

echo "220 ipsec" >> /etc/iproute2/rt_tables

Super. Po spuštění ipsecu mi vytvoří pravidlo NADŘAZENÉ hlavní routovací tabulce, a to speciálně 220: from all lookup ipsec:

root@turris:/etc/config# ip rule list
0:  from all lookup local 
220:  from all lookup ipsec 
32766:  from all lookup main 
32767:  from all lookup default

Tam je todle:

root@turris:/etc/config# ip -6 r show table ipsec
default dev ipsec0  proto static  src 2a01:490:19:42::1  metric 1024

Dává to smysl, podle této tabulky se kernel mohl řídit, a tak se podle ní řidil, a to dřív, než došel k pravidlu o tabulce main. To teda nic moc. Tady se nabízí dvě řešení: buď do tabulky ipsec(220) vložit ručně routu o lokálnín síti, nebo říct ipsecu, aby vkládal pravidla do jiné tabulky, a to vložením routing_table = 254 do strongswan.conf; můj by vypadá takto:

charon {
  plugins {
    include strongswan.d/charon/*.conf
  }
  routing_table = 254
}

Což je docela dobrá varianta, protože nemusím manuálně přepisovat routu až změním nějakou konfiguraci (třeba rank).

Navíc poznámka pro zvědavé: jak nastavit zóny firewallu a tak? Já si definoval v /etc/config/network dvě rozhraní:

config interface 'lan6'
  option ifname '@lan'

config interface 'wan6'
  option ifname 'ipsec0'
  option proto 'static'
  option ip6prefix '2a01:490:19:42::/64'

Každému z nich nastavil vlastní zónu a povolil v nich forwardování (klikátkem). POZOR ale, má to háček. v4 a v6 zóny musí být oddělené, pokud jedna z nich bude mít "oba" protokoly, všechno se to rozsype, protože openwrt konfigurovátko si někdy v nahazování firewallu přepíše kus toho co už nakonfigurovalo :-)

IPv6 zdar!