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

[DONE] Lab - WireGuard VPN: Split Tunnel vs Full Tunnel

·4 mins
base
Network-Defense Security-Plus
Alessio Barnini
Author
Alessio Barnini
Table of Contents
[DONE] Lab - WireGuard VPN: Split Tunnel vs Full Tunnel

Cosa fa
#

Configura un tunnel WireGuard tra Ubuntu (VPN concentrator) e Kali (client remoto). Dimostra la differenza tra split tunnel e full tunnel osservando le routing table di Kali e catturando il traffico cifrato su Ubuntu.

TL;DR
#

Ubuntu (192.168.64.3)   → VPN concentrator (wg0: 10.0.0.1/24)
Kali   (192.168.64.200) → VPN client       (wg0: 10.0.0.2/24)
Mac    (192.168.64.1)   → gateway host-only

WireGuard è il VPN protocol che "scegli quando puoi scegliere" — non usa IPsec/AH/ESP ma UDP 51820. Perfetto per capire split vs full tunnel. Per IPsec specifico → [[[DONE] lab-ipsec-strongswan|lab-ipsec-strongswan]].

Obiettivo finale
#

Come sai che hai finito tutto:

  • Split tunnel: ip route su Kali mostra solo 10.0.0.0/24 via wg0; traceroute 8.8.8.8 da Kali NON passa per Ubuntu
  • Full tunnel: ip route su Kali mostra 0.0.0.0/0 via wg0; traceroute 8.8.8.8 da Kali passa per Ubuntu (192.168.64.3)

Fase 1 — Setup WireGuard
#

  • Task 1 — Installa WireGuard su Ubuntu e Kali

    • apt install wireguard su entrambe
    • Come sai che hai finito: wg --version funziona su entrambe le VM

  • Task 2 — Genera le coppie di chiavi

    • Su Ubuntu: genera privatekey + publickey per il server
    • Su Kali: genera privatekey + publickey per il client
    • Come sai che hai finito: hai 4 file: server_private, server_public, client_private, client_public

  • Task 3 — Configura il server (Ubuntu)

    • Crea /etc/wireguard/wg0.conf con Address = 10.0.0.1/24, ListenPort = 51820, PrivateKey = [server_private]
    • Aggiungi il peer Kali con PublicKey = [client_public], AllowedIPs = 10.0.0.2/32
    • Come sai che hai finito: wg-quick up wg0 parte senza errori; ip addr show wg0 mostra 10.0.0.1

  • Task 4 — Configura il client (Kali)

    • Crea /etc/wireguard/wg0.conf con Address = 10.0.0.2/24, PrivateKey = [client_private]
    • Peer Ubuntu: PublicKey = [server_public], Endpoint = 192.168.64.3:51820
    • Per ora: AllowedIPs = 10.0.0.0/24 (split tunnel — solo la LAN interna)
    • Come sai che hai finito: wg-quick up wg0 su Kali; ping 10.0.0.1 funziona

Fase 2 — Split Tunnel
#

  • Task 5 — Verifica le route con split tunnel

    • Su Kali: ip route dopo aver avviato il tunnel
    • Come sai che hai finito: vedi 10.0.0.0/24 dev wg0 ma default via 192.168.64.1 rimane — il traffico verso internet NON passa per il tunnel

  • Task 6 — Dimostra che il traffico internet bypassa il tunnel

    • traceroute 8.8.8.8 da Kali
    • Come sai che hai finito: il primo hop è 192.168.64.1 (Mac gateway), non Ubuntu — la ricerca Google di Lisa va dritta a internet

  • Task 7 — Cattura il traffico tunnel su Ubuntu

    • Su Ubuntu: tcpdump -i eth0 udp port 51820 mentre pinghi da Kali verso 10.0.0.1
    • Come sai che hai finito: vedi pacchetti UDP tra 192.168.64.200 e 192.168.64.3 — il payload è cifrato, non si vede nulla dentro

Fase 3 — Full Tunnel
#

  • Task 8 — Modifica il client per full tunnel

    • Su Kali: in /etc/wireguard/wg0.conf cambia AllowedIPs = 0.0.0.0/0, ::/0
    • Su Ubuntu: abilita IP forwarding (echo 1 > /proc/sys/net/ipv4/ip_forward) + regola NAT (iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE)
    • Come sai che hai finito: dopo wg-quick down wg0 && wg-quick up wg0 su Kali, ip route mostra default via 10.0.0.1

  • Task 9 — Verifica che TUTTO il traffico passi per Ubuntu

    • traceroute 8.8.8.8 da Kali
    • Come sai che hai finito: il primo hop è 10.0.0.1 (Ubuntu) — la ricerca Google di Lisa passa per il VPN server aziendale

  • Task 10 — Confronta le due modalità

    • Ripeti traceroute 8.8.8.8 sia in split che in full tunnel
    • Come sai che hai finito: output diverso tra le due modalità — documenta la differenza in un commento nel config file

Fase 4 — Cattura e analisi avanzata
#

  • Task 11 — Confronta traffico cifrato vs decifrato

    • Su Ubuntu: tcpdump -i wg0 (interfaccia tunnel, decifrata) — vedi il traffico interno
    • Su Ubuntu: tcpdump -i eth0 udp port 51820 (interfaccia fisica) — vedi solo UDP cifrato
    • Come sai che hai finito: su wg0 vedi ICMP; su eth0 vedi solo UDP opaco con dimensioni diverse

  • Task 12 — Misura l'overhead del tunnel

    • Confronta la dimensione di un ping normale su eth0 vs un ping tunnelato su eth0 in full tunnel
    • Come sai che hai finito: il ping tunnelato è più grande del ping diretto — questo è l'overhead IPsec/WireGuard

Domande di verifica Security+
#

  1. In split tunnel, Lisa cerca "saxophones" su Google. Il traffico passa per il VPN server aziendale? Spiega.
  2. In full tunnel, quale IP vede Google quando Lisa fa la ricerca? L'IP di casa di Lisa o l'IP aziendale?
  3. Perché un amministratore di sicurezza preferisce il full tunnel anche se è più lento?
  4. Il VPN concentrator è Ubuntu in questo lab. Cosa farebbe un hardware dedicato (Cisco ASA) di diverso/migliore?
  5. WireGuard usa UDP 51820. IPsec usa IP protocol 50/51 + UDP 500. Qual è il vantaggio di WireGuard in ambienti con NAT?

Collegato a
#

  • [[[DONE] lab-ipsec-strongswan|lab-ipsec-strongswan]] — variante con IPsec reale (ESP, AH, IKE, tunnel vs transport mode)
  • [[[TODO] lab-freeradius-samba|lab-freeradius-samba]] — autenticazione RADIUS che precede l'apertura del tunnel
  • cap-04-securing-your-network — teoria split/full tunnel, concentrator, IPsec
  • mustache-project — WireGuard potrebbe diventare l'accesso admin sicuro al lab

Related