APPPUNTI VM internet e AMPRNET: differenze tra le versioni
Vai alla navigazione
Vai alla ricerca
| (10 versioni intermedie di uno stesso utente non sono mostrate) | |||
| Riga 32: | Riga 32: | ||
<pre>root@geu-ampr:/etc/wireguard# cat wg_ampr_ari0.conf | <pre>root@geu-ampr:/etc/wireguard# cat wg_ampr_ari0.conf | ||
</pre> | </pre> | ||
<pre> | <pre> | ||
[Interface] | [Interface] | ||
ListenPort = 51820 | ListenPort = 51820 | ||
| Riga 48: | Riga 43: | ||
Table = r_AMPR | Table = r_AMPR | ||
PostUp = | 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 | |||
ip | PostDown = ip -4 rule del from 44.32.33.xxx table r_AMPR | ||
ip route del | 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 | |||
ip route | |||
[Peer] | |||
PublicKey = PUBLICKEY | |||
AllowedIPs = 44.0.0.0/9, 44.128.0.0/10 | |||
Endpoint = 5.144.187.34:13236 | |||
PresharedKey = PRESHAREDKEY | |||
</pre> | </pre> | ||
| Riga 157: | Riga 149: | ||
# Completed on Wed Mar 6 14:11:24 2024 | # Completed on Wed Mar 6 14:11:24 2024 | ||
</pre> | </pre> | ||
Migliorie: | |||
* aggiungere un drop dei bogons in ingresso | |||
* specificare l'interfaccia | |||
'''Attivazione/ripristino delle regole di firewall''' | '''Attivazione/ripristino delle regole di firewall''' | ||
| Riga 180: | Riga 176: | ||
== Traffic shaping - DA RAGIONARCI ANCORA == | == Traffic shaping - DA RAGIONARCI ANCORA == | ||
Su una VM che non fa routing, questo approccio funziona in egress, cioè solo in uscita. | |||
<pre> | <pre> | ||
# Impostazione generale di shaping | # Impostazione generale di shaping | ||
| Riga 195: | Riga 192: | ||
</pre> | </pre> | ||
== | Influenzare un pochino la banda in ingresso sarebbe possibili tramite ifb. Non sa quanto sia efficace. Da provare... | ||
<pre> | |||
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 | |||
</pre> | |||
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. | |||
<pre> | |||
iptables -A INPUT -p udp -m limit --limit 10/sec --limit-burst 20 -j ACCEPT | |||
iptables -A INPUT -p udp -j DROP | |||
</pre> | |||
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: | |||
<code> | |||
export HISTTIMEFORMAT="%d/%m/%y %T " | |||
</code> | |||
=== prompt colorato === | |||
Impostazioni da mettere nel proprio .bash_profile | |||
root_in_rosso@hostname_in_azzurro | |||
<code> | |||
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\]' | |||
</code> | |||
utente_non_root_in_verde@hostname_in_azzurro | |||
<code> | |||
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\]' | |||
</code> | |||
== Certificati SSL/TLS - TROVARE SOLUZIONE == | |||
Trovare soluzione per poter avere automatismi gratuiti di emissione/aggiornamento di certificati per SSL/TLS dei server AMPR ARI | Trovare soluzione per poter avere automatismi gratuiti di emissione/aggiornamento di certificati per SSL/TLS dei server nella rete 44 AMPR ARI | ||
; LetsEncrypt | ; LetsEncrypt https://letsencrypt.org/docs/challenge-types/ | ||
: * Metodo riconoscimento via WEB necessità il raggiungimento del ip 44 da LetsEncrypt/internet | : * Metodo riconoscimento via WEB necessità il raggiungimento del ip 44 da LetsEncrypt/internet (HTTP-01 challenge) | ||
: * Metodo riconoscimento via DNS necessità | : * Metodo riconoscimento via DNS necessità di un DNS aggiornabile via API (DNS-01 challenge) | ||
Versione attuale delle 13:34, 28 mar 2024
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)