APPPUNTI VM internet e AMPRNET

Appunti di viaggio per gli addetti ai lavori

WORK IN PROGRESS - DA TESTARE

Vm di base

Questa è una VM debian minimal su OVH che ha una configurazione di rete MOLTO particolare. Se funziona qui, ci sono altissime probabilità che funioni anche da voi.

La VM nasce con connettività internet del provider di hosting. Si vuole ottenere che un servizio di rete venga erogato verso internet se richiesto da internet e verso la 44 se richiesto da AMPR.

Pacchetti base installalti: iptables iptables-persistent systemd-resolved wireguard ssh caddy

interfacce - OK

root@geu-ampr:/etc/network# cat interfaces

source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
    address ip.in.ter.net/32
    post-up ip route add              gw.in.ter.net dev eth0
    post-up ip route add  default via gw.in.ter.net dev eth0
    pre-down ip route del default via gw.in.ter.net dev eth0
    pre-down ip route del             gw.in.ter.net dev eth0

tunnel wireguard - OK

root@geu-ampr:/etc/wireguard# cat wg_ampr_ari0.conf 

[Interface]
ListenPort = 51820
PrivateKey = PRIVATEKEY
Address = 44.32.33.xxx/21
# Se si usa questa riga DNS, tutte le richieste dns verranno dirottate li. Usare systemd-resolved per avere un risolutore specifico per dominio
#DNS = 44.32.32.2, 44.60.44.3, 44.32.32.1

# Creare riga "585 r_AMPR" in /etc/iproute2/rt_tables
Table = r_AMPR

PostUp = ip -4 rule add from 44.32.33.xxx table r_AMPR
PostUp = ip -4 route add 44.0.0.0/9    via 44.32.32.1
PostUp = ip -4 route add 44.128.0.0/10 via 44.32.32.1

PostDown = ip -4 rule del from 44.32.33.xxx table r_AMPR
PostDown = ip -4 route del 44.0.0.0/9    via 44.32.32.1 dev wg0 table r_AMPR
postDown = ip -4 route del 44.128.0.0/10 via 44.32.32.1 dev wg0 table r_AMPR

[Peer]
PublicKey = PUBLICKEY
AllowedIPs = 44.0.0.0/9, 44.128.0.0/10
Endpoint = 5.144.187.34:13236
PresharedKey = PRESHAREDKEY

Abilitazione del servizio per l'avvio automatico:

systemctl enable wg-quick@wg_ampr_ari0.service
systemctl start wg-quick@wg_ampr_ari0

Test instradamento - OK

Test delle rotte OK

root@geu-ampr:~# ip ro get 8.8.8.8
8.8.8.8 via 51.75.243.254 dev ens18 src 193.70.17.196
    cache
root@geu-ampr:~# ip ro get 44.32.32.2
44.32.32.2 dev wg_ampr_ari src 44.32.33.162
    cache
root@geu-ampr:~# ip ro get 44.88.0.1
44.88.0.1 via 44.32.32.1 dev wg_ampr_ari src 44.32.33.162
    cache

Test instradamento verso internet OK

root@geu-ampr:~# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  551.255.69.252 (551.255.69.252)  0.505 ms  0.508 ms  0.669 ms
 2  510.17.50.50 (510.17.50.50)  0.521 ms  0.618 ms  0.697 ms
 3  510.73.17.66 (510.73.17.66)  0.199 ms
 4  510.95.64.136 (510.95.64.136)  0.574 ms
 5  * * *
 6  510.200.2.69 (10.200.2.69)  3.965 ms  3.929 ms
 7  * * *
 8  * * *
 9  66.249.94.133 (66.249.94.133)  4.942 ms dns.google (8.8.8.8)  4.100 ms 142.250.234.43 (142.250.234.43)  4.897 ms

Test instradamento verso AMPR ARI OK

root@geu-ampr:~# traceroute 44.32.32.2
traceroute to 44.32.32.2 (44.32.32.2), 30 hops max, 60 byte packets
 1  44.32.32.1 (44.32.32.1)  25.891 ms  25.864 ms  25.882 ms
 2  44.32.32.2 (44.32.32.2)  28.531 ms  28.537 ms  28.528 ms

Test instradamento verso AMPR fuori da AMR ARI OK

root@geu-ampr:~# traceroute 44.88.0.1
traceroute to 44.88.0.1 (44.88.0.1), 30 hops max, 60 byte packets
 1  44.32.32.1 (44.32.32.1)  25.710 ms  25.698 ms  25.683 ms
 2  gw.hamgatect.ampr.org (44.88.0.1)  145.807 ms  145.784 ms *

firewall - OK

Il firewall è molto personale e va implementato secondo le proprie esigenze. Questo vuole solo essere un punto di partenza.

Oltre ad iptables viene usato il pacchetto iptables-persistnet che salva in /etc/iptables le regole e le attiva all'avvio.

root@geu-ampr:/etc/iptables# cat rules.v4 

# Generated by iptables-save v1.8.9 (nf_tables) on Wed Mar  6 14:11:24 2024
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Wed Mar  6 14:11:24 2024
# Generated by iptables-save v1.8.9 (nf_tables) on Wed Mar  6 14:11:24 2024
*filter
:INPUT DROP [79:8052]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [118:18860]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 51820 -j ACCEPT -m comment --comment "WireGuard"
-A INPUT -p icmp --icmp-type destination-unreachable/source-quench              -j ACCEPT -m comment --comment "PMTU Discovery"
-A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --limit-burst 10 -j ACCEPT -m comment --comment "ping si ma non troppo"
-A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/m --limit-burst 1  -j LOG --log-prefix "ICMP flood scampato: "
-A INPUT -p icmp --icmp-type echo-request -j DROP
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -m comment --comment "servizio WEB HTTP"
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT -m comment --comment "servizio WEB HTTPS"
-A INPUT -s ip.qth -m comment --comment "Casa" -j ACCEPT
COMMIT
# Completed on Wed Mar  6 14:11:24 2024

Migliorie:

• aggiungere un drop dei bogons in ingresso
• specificare l'interfaccia

Attivazione/ripristino delle regole di firewall

iptables-restore </etc/iptables/rules.v4

Salvataggio delle regole di firewall

Se si fanno dei cambiamenti a mano da riga di comando direttamente con iptables, occorre salvarle per ritrovarsele attive dopo un riavvio.

iptables-save >/etc/iptables/rules.v4

Raggiungibilità servizi - OK

Test raggiungibilità

• su ip numerico internet http://193.70.17.196 OK da internet
• su dominio internet http://vm.iw1geu.audric.it OK da internet
• su ip numerico AMPR ARI http://44.32.33.162 OK da AMPR ARI
• su dominio AMPR ARI http://vm.iw1geu.ampr.ari.it OK da AMPR ARI mentre da AMPR fuori ARI è da testare

Traffic shaping - DA RAGIONARCI ANCORA

Su una VM che non fa routing, questo approccio funziona in egress, cioè solo in uscita.

# Impostazione generale di shaping
tc qdisc add dev wg_ampr_ari0 root handle 1: htb default 11

# massimo bitrate totale per interfaccia
tc class add dev wg_ampr_ari0 parent 1: classid 1:1 htb rate 5000kbps

# definizione classe limitata a 1000kpbs
tc class add dev wg_ampr_ari0 parent 1:1 classid 1:10 htb rate 1000kbps

# Limita traffico UDP (protocollo 17) ridirigendolo alla classe limitante
tc filter add dev wg_ampr_ari0 protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff flowid 1:10

Influenzare un pochino la banda in ingresso sarebbe possibili tramite ifb. Non sa quanto sia efficace. Da provare...

ip link add name ifb0 type ifb
ip link set dev ifb0 up
tc qdisc add dev wg_ampr_ari0 handle ffff: ingress
tc filter add dev wg_ampr_ari0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0
tc qdisc add dev ifb0 root handle 1: htb default 11

E' possibile anche limitare il numero di pacchetti UDP in ingresso tramite iptables ma questo potrebbe danneggiare traffico legittimo e bisognerà creare eccezzioni. Se la limitazione impatta sul VoIP o altri stream che non devono avere limitazione, si dovrà andare a creare una eccezzione a monte con un ACCEPT.

iptables -A INPUT -p udp -m limit --limit 10/sec --limit-burst 20 -j ACCEPT
iptables -A INPUT -p udp -j DROP

Pericoloso ma fattibile sarebbe far loggare ad iptables il blocco UDP e far anallizare il log a fail2ban per procedere di conseguenza.

Terminal gems

history alla BSD

Impostazioni da mettere nel proprio .bash_profile Questa mostra il timestamp della history in classico stile BSD. es:

export HISTTIMEFORMAT="%d/%m/%y %T "

prompt colorato

Impostazioni da mettere nel proprio .bash_profile

root_in_rosso@hostname_in_azzurro

export PS1='\[\e[0;31m\]\u\[\e[m\]\[\e[1;29m\]@\[\e[1;34m\]\h \[\e[1;32m\]\w\[\e[m\] \[\e[1;32m\]\$\[\e[m\] \[\e[29m\]'

utente_non_root_in_verde@hostname_in_azzurro

export PS1='\[\e[0;32m\]\u\[\e[m\]\[\e[1;29m\]@\[\e[1;34m\]\h \[\e[1;32m\]\w\[\e[m\] \[\e[1;32m\]\$\[\e[m\] \[\e[29m\]'

Certificati SSL/TLS - TROVARE SOLUZIONE

Trovare soluzione per poter avere automatismi gratuiti di emissione/aggiornamento di certificati per SSL/TLS dei server nella rete 44 AMPR ARI

LetsEncrypt https://letsencrypt.org/docs/challenge-types/

* Metodo riconoscimento via WEB necessità il raggiungimento del ip 44 da LetsEncrypt/internet (HTTP-01 challenge)

* Metodo riconoscimento via DNS necessità di un DNS aggiornabile via API (DNS-01 challenge)