Routing między dwiema sieciami

Laboratorium rozwija Lab 01 i Lab 02: najpierw była komunikacja w jednej sieci, potem DHCP, a teraz ruch przechodzi między dwiema różnymi podsieciami przez router Debian. Teorię routingu możesz zestawić z materiałem Routing.

• odróżnić sieć lokalną od sieci zdalnej.
• skonfigurować Debiana jako router IPv4 z dwiema kartami.
• ustawić default gateway na hostach końcowych.
• sprawdzić connected routes i tablice routingu.
• włączyć IPv4 forwarding w Linux.
• przetestować przejście pakietu przez router.
• zdiagnozować błędy gateway, masek, nazw Internal Network i firewall.

Na każdej z trzech VM zapisz interfejsy, adresy, wszystkie trasy oraz używaną konfigurację sieci. Na routerze zapisz dodatkowo bieżącą wartość net.ipv4.ip_forward i stan pliku, który laboratorium później utworzy.

STATE="$HOME/lab03-state"
umask 077
mkdir -p "$STATE"
ip -br link > "$STATE/link.before"
ip -br address > "$STATE/address.before"
ip route show table all > "$STATE/routes.before"

if sudo test -e /etc/network/interfaces; then
  printf 'present
' > "$STATE/interfaces.marker"
  sudo cp -a /etc/network/interfaces "$STATE/interfaces.before"
else
  printf 'absent
' > "$STATE/interfaces.marker"
fi

# Tylko na routerze
sysctl -n net.ipv4.ip_forward > "$STATE/ip-forward.before"
if sudo test -e /etc/sysctl.d/99-lab-routing.conf; then
  printf 'present
' > "$STATE/sysctl-file.marker"
  sudo cp -a /etc/sysctl.d/99-lab-routing.conf "$STATE/99-lab-routing.conf.before"
else
  printf 'absent
' > "$STATE/sysctl-file.marker"
fi

Przy wyłączonych VM zapisz na hoście tryb, nazwę sieci i stan kabla każdego adaptera VirtualBox. Oczekiwany rezultat to osobny katalog stanu na Client A, Routerze i Client B oraz zapis obu segmentów VirtualBox. Snapshot jest tylko dodatkowym punktem powrotu, nie backupem.

Używasz trzech maszyn Debian Stable. Client A znajduje się w sieci 192.168.80.0/24, Client B w sieci 192.168.90.0/24, a router ma po jednym interfejsie w każdej z nich.

Client A: 192.168.80.10/24
        |
Internal Network: lab-route-a
        |
Router Debian:
  NIC1: 192.168.80.1/24
  NIC2: 192.168.90.1/24
        |
Internal Network: lab-route-b
        |
Client B: 192.168.90.10/24

Wyłącz maszyny i ustaw adaptery VirtualBox. Client A oraz pierwsza karta routera muszą używać nazwy lab-route-a. Client B oraz druga karta routera muszą używać nazwy lab-route-b.

Client A  Adapter 1 -> Internal Network: lab-route-a
Router    Adapter 1 -> Internal Network: lab-route-a
Router    Adapter 2 -> Internal Network: lab-route-b
Client B  Adapter 1 -> Internal Network: lab-route-b

Literówka, na przykład lab-route-b kontra lab-rout-b, oznacza dwa różne segmenty warstwy 2. Sama poprawna adresacja IP wtedy nie wystarczy.

Nie zakładaj nazw eth0 i eth1. Współczesny Debian może używać nazw takich jak enp0s3i enp0s8. W przykładach przyjmujemy enp0s3 dla lab-route-a oraz enp0s8 dla lab-route-b, ale najpierw ustal rzeczywiste nazwy kart.

ip link show
ip address show

Adresacja jest przykładowa i nie nakłada się: sieć A to 192.168.80.0/24, sieć B to 192.168.90.0/24. Przypomnij sobie podstawy w materiałach Adresacja IPv4 oraz Maski podsieci.

Konfiguracja poleceniami ip jest konfiguracją runtime i może zniknąć po restarcie. Zastąp enp0s3 nazwą interfejsu odczytaną ze swojego systemu.

# UWAGA: flush usuwa całą bieżącą adresację IPv4 z tego interfejsu.
sudo ip addr flush dev enp0s3
sudo ip addr add 192.168.80.10/24 dev enp0s3
sudo ip link set enp0s3 up
sudo ip route replace default via 192.168.80.1

ip address show
ip route show

Oczekujesz adresu 192.168.80.10/24, trasy connected do 192.168.80.0/24 oraz default route przez 192.168.80.1.

Client B jest analogiczny, ale należy do drugiej podsieci i używa drugiego interfejsu routera jako bramy domyślnej.

# UWAGA: flush usuwa całą bieżącą adresację IPv4 z tego interfejsu.
sudo ip addr flush dev enp0s3
sudo ip addr add 192.168.90.10/24 dev enp0s3
sudo ip link set enp0s3 up
sudo ip route replace default via 192.168.90.1

ip address show
ip route show

Oczekujesz adresu 192.168.90.10/24, trasy connected do 192.168.90.0/24 oraz default route przez 192.168.90.1.

Router dostaje dwa adresy: 192.168.80.1/24 po stronie Client A oraz 192.168.90.1/24 po stronie Client B. Dla samej komunikacji między tymi sieciami router nie potrzebuje default route ani NAT.

# UWAGA: flush usuwa całą bieżącą adresację IPv4 ze wskazanych interfejsów.
sudo ip addr flush dev enp0s3
sudo ip addr flush dev enp0s8

sudo ip addr add 192.168.80.1/24 dev enp0s3
sudo ip addr add 192.168.90.1/24 dev enp0s8

sudo ip link set enp0s3 up
sudo ip link set enp0s8 up

ip address show
ip route show

W tablicy routingu routera powinny pojawić się dwie trasy connected: 192.168.80.0/24 i 192.168.90.0/24.

Najpierw nie włączaj IP forwarding. Client A powinien osiągnąć swój lokalny interfejs routera, a Client B swój. Pełna komunikacja Client A do Client B nie powinna działać, jeśli forwarding jest wyłączony.

# UWAGA: poniższe delete usuwają wyłącznie wskazane trasy i adresy runtime.
# Client A
ping -c 4 192.168.80.1
ping -c 4 192.168.90.10

# Client B
ping -c 4 192.168.90.1

Router posiada obie sieci lokalnie, ale Linux nie routuje pakietów IPv4 między interfejsami, gdy net.ipv4.ip_forward ma wartość 0.

Na routerze sprawdź bieżący stan forwarding, a następnie włącz go dla IPv4. Wartość 1 pozwala kernelowi przekazywać pakiety, o ile adresacja, routing i firewall na to pozwalają.

sysctl net.ipv4.ip_forward
cat /proc/sys/net/ipv4/ip_forward

sudo sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Opcjonalnie możesz utrwalić ustawienie w pliku /etc/sysctl.d/99-lab-routing.conf.

echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/99-lab-routing.conf
sudo sysctl --system

Client A traktuje 192.168.90.10 jako cel zdalny i wysyła pakiet do 192.168.80.1. Client B traktuje192.168.80.10 jako cel zdalny i wysyła pakiet do192.168.90.1. Router ma obie podsieci directly connected.

# Client A
ip route show

# Router
ip route show

# Client B
ip route show

Routing musi działać także w kierunku powrotnym. Jeżeli host po drugiej stronie nie ma poprawnej trasy powrotnej, odpowiedź nie wróci do nadawcy.

Po włączeniu forwarding sprawdź pełną komunikację między podsieciami. To nadal nie jest NAT i nie zapewnia Internetu.

# Client A -> Client B
ping -c 4 192.168.90.10

# Client B -> Client A
ping -c 4 192.168.80.10

Client A może także testować 192.168.80.1 jako lokalny interfejs routera oraz 192.168.90.1 jako drugi interfejs routera osiągany przez routing.

Polecenie ip route get jest bardzo praktyczne, bo pokazuje, jak system wybrał trasę dla konkretnego celu.

# Client A
ip route get 192.168.90.10
# oczekiwany sens: via 192.168.80.1

# Client B
ip route get 192.168.80.10
# oczekiwany sens: via 192.168.90.1

# Router
ip route get 192.168.90.10
# oczekiwany sens: bezpośrednio przez interfejs do lab-route-b

Jeśli tracepath albo traceroute są już dostępne, możesz ich użyć, ale nie są wymagane w minimalnym Debianie. Nie instaluj pakietów z Internetu w tym laboratorium.

tracepath 192.168.90.10
traceroute 192.168.90.10

1. Czy interfejs jest UP?
2. Czy VM jest w poprawnej Internal Network?
3. Czy adres IP i prefix są poprawne?
4. Czy klient osiąga swój gateway?
5. Czy default route wskazuje właściwy gateway?
6. Czy router posiada oba adresy?
7. Czy router ma obie trasy connected?
8. Czy net.ipv4.ip_forward = 1?
9. Czy firewall nie blokuje FORWARD?
10. Czy host po drugiej stronie ma poprawną trasę powrotną?

Jeśli dostępne, sudo nft list ruleset może pomóc w sprawdzeniu nftables. Nie zaczynaj diagnostyki od wyłączania firewalla. Więcej narzędzi znajdziesz w materiale Diagnostyka sieci.

Client A nie potrzebuje adresu MAC Client B. Dla celu zdalnego192.168.90.10 potrzebuje MAC swojego next hop, czyli192.168.80.1. Router dopiero na drugim interfejsie rozwiązuje MAC Client B. Do obserwacji sąsiadów użyj:

ip neigh show

Szersze wyjaśnienie znajdziesz w materiale ARP/ICMP.

Główny scenariusz używa poleceń ip, aby nie wiązać ćwiczenia z konkretnym managerem sieci. Po restarcie taka konfiguracja może zniknąć. Dopiero po zrozumieniu topologii warto przepisać ją do mechanizmu używanego w danym systemie, na przykład NetworkManager, systemd-networkd albo /etc/network/interfaces.

1. Wyjaśnij, dlaczego Client A nie wysyła bezpośrednio ramki do MAC Client B.
2. Usuń default gateway na Client A i sprawdź, które testy nadal działają.
3. Ustaw net.ipv4.ip_forward=0 na routerze i opisz objaw.
4. Wyjaśnij, dlaczego router nie potrzebuje statycznej trasy do 192.168.90.0/24.
5. Uruchom ip route get 192.168.90.10 na Client A i wskaż next hop.
6. Zmień maskę Client A na /16 i wyjaśnij, dlaczego to psuje logikę routingu.
7. Wprowadź literówkę w nazwie lab-route-b i znajdź pierwszy niedziałający etap.
8. Udowodnij komendami, że routing działa bez NAT.

Jeżeli przechodzisz bezpośrednio do Lab 04, pozostaw działający routing z Lab 03 i zachowaj katalogi lab03-state: Lab 04 jawnie rozwija tę topologię. Jeżeli kończysz ćwiczenia lub chcesz odtworzyć stan sprzed Lab 03, wykonaj pełną procedurę z lokalnej konsoli VirtualBox, nie przez SSH.

Na klientach usuń wyłącznie bramy i adresy dodane w Lab 03. Na routerze usuń wyłącznie dwa adresy laboratoryjne. Następnie na każdej VM przywróć jej własny plik konfiguracji sieci i przeładuj ifupdown.

# Client A
sudo ip route delete default via 192.168.80.1 2>/dev/null || true
sudo ip address delete 192.168.80.10/24 dev enp0s3 2>/dev/null || true

# Client B
sudo ip route delete default via 192.168.90.1 2>/dev/null || true
sudo ip address delete 192.168.90.10/24 dev enp0s3 2>/dev/null || true

# Router
sudo ip address delete 192.168.80.1/24 dev enp0s3 2>/dev/null || true
sudo ip address delete 192.168.90.1/24 dev enp0s8 2>/dev/null || true

# Na każdej VM
STATE="$HOME/lab03-state"
if grep -qx present "$STATE/interfaces.marker"; then
  sudo cp -a "$STATE/interfaces.before" /etc/network/interfaces
else
  # UWAGA: usuń plik tylko wtedy, gdy marker potwierdza jego wcześniejszy brak.
  sudo rm -- /etc/network/interfaces
fi
sudo systemctl restart networking

Na routerze odtwórz obecność i zawartość wyłącznie pliku 99-lab-routing.conf, a potem dokładną wartość runtime zapisaną przed ćwiczeniem. Nie ustawiaj bezwarunkowoip_forward=0.

STATE="$HOME/lab03-state"
if grep -qx present "$STATE/sysctl-file.marker"; then
  sudo cp -a "$STATE/99-lab-routing.conf.before" /etc/sysctl.d/99-lab-routing.conf
else
  # UWAGA: usuń plik tylko wtedy, gdy marker potwierdza jego wcześniejszy brak.
  sudo rm -- /etc/sysctl.d/99-lab-routing.conf
fi

sudo sysctl --system
sudo sysctl -w net.ipv4.ip_forward="$(cat "$STATE/ip-forward.before")"
sysctl net.ipv4.ip_forward
ip -br address
ip route show table all

Wyłącz VM i przywróć zapisane ustawienia kart VirtualBox. Na wszystkich maszynach porównaj adresy i trasy z plikami*.before. Test końcowy ma odpowiadać stanowi początkowemu: nie oczekuj automatycznie ani obecności, ani braku routingu. Procedura nie usuwa cudzych tras, innych plików sysctl, reguł firewalla ani maszyn wirtualnych.

Kontynuuję Lab 04: pomiń pełne sprzątanie, zachowaj działające dwa LAN-y i zapis stanu. Kończę ćwiczenia: wykonaj pełny rollback i usuń katalogi stanu dopiero po zgodnej walidacji.

• Linux Kernel — IPv4 ip_forward
• Debian Manpages — ip-route(8)
• Oracle VirtualBox — Virtual Networking