APPPUNTI VM internet e AMPRNET: differenze tra le versioni

Da AMPR ARI.
Vai alla navigazione Vai alla ricerca
 
(21 versioni intermedie di uno stesso utente non sono mostrate)
Riga 13: Riga 13:
Pacchetti base installalti: iptables iptables-persistent systemd-resolved wireguard ssh caddy
Pacchetti base installalti: iptables iptables-persistent systemd-resolved wireguard ssh caddy


== interfacce ==  
== interfacce - OK ==  
<pre>root@geu-ampr:/etc/network# cat interfaces
<pre>root@geu-ampr:/etc/network# cat interfaces
</pre>
</pre>
Riga 29: Riga 29:
</pre>
</pre>


== tunnel wireguard ==
== tunnel wireguard - OK ==
<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>[Peer]
<pre>
PublicKey = PUBLICKEY
AllowedIPs = 44.0.0.0/9, 44.128.0.0/10
Endpoint = 5.144.187.34:13236
PresharedKey = PRESHAREDKEY
 
[Interface]
[Interface]
ListenPort = 51820
ListenPort = 51820
Riga 48: Riga 43:
Table = r_AMPR
Table = r_AMPR


PostUp = /etc/wireguard/wg_ampr_ari-up0.sh
PostUp = ip -4 rule add from 44.32.33.xxx table r_AMPR
</pre>
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


<pre>root@geu-ampr:/etc/wireguard# cat wg_ampr_ari0-up.sh
PostDown = ip -4 rule del from 44.32.33.xxx table r_AMPR
</pre>
PostDown = ip -4 route del 44.0.0.0/9    via 44.32.32.1 dev wg0 table r_AMPR
<pre>#!/bin/bash
postDown = ip -4 route del 44.128.0.0/10 via 44.32.32.1 dev wg0 table r_AMPR


ip route del 44.0.0.0/9    via 44.32.32.1 >/dev/null ||true
[Peer]
ip route del 44.128.0.0/10 via 44.32.32.1 >/dev/null ||true
PublicKey = PUBLICKEY
ip route add 44.0.0.0/9   via 44.32.32.1
AllowedIPs = 44.0.0.0/9, 44.128.0.0/10
ip route add 44.128.0.0/10 via 44.32.32.1
Endpoint = 5.144.187.34:13236
 
PresharedKey = PRESHAREDKEY
ip route del 44.0.0.0/9    via 44.32.32.1 dev wg_ampr_ari0 table r_AMPR >/dev/null |true
ip route del 44.128.0.0/10 via 44.32.32.1 dev wg_ampr_ari0 table r_AMPR >/dev/null |true
ip route add 44.0.0.0/9    via 44.32.32.1 dev wg_ampr_ari0 table r_AMPR
ip route add 44.128.0.0/10 via 44.32.32.1 dev wg_ampr_ari0 table r_AMPR


</pre>
</pre>
Riga 73: Riga 65:
</pre>
</pre>


== Test instradamento ==
== Test instradamento - OK ==


Test delle rotte '''OK'''
Test delle rotte '''OK'''
Riga 123: Riga 115:
</pre>
</pre>


== firewall ==
== 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.'''
'''Oltre ad iptables viene usato il pacchetto iptables-persistnet che salva in /etc/iptables le regole e le attiva all'avvio.'''
Riga 149: Riga 143:
-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 -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 icmp --icmp-type echo-request -j DROP
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-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
-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
-A INPUT -s ip.qth -m comment --comment "Casa" -j ACCEPT
COMMIT
COMMIT
# 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 168: Riga 166:
</pre>
</pre>


== NS resolver selettivo ==  
== Raggiungibilità servizi - OK ==


''' DA RIVEDERE '''
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


Resolver di default e resolver specifico per dominio e sottodomini di ampr.ari.it
== Traffic shaping - DA RAGIONARCI ANCORA ==
<pre>root@geu-ampr:/etc/systemd/resolved.conf.d# cat ampr.ari.it.conf
 
</pre>
Su una VM che non fa routing, questo approccio funziona in egress, cioè solo in uscita.  
<pre>
<pre>
[Resolve]
# Impostazione generale di shaping
Domains=ampr.ari.it
tc qdisc add dev wg_ampr_ari0 root handle 1: htb default 11
DNS=44.32.32.2 44.60.44.3 44.32.32.1
 
# 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
 
</pre>
</pre>


<pre>root@geu-ampr:/etc/systemd/resolved.conf.d# cat dns_servers.conf
Influenzare un pochino la banda in ingresso sarebbe possibili tramite ifb. Non sa quanto sia efficace. Da provare...
</pre>
<pre>
<pre>
[Resolve]
ip link add name ifb0 type ifb
DNS=8.8.8.8
ip link set dev ifb0 up
Domains=~.
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>
</pre>


Test configurazione '''da rivedere'''
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>
<pre>
root@geu-ampr:~# resolvectl status
iptables -A INPUT -p udp -m limit --limit 10/sec --limit-burst 20 -j ACCEPT
iptables -A INPUT -p udp -j DROP
</pre>
</pre>
<pre>
Global
        Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 8.8.8.8
        DNS Servers 44.32.32.2 44.60.44.3 44.32.32.1 8.8.8.8
        DNS Domain ampr.ari.it ~.


Link 2 (ens18)
Pericoloso ma fattibile sarebbe far loggare ad iptables il blocco UDP e far anallizare il log a fail2ban per procedere di conseguenza.
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
 
    Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 
    DNS Domain: DOMAINS
== 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>


Link 3 (wg_ampr_ari)
== Certificati SSL/TLS - TROVARE SOLUZIONE ==
Current Scopes: none
    Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
</pre>


== reverse proxy ==
Trovare soluzione per poter avere automatismi gratuiti di emissione/aggiornamento di certificati per SSL/TLS dei server nella rete 44 AMPR ARI
<pre>root@geu-ampr:/etc/caddy# cat Caddyfile
</pre>
<pre>
:80 {
    root * /var/www/default
    php_fastcgi unix//run/php/php-fpm.sock
    file_server
    encode zstd gzip
    log {
        output file /var/log/caddy/default.access.log
        format console
    }
}
</pre>


;Test risposte da:
; LetsEncrypt https://letsencrypt.org/docs/challenge-types/
* da internet su ip numerico http://193.70.17.196 '''OK'''
: * Metodo riconoscimento via WEB necessità il raggiungimento del ip 44 da LetsEncrypt/internet (HTTP-01 challenge)
* da internet su dominio http://vm.iw1geu.audric.it '''OK'''
: * Metodo riconoscimento via DNS necessità di un DNS aggiornabile via API (DNS-01 challenge)
* da AMPR ARI su ip numerico http://44.32.33.162 '''OK'''
* da AMPR ARI su dominio http://vm.iw1geu.ampr.ari.it '''OK'''
* da AMPR fuori ARI su ip numerico http://44.32.33.162 '''??? boh!? chi mi dice se funziona?'''

Versione attuale delle 12: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à

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)
Estratto da "https://wiki.ampr.ari.it/index.php?title=APPPUNTI_VM_internet_e_AMPRNET&oldid=329"