↓ Skip to main content
u-random
u-random
  1. Lab-blue/

[TODO] Lab - VPN + DMZ con Windows Server interno

·5 mins
avanzato
Network-Defense Iam Security-Plus
Alessio Barnini
Author
Alessio Barnini
Table of Contents
[TODO] Lab - VPN + DMZ con Windows Server interno

Cosa fa
#

Trasforma Ubuntu in un VPN concentrator con due gambe: una sul lato "internet" (dove vive Kali) e una sul lato "interno" (dove vive Windows Server). Kali non può raggiungere Windows direttamente — deve passare per il tunnel WireGuard. Simula l'architettura DMZ reale.

TL;DR
#

Kali (192.168.64.200)       → lato internet (attaccante / utente remoto)
    │
    │  tunnel WireGuard UDP 51820
    │
Ubuntu (192.168.64.3)       → VPN concentrator in DMZ
    │  enp0s1  → lato internet
    │  enp0s2  → lato interno (nuova interfaccia)
    │
Windows Server (172.16.0.10) → server interno (AD DS / target)

Prerequisiti
#

  • [[[TODO] lab-windows-server-utm|lab-windows-server-utm]] completato — Windows Server 2022 installato su UTM con AD DS attivo
  • [[[DONE] lab-vpn-wireguard-tunnels|lab-vpn-wireguard-tunnels]] completato — WireGuard già noto, chiavi generate, concetti split/full tunnel chiari
  • Ubuntu con WireGuard installato (wg --version funziona)

Architettura di rete target
#

          Internet / rete host-only 1 (192.168.64.x)
          ┌─────────────────────────────┐
          │                             │
    Kali  │                        Ubuntu enp0s1
  192.168.64.200              192.168.64.3
          │
          │   tunnel WireGuard (10.0.0.0/24)
          │
          │                        Ubuntu enp0s2
                                   172.16.0.1
                                        │
                              rete interna (172.16.0.x)
                              ┌──────────────────────┐
                              │                      │
                        Windows Server
                         172.16.0.10
                          (AD DS / lab.local)

Ubuntu ha due interfacce:

  • enp0s1 — sulla rete host-only esistente (192.168.64.x), lato "internet"
  • enp0s2 — sulla nuova rete interna (172.16.0.x), lato "interno"

Kali non ha route verso 172.16.0.0/24 — può arrivarci solo via tunnel WireGuard, passando per Ubuntu.

Fase 1 — Aggiungere la seconda rete in UTM
#

  • Task 1.1 — Aggiungere un secondo adapter a Ubuntu in UTM

    • Spegni Ubuntu
    • In UTM → settings Ubuntu → Network → Add Network Interface
    • Tipo: Host Only — ma su una nuova rete separata dalla prima
    • Nota: UTM su Apple Silicon crea reti host-only distinte — assicurati che la seconda sia su un subnet diverso
    • Come sai che hai finito: Ubuntu avviato mostra enp0s2 in ip addr

  • Task 1.2 — Aggiungere Windows alla rete interna in UTM

    • In UTM → settings Windows Server → Network
    • Cambia la rete da quella esistente (192.168.64.x) alla nuova rete interna
    • Come sai che hai finito: Windows non ha più IP 192.168.64.x

  • Task 1.3 — Assegnare IP statico a Ubuntu su enp0s2

    • Su Ubuntu:
    sudo ip addr add 172.16.0.1/24 dev enp0s2
sudo ip link set enp0s2 up
    • Per renderlo persistente: aggiungi a /etc/netplan/ o /etc/network/interfaces
    • Come sai che hai finito: ip addr show enp0s2 mostra 172.16.0.1

  • Task 1.4 — Assegnare IP statico a Windows Server

    • Su Windows: Control Panel → Network → Ethernet → Properties → IPv4
    • IP: 172.16.0.10 — subnet mask 255.255.255.0 — gateway 172.16.0.1
    • Come sai che hai finito: ping 172.16.0.1 da Windows risponde (Ubuntu risponde)

Fase 2 — Configurare WireGuard su Ubuntu (concentrator)
#

  • Task 2.1 — Aggiornare /etc/wireguard/wg0.conf su Ubuntu

    Aggiungere la route verso la rete interna nell'interfaccia WireGuard:

    [Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <server_private>

[Peer]
PublicKey = <client_public>
AllowedIPs = 10.0.0.2/32

    Nota: la route verso 172.16.0.0/24 non va in wg0.conf — la gestisce il kernel con IP forwarding.

  • Task 2.2 — Abilitare IP forwarding su Ubuntu

    echo 1 > /proc/sys/net/ipv4/ip_forward

    Per renderlo persistente: in /etc/sysctl.conf → net.ipv4.ip_forward = 1

    • Come sai che hai finito: cat /proc/sys/net/ipv4/ip_forward restituisce 1

  • Task 2.3 — Aggiungere la route di forwarding

    ip route add 172.16.0.0/24 dev enp0s2
    • Come sai che hai finito: ip route mostra 172.16.0.0/24 dev enp0s2

Fase 3 — Configurare Kali (client VPN)
#

  • Task 3.1 — Aggiornare /etc/wireguard/wg0.conf su Kali

    Aggiungere la rete interna agli AllowedIPs — così Kali sa che 172.16.0.x si raggiunge via tunnel:

    [Interface]
Address = 10.0.0.2/24
PrivateKey = <client_private>

[Peer]
PublicKey = <server_public>
Endpoint = 192.168.64.3:51820
AllowedIPs = 10.0.0.0/24, 172.16.0.0/24

    AllowedIPs ora include sia la rete tunnel (10.0.0.x) che la rete interna (172.16.0.x). Kali instraderà automaticamente il traffico verso Windows nel tunnel.

  • Task 3.2 — Avviare il tunnel

    wg-quick up wg0
ip route
    • Come sai che hai finito: ip route mostra 172.16.0.0/24 dev wg0 — la rete interna è raggiungibile via tunnel

Fase 4 — Verifica: Kali raggiunge Windows via VPN
#

  • Task 4.1 — Ping da Kali a Windows

    ping 172.16.0.10
    • Come sai che hai finito: ping risponde — Kali raggiunge Windows passando per Ubuntu

  • Task 4.2 — Traceroute per vedere il percorso

    traceroute 172.16.0.10
    • Come sai che hai finito: primo hop 10.0.0.1 (Ubuntu concentrator), secondo hop 172.16.0.10 (Windows). Il traffico passa per il tunnel.

  • Task 4.3 — Verifica che Kali NON raggiunga Windows senza tunnel

    wg-quick down wg0
ping 172.16.0.10
    • Come sai che hai finito: ping fallisce — senza VPN, 172.16.0.x è irraggiungibile da Kali. La DMZ funziona.

  • Task 4.4 — tcpdump su Ubuntu: vedi il traffico cifrato e decifrato

    • Su Ubuntu, due terminali:
    # terminale 1 — lato internet (cifrato)
tcpdump -i enp0s1 udp port 51820

# terminale 2 — lato interno (in chiaro)
tcpdump -i enp0s2 icmp

    Da Kali: ping 172.16.0.10

    • Come sai che hai finito: enp0s1 mostra UDP cifrato; enp0s2 mostra ICMP in chiaro verso Windows. Ubuntu ha decifrato il traffico e lo ha inoltrato.

Fase 5 — Bonus: accesso RDP via VPN
#

  • Task 5.1 — Abilitare RDP su Windows Server

    • Control Panel → System → Remote Desktop → Enable
    • Windows Firewall → Allow Remote Desktop

  • Task 5.2 — Connessione RDP da Kali via tunnel

    rdesktop 172.16.0.10
# oppure
xfreerdp /v:172.16.0.10 /u:Administrator
    • Come sai che hai finito: desktop Windows appare su Kali — connessione RDP attraverso il tunnel WireGuard

Come sai che hai finito tutto
#

  1. ping 172.16.0.10 da Kali con tunnel up → risponde
  2. ping 172.16.0.10 da Kali con tunnel down → fallisce
  3. traceroute 172.16.0.10 mostra 10.0.0.1 come primo hop
  4. tcpdump su enp0s1 mostra UDP 51820 cifrato; su enp0s2 mostra ICMP in chiaro
  5. (bonus) RDP su 172.16.0.10 apre il desktop Windows

Collegato a
#

  • [[[DONE] lab-vpn-wireguard-tunnels|lab-vpn-wireguard-tunnels]] — prerequisito: split/full tunnel, chiavi WireGuard
  • [[[TODO] lab-windows-server-utm|lab-windows-server-utm]] — prerequisito: Windows Server 2022 installato con AD DS
  • [[[TODO] lab-active-directory-sso-kerberos|lab-active-directory-sso-kerberos]] — estensione naturale: Kali che fa query LDAP/Kerberos via VPN
  • cap-04-securing-your-network — teoria VPN concentrator, DMZ, screened subnet

Related