APPPUNTI VM internet e AMPRNET: differenze tra le versioni

Da AMPR ARI.
Vai alla navigazione Vai alla ricerca
(Creata pagina con " = Appunti di viaggio per gli addetti ai lavori = == 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. Pacchetti base installalti: iptables ipset wireguard ssh caddy == interfacce == <pre>root@geu-ampr:/etc/network# cat interfaces </pre> <pre>source /etc/network/interfaces.d/* auto lo iface lo inet loopback allow-hotplug eth0 iface eth0...")
 
 
(40 versioni intermedie di uno stesso utente non sono mostrate)
Riga 1: Riga 1:


= Appunti di viaggio per gli addetti ai lavori =
= Appunti di viaggio per gli addetti ai lavori =
''' WORK IN PROGRESS - DA TESTARE '''


== Vm di base ==
== Vm di base ==
Questa è una VM debian minimal su OVH che ha una configurazione di rete MOLTO particolare.
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.


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 ipset 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 23: Riga 27:
     pre-down ip route del 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
     pre-down ip route del            gw.in.ter.net dev eth0
    dns-nameservers 8.8.8.8
</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 45: 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
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
 
</pre>
</pre>


<pre>root@geu-ampr:/etc/wireguard# cat wg_ampr_ari0-up.sh
'''Abilitazione del servizio per l'avvio automatico:'''
<pre>
systemctl enable wg-quick@wg_ampr_ari0.service
systemctl start wg-quick@wg_ampr_ari0
</pre>
</pre>
<pre>#!/bin/bash


ip route del 44.0.0.0/9    via 44.32.32.1 >/dev/null ||true
== Test instradamento - OK ==
ip route del 44.128.0.0/10 via 44.32.32.1 >/dev/null ||true
 
ip route add 44.0.0.0/9    via 44.32.32.1
Test delle rotte '''OK'''
ip route add 44.128.0.0/10 via 44.32.32.1
 
<pre>
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
</pre>


ip route del 44.0.0.0/9    via 44.32.32.1 dev wg_ampr_ari0 table r_AMPR >/dev/null |true
Test instradamento verso internet '''OK'''
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>
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
</pre>
</pre>


== firewall ==
Test instradamento verso AMPR ARI '''OK'''
 
<pre>
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
</pre>
 
Test instradamento verso AMPR fuori da AMR ARI '''OK'''
 
<pre>
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 *
</pre>
 
== 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.'''
 
<pre>root@geu-ampr:/etc/iptables# cat rules.v4  
<pre>root@geu-ampr:/etc/iptables# cat rules.v4  
</pre>
</pre>
Riga 82: Riga 138:
-A INPUT -i lo -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m udp --dport 51820 -j ACCEPT -m comment --comment "WireGuard"
-A INPUT -p udp -m udp --dport 51820 -j ACCEPT -m comment --comment "WireGuard"
-A INPUT -p icmp -m icmp -s 44.0.0.0/9 -j ACCEPT -m comment --comment "AMPR"
-A INPUT -p icmp --icmp-type destination-unreachable/source-quench              -j ACCEPT -m comment --comment "PMTU Discovery"
-A INPUT -p icmp -m icmp -s 44.128.0.0/10 -j ACCEPT -m comment --comment "AMPR"
-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 tcp -m tcp --dport 80 -j ACCEPT
-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 tcp -m tcp --dport 443 -j ACCEPT
-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
-A INPUT -s ip.qth -m comment --comment "Casa" -j ACCEPT
COMMIT
COMMIT
Riga 92: Riga 150:
</pre>
</pre>


== NS resolver selettivo ==
Migliorie:
Resolver di default e resolver specifico per dominio e sottodomini di ampr.ari.it
* aggiungere un drop dei bogons in ingresso
<pre>root@geu-ampr:/etc/systemd/resolved.conf.d# cat ampr.ari.it.conf
* specificare l'interfaccia
 
'''Attivazione/ripristino delle regole di firewall'''
<pre>
iptables-restore </etc/iptables/rules.v4
</pre>
</pre>
'''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.
<pre>
<pre>
[Resolve]
iptables-save >/etc/iptables/rules.v4
Domains=ampr.ari.it
DNS=44.32.32.2 44.60.44.3 44.32.32.1
</pre>
</pre>


<pre>root@geu-ampr:/etc/systemd/resolved.conf.d# cat dns_servers.conf
== 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.
<pre>
# 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
 
</pre>
</pre>
Influenzare un pochino la banda in ingresso sarebbe possibili tramite ifb. Non sa quanto sia efficace. Da provare...
<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>


== reverse proxy ==
E' possibile anche limitare il numero di pacchetti UDP in ingresso tramite iptables ma questo potrebbe danneggiare traffico legittimo e bisognerà creare eccezzioni.
<pre>root@geu-ampr:/etc/caddy# cat Caddyfile
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>
<pre>
vm.iw1geu.ampr.ari.it:80 {
iptables -A INPUT -p udp -m limit --limit 10/sec --limit-burst 20 -j ACCEPT
root * /var/www/vm.iw1geu.ampr.ari.it
iptables -A INPUT -p udp -j DROP
file_server
}
my.ip.ampr.net:80 {
root * /var/www/my.ip.ampr.net
file_server
}
ip.in.ter.net:80 {
root * /var/www/ip.in.ter.net
file_server
}
:80 {
respond "Makkè quarzo vuoi!??"
}
</pre>
</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 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)

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"