Configurazione VPN Linux: differenze tra le versioni

Da AMPR ARI.
Vai alla navigazione Vai alla ricerca
Nessun oggetto della modifica
Nessun oggetto della modifica
Riga 15: Riga 15:
PrivateKey = PRIVATEKEY1234567890PRIVATEKEY=
PrivateKey = PRIVATEKEY1234567890PRIVATEKEY=
Address = 44.32.32.255/21
Address = 44.32.32.255/21
'''#DNS = 44.32.32.2, 44.60.44.3'''
#DNS = 44.32.32.2, 44.60.44.3
[Peer]
[Peer]
PublicKey = PUBLICKEY1234567890PUBLICKEY=
PublicKey = PUBLICKEY1234567890PUBLICKEY=
Riga 21: Riga 21:
Endpoint = 5.144.187.34:12345
Endpoint = 5.144.187.34:12345
PresharedKey = PRESHAREDKEY1234567890</pre>
PresharedKey = PRESHAREDKEY1234567890</pre>
Si noti il commento alla riga DNS.


== Generazione dei certificati ==
== Generazione dei certificati ==
<code>cd /etc/wireguard<br>
echo PRIVATEKEY1234567890PRIVATEKEY= >private.key<br>
wg pubkey < private.key > pub.key<br>
echo PRESHAREDKEY1234567890 >preshared.key<br></code>


Comunemente, un router configurato con una interfaccia ad uso locale (con associato un indirizzamento IPv4 locale, per la propria LAN) avrà bisogno di una regola di NAT per poter mascherare gli indirizzi privati dietro l'endpoint pubblico afferente alla rete AMPR appena configurato, nel nostro caso vorremo che il solo accesso per la destinazione alla rete AMPR passi per la VPN, pertanto dovremo assicurarci che il traffico venga correttamente marcato a tale scopo e soprattutto che il traffico entrante nella interfaccia VPN (che ricordiamo essere a tutti gli effetti una interfaccia pubblica, da proteggere con opporture regole di firewall) torni indietro con il corretto mittente e attraverso la corretta interfaccia.
Comunemente, un router configurato con una interfaccia ad uso locale (con associato un indirizzamento IPv4 locale, per la propria LAN) avrà bisogno di una regola di NAT per poter mascherare gli indirizzi privati dietro l'endpoint pubblico afferente alla rete AMPR appena configurato, nel nostro caso vorremo che il solo accesso per la destinazione alla rete AMPR passi per la VPN, pertanto dovremo assicurarci che il traffico venga correttamente marcato a tale scopo e soprattutto che il traffico entrante nella interfaccia VPN (che ricordiamo essere a tutti gli effetti una interfaccia pubblica, da proteggere con opporture regole di firewall) torni indietro con il corretto mittente e attraverso la corretta interfaccia.

Versione delle 14:42, 22 mar 2024

La VPN di Accesso AMPR ARI

La VPN per l'accesso alla rete AMPR in subnet 44 (nella porzione di rete 44.32.32.0/21 a noi delegata) utilizza il protocollo WireGuard. In fase di attivazione viene consegnato all'utenza un file di configurazione in formato INI WireGuard: esso contiene tutte le informazioni necessarie alla configurazione della VPN per il client nativo che implementa le funzionalità ( https://www.wireguard.com ).

Preparazione del file di configurazione per Linux

L'installazione su OS Linux può presentare dei passaggi dipendenti dalla configurazione attuale della macchina, e richiede comunque una discreta padronanza dell' infrastruttura che si andrà ad integrare.

Il file INI fornito da ARI puo' essere utilizzato cosi' come e', con l'accortezza di rimuovere e commentare la riga gdi configurazione riguardante il DNS, inserendo il contenuto del file INI nel file /etc/wireguard/wg0.conf.

Ad esempio se avessimo ricevuto il seguente file (nell'esempio sono contenuti dati non reali, a solo scopo esemplificativo), il file di configurazione /etc/wireguard/wg0.conf risulterebbe simile a questo:

[Interface]
ListenPort = 51820
PrivateKey = PRIVATEKEY1234567890PRIVATEKEY=
Address = 44.32.32.255/21
#DNS = 44.32.32.2, 44.60.44.3
[Peer]
PublicKey = PUBLICKEY1234567890PUBLICKEY=
AllowedIPs = 44.0.0.0/9, 44.128.0.0/10
Endpoint = 5.144.187.34:12345
PresharedKey = PRESHAREDKEY1234567890

Si noti il commento alla riga DNS.

Generazione dei certificati

cd /etc/wireguard
echo PRIVATEKEY1234567890PRIVATEKEY= >private.key
wg pubkey < private.key > pub.key
echo PRESHAREDKEY1234567890 >preshared.key

Comunemente, un router configurato con una interfaccia ad uso locale (con associato un indirizzamento IPv4 locale, per la propria LAN) avrà bisogno di una regola di NAT per poter mascherare gli indirizzi privati dietro l'endpoint pubblico afferente alla rete AMPR appena configurato, nel nostro caso vorremo che il solo accesso per la destinazione alla rete AMPR passi per la VPN, pertanto dovremo assicurarci che il traffico venga correttamente marcato a tale scopo e soprattutto che il traffico entrante nella interfaccia VPN (che ricordiamo essere a tutti gli effetti una interfaccia pubblica, da proteggere con opporture regole di firewall) torni indietro con il corretto mittente e attraverso la corretta interfaccia.

Un esempio (non esaustivo, che ogni utente deve necessariamente completare ed adattare alla propria infrastruttura e topologia di rete) per la configurazione di uno scenario simile sarà il seguente;

1. Si definisce una address-list per le destinazioni dell'intero dominio AMPR:
/ip/firewall/address-list/add address=44.0.0.0/9 comment="AMPR Network #1" list=AMPR
/ip/firewall/address-list/add address=44.128.0.0/10 comment="AMPR Network #2" list=AMPR

2. Si definisce una Routing-Table dedicata e le corrispondenti regole di instradamento:
/routing/table/add disabled=no fib name=ARI-AMPR
/ip/route/add check-gateway=ping comment="AMPR" disabled=no distance=1 dst-address=44.0.0.0/9 gateway=44.32.32.1%wg_ampr_ari routing-table=ARI-AMPR scope=30 suppress-hw-offload=no
/ip/route/add check-gateway=ping comment="AMPR" disabled=no distance=1 dst-address=44.128.0.0/10 gateway=44.32.32.1%wg_ampr_ari routing-table=ARI-AMPR scope=30 suppress-hw-offload=no

3. Si definiscono le regole di mangle / packet-marking considerando la routing-table separata appena creata:
/ip/firewall/mangle/add action=mark-routing chain=prerouting src-address-list=!AMPR dst-address-list=AMPR new-routing-mark=ARI-AMPR passthrough=no
/ip/firewall/mangle/add action=mark-connection chain=input in-interface=wg_ampr_ari new-connection-mark=AMPR-CONNECTION passthrough=yes
/ip/firewall/mangle/add action=mark-connection chain=forward in-interface=wg_ampr_ari new-connection-mark=AMPR-CONNECTION passthrough=yes
/ip/firewall/mangle/add action=mark-routing chain=prerouting connection-mark=AMPR-CONNECTION in-interface=!wg_ampr_ari new-routing-mark=ARI-AMPR passthrough=no
/ip/firewall/mangle/add action=mark-routing chain=output connection-mark=AMPR-CONNECTION new-routing-mark=ARI-AMPR passthrough=no
Note importanti: La prima regola di mangle così definita nell' esempio è generica, si consiglia di ottimizzarla specificando come src-address il prefisso locale permesso per l' accesso alla rete AMPR (esempio 192.168.0.0/24) eliminando di conseguenza src-address-list=!AMPR.

4. Si definisce la regola di NAT (IP Masquerade) per la traslazione IP privato / pubblico dedicata alla sola destinazione AMPR:
/ip/firewall/nat/add action=masquerade chain=srcnat comment="AMPR VPN NAT" dst-address-list=AMPR out-interface=wg_ampr_ari
Note importanti: La regola di NAT così definita è generica, si consiglia di ottimizzarla specificando come src-address il prefisso locale permesso per l'accesso alla rete AMPR (esempio 192.168.0.0/24). Controllare l' ordine delle regole inserite, potrebbe essere necessario spostare la regola (più selettiva) appena creata in posizione di priorità rispetto ad altre già attive nel proprio router.

Se tutto ha funzionato correttamente (e se il contesto personale del router/firewall è stato modificato a dovere, adattando quanto necessario) la rete locale dovrebbe essere mascherata dietro l'indirizzo IP AMPR (appartenente alla 44.32.32.0/21) comunicato in fase di attiazione. Un semplice traceroute verso 44.32.32.1 dovrebbe confermare la configurazione mostrando l'IP raggiungibile ad un solo HOP di distanza.

Pubblicazione di un servizio su rete AMPR

In aggiunta, sarà anche possibile ora pubblicare un servizio (ad esempio un WebServer) accessibile dalla rete AMPR, semplicemente configurando un NA(P)T (nell'esempio seguente si utilizza l'IP AMPR configurato nell'esempio sopra, ovvero il 44.32.32.255 e l' IP privato del server 192.168.0.10 che risponde in porta 80/TCP:

/ip/firewall/nat add action=dst-nat chain=dstnat comment="AMPR WebServer NAT" dst-address=44.32.32.255 dst-port=80 in-interface=wg_ampr_ari protocol=tcp to-addresses=192.168.0.10 to-ports=80

Anche in questo caso sarà necessario adattare opportune regole di restrizione e/o packet-filtering in modo da garantire la sicurezza di accesso necessaria all'applicativo esposto.