10415
Commento:
|
10595
|
Le cancellazioni sono segnalate in questo modo. | Le aggiunte sono segnalate in questo modo. |
Linea 71: | Linea 71: |
#list Address 176.62.53.220 #questo è l'ipv4 del server de Roma list Address 2001:4c00:893b:fa::220 #questo è l'ipv6 del server de Roma |
list Address 176.62.53.98 #questo è l'ipv4 del server de Roma |
Linea 185: | Linea 184: |
access-class vty | access-class vty! ! route-map NINUX_PRIVATE permit 10 set src 10.x.x.x ip protocol bgp route-map NINUX_PRIVATE |
Linea 189: | Linea 192: |
Il set src 10.x.x.x mettere l'ip privato della router in modo tale che gli indirizzi in tabella non abbiano l'indirizzo dellla VPN la cui barra viene filtrata. |
Avvertenze
Ricordarsi di connettere il cervello prima dell'RJ45, eviterà di mandare in crash tutta la rete.
Introduzione
Lo scopo di questa guida è la configurazione di un router di frontiera per connettere reti su cui gira OLSR tramite il protocollo BGP. La base di partenza è OpenWRT Attitude Adjustment versione Scooreggiona. La configurazione adottata prevede il link della VPN in IPV6 ma è applicabile anche in IPV4. Al momento in cui sto scrivendo questa quida il server si trova in farm e non essendo al bordo della rete ipv4 l'ip è trasportato in vpn e quindi si avrebbe una vpn dentro una vpn. Invece avendo connettività ipv6 da Telecom (vedi guida) ed essendo la farm ad un hop dal gateway ipv6 risulta più pulito.
Cosa serve
- Tinc
- Quagga (con plugin olsr)
- OLSR (con plugin quagga)
E' possibile compilarsi una versione di OperWrt AA con già tutto dentro: Basta seguire la guida (link) poi eseguire make config ed andare ad abilitare i pacchetti su indicati.
Configurare Tinc
Creiamo la cartella:
#> mkdir /etc/tinc/VPNISOLE
all'interno della quale creiamo la coppia di chiavi (privata/pubblica)
#> tincd -K
creiamo la cartella:
#> mkdir /etc/tinc/VPNISOLE/hosts
dentro cui ci spostemo la chiave pubblica rinominata bgpLAMIACITTA mentre la privata (rsa_key.priv) la lasciamo lì.
Daremo copia della chiave pubblica a contatti_at_ninux.org e dentro host metteremo la chiave del server di Roma (bgproma)
A questo punto da Gestione indirizzi ci assegnamo:
- Il numero dell AS privato
- Un indirizzo ip della rete 10.150.254.0/24
Con questi dati passiamo alla configurazione dell file /etc/config/tinc:
config tinc-net VPNISOLE option enabled 1 #option log /tmp/log/tinc.VPNISOLE.log #option debug 3 ## Server Configuration (tinc.conf) option AddressFamily any list ConnectTo bgproma option Interface vpnisole option Mode switch option Name bgpLAMIACITTA option Port 777 option PrivateKeyFile /etc/tinc/VPNISOLE/rsa_key.priv # QUESTO è il FILE HOSTS config tinc-host bgproma option enabled 1 option net VPNISOLE list Address 176.62.53.98 #questo è l'ipv4 del server de Roma option PMTUDiscovery yes option Port 777 option Subnet 10.150.254.0/24
sempre nella cartella /etc/tinc/VPNISOLE creiamo due script utilzzando l'ip preso da gestione indirizzi:
tinc-up:
ip link set dev $INTERFACE up ip addr add 10.150.254.X/24 brd 10.150.254.255 dev $INTERFACE #Mettere l'ip corretto iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
tinc-down:
ip link set dev $INTERFACE down iptables -D FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
che rendiamo eseguibili:
#> chmod +x tinc-*
Prima di provarla è necessario modificare il policy routing come descritto in basso. Senza tale modifica NF1C.
Se la VPN funziona dovremmo riuscire a pingare il server di Roma:
#> ping 10.150.254.4
Configurare Quagga
Il meccanismo di funzionamento è il seguente:
- Quagga prende le rotte locali e le annuncia al peer
- Quagga prende le rotte apprese dall'istanza locale di olsr e le manda al peer
- Quagga prende le rotte apprese dal peer e dall'istanza locale di OLSR e le scrive nella tabella di routing del kernel
bgpd.conf
questo file si trova in /etc/quagga
hostname bgpLAMIACITTA password lamiapassword1 enable password lamiapassword2 ! access-list vty permit 127.0.0.0/8 access-list vty deny any ! line vty access-class vty ! router bgp IL_MIO_AS_NUMBER bgp router-id IL_MIO_IP redistribute connected redistribute olsr neighbor 10.150.254.4 remote-as 64512 neighbor 10.150.254.4 description BGP Roma neighbor 10.150.254.4 route-map FILTERIN in neighbor 10.150.254.4 route-map FILTEROUT out ! ip prefix-list FILIN seq 10 deny 10.11.12.0/25 le 32 ip prefix-list FILIN seq 20 deny 150.217.0.0/16 le 32 ip prefix-list FILIN seq 30 deny 176.62.53.0/24 le 32 ip prefix-list FILIN seq 41 deny 10.150.254.0/24 le 32 ip prefix-list FILIN seq 42 deny 10.X.X.X/16 le 32 ip prefix-list FILIN seq 43 deny 172.16.X.X/24 le 32 ip prefix-list FILIN seq 70 permit any ! ip prefix-list FILOUT seq 41 deny 10.150.254.0/24 le 32 ip prefix-list FILOUT seq 70 permit any ! route-map FILTERIN permit 10 match ip address prefix-list FILIN ! route-map FILTEROUT permit 10 match ip address prefix-list FILOUT ! route-map FILTER deny 50 !
Le informazioni di AS number e Ip presi da gestione indirizzi sono utilizzati in questo file. Le direttive "redistribute" non fanno altro che mandare al peer le rotte locali (connected) e quelle apprese vi olsr (olsr). La prima serve perchè l'hna annunciato localmente non viene preso in considerazione. Quando si parla di rotte locali in un sistema multitable si intende quelle presenti nella tabella main (ip r s t main). Se nella nostra tabella abbiamo delle rotte che non annunciamo il olsr e non vogliamo che vadano in giro per le isole le inseriamo nellaa lista FILOUT. Questo è il caso dalla 10.150.254.0/24 che è la sottorete della VPN e non ha senso annunciare anzi può essere dannosa in quanto una volta arrivata potrebbe far cadere la connessione vpn che l'ha trasportata (autodistruzione). Stesso discorso per le reti che si "apprendono" dall'esterno. In questo caso decide di filtrare in ingresso:
- 10.11.12.0/25 che è la sottorete anycast romana
- 150.217.0.0/16 non lo so
- 176.62.53.0/24 gli indirizzi pubblici di Roma, essendo pubblici è inutile routarli via VPN
- 10.150.254.0/24 la sottorete della vpn
- 10.X.X.X/16 la classe di ip che sono stati assegnati alla mia isola
- 172.16.X.X/24 la classe di ip che sono stati assegnati alla mia isola
zebra.conf
questo file si trova in /etc/quagga
password lamiapassword1 table 111 ! access-list vty permit 127.0.0.0/8 access-list vty deny any ! line vty access-class vty! ! route-map NINUX_PRIVATE permit 10 set src 10.x.x.x ip protocol bgp route-map NINUX_PRIVATE
Unica cosa interessante di questo file è che diciamo in che tabella del kernel mettere le rotte apprese, ovvero la 111.
Il set src 10.x.x.x mettere l'ip privato della router in modo tale che gli indirizzi in tabella non abbiano l'indirizzo dellla VPN la cui barra viene filtrata.
Configurare Olsr
questo file è in /etc/config/olsr. Oltre alla configurazione standard che qui non riporto, bisogna aggiungere il caricamento del plugin di quagga:
config LoadPlugin option library 'olsrd_quagga.so.0.2.2' option Redistribute 'bgp' option ExportRoutes 'only' option Distance '100' option LocalPref 'false' option SockPath '/tmp/run/quagga/zserv.api' option Version '2'
Modifiche a rc.local di Scooreggione
Rispetto al file rc.local fornito di default con scooreggione sono state apportate le diverse modifiche:
- Sono state eliminate le policy sulle subnet 176.62.53.0, Per un'isola ninux sono pubblici come tutti altri e devono andare verso la default
- è stata aggiunta una lookup sulla main per la 10.150.254.0/24 a maggior preferenza in quanto match la 10.0.0.0/8 mandando la rete vpn in blackhole.
# Put your custom commands here that should be executed once # the system init finished. By default this file does nothing. #110 Local routes #111 RtTable #112 RtTableDefault #113 Special Table for /1 #114 blackholes table #Copy local routes only from table main 254 to table 110 ip route show table 254 | grep -Ev ^default | grep -Ev ^blackhole | while read ROUTE ; do MASK=`echo "${ROUTE}" | awk '{print $1}' | awk -F/ '{print $2}'` if [ "$MASK" -ne 16 ] ; then ip route add table 110 $ROUTE fi done #First evaluate local routes ip rule add from all lookup 110 pref 3 #La rotta della vpn sta nella main ip rule add to 10.150.254.0/24 table main pref 3 #Private routes to OLSR table ip rule add to 10.0.0.0/8 table 111 pref 4 ip rule add to 172.16.0.0/12 table 111 pref 4 ip rule add to 192.168.0.0/16 table 111 pref 4 #Evaluate blackholes ip rule add from all table 114 pref 5 #Lookup default route first from user and then from OLSR ip rule add from all lookup 254 pref 7 ip rule add from all lookup 112 pref 8 #Blackhole private aggregates ip route add blackhole 10.0.0.0/8 table 114 ip route add blackhole 172.16.0.0/12 table 114 ip route add blackhole 192.168.0.0/16 table 114 exit 0
Misc
In questa sezione un po di tips utili
IPV6 e Radvd
Con scooreggione v4 avevo il problema che l'interfaccia lan non mi prendeva l'ipv6 dal router che riceveva la delega della /64 dal provider. Il problema è stato risolto così:
echo 0 > /proc/sys/net/ipv6/conf/all/forwarding
e reso definitivo andando a modificare il file /etc/sysctrl.conf
Topologia e linee verdi sul mapserver
Nonostante le nostre rotte arrivino al map server via VPN esso non ci disegnerà il link perchè BGP propaga le rotte e non la topologia OLSR. Un modo per permettere al mapserver di disegnare i link è il seguente:
Avere un account su un servizio di DNS per ip dinamici (Servizio DNS molto costoso)
- Forwardare la porta 2006 del router olsr verso internet dal proprio router
Test della configurazione
Colleghiamoci al router BGP:
telnet 127.0.0.1 bgpd
mettiamo la password e una volta dentro digitiamo:
bgpLAMIACITTA> show ip bgp summary BGP router identifier 10.150.254.X, local AS number 645XX RIB entries 1169, using 82 KiB of memory Peers 1, using 2524 bytes of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.150.254.4 4 64512 152 95 0 0 0 01:28:40 640 Total number of neighbors 1
dove vediamo che l'AS 64512 (che è Roma) ci ha mandato 640 rotte. Usciamo da bgp con il comando exit e andiamo a vedere se le rotte sono nel kernel:
#> ip r s t 111