zumindest für den Anfang…
ein Netzwerk aus 3 OpenBSD Routern auf APU4b4’s. Einer als Verbindung in die Welt für die beiden anderen und den Desktops (repräsentiert durch je eine Raspberry Pi 3) dahinter.
Was der Sinn sein soll? Lernen … wie funktioniert pf, wie funktioniert routing über mehrer router hinweg, … tunnel und so weiter. Und natürlich das Niederschreiben was man getan hat um es ggf. reproduzieren zu können. Es gibt nur wenige Anleitungen auf deutsch zu diesem Thema.
Gut einen der im letzten Artikel erwähnten Switche konnte ich schon weg rationalisieren… der hatte die Router mit Internet versorgt, solange ich nicht verstanden hatte, wie NAT bei OpenBSD funktioniert und noch ein paar Routen falsch waren… back to stock.
Im Grunde alles was ich gemacht habe benötigt root Rechte. Deshalb hab ich mich erst einmal zum root gemacht doas su -. Jeder sollte wissen was, was bedeutet.
Das erste was man auf allen OpenBSD Rechnern die routen sollen benötigt ist der sysctl Eintrag net.inet.ip.forwarding=1 standardmässig steht dieser auf 0 also nicht forwarden.
Um es sofort und permanent zu machen benötigt man 2 Zeile:
sysctl net.inet.ip.forwarding=1 echo "net.inet.ip.forwarding=1" >> /etc/sysctl.conf
Das Routing funktioniert sehr einfach mit route add
Um sie Permanent zu machen kommen die Routen in die /etc/hostname.
Ich habe, der Einheitlichkeit halber am ersten Netzwerk-Anschluss grundsätzlich die Kabel für das Interne Netzwerk 172.16.71.0/24.
Am zweiten die, so fern vorhanden, verbundenen Netze. Bei puffy-lab-2 das Netz 172.16.65.0/24. Und bei puffy-lab-3 das Netz 172.16.79.0/24. Ja die Zahl im dritte Oktett hat eine Bedeutung, ist aber für andere irrelevant.
Und am vierten der Weg zu meinem Hauptnetz mit dem Gateway zum ISP. Da das in nächster Zeit mal auf eine andere IP umgezogen wird (damit ein geplantes Routing via IPSec oder SSH Tunnel VPN sich nicht ins Gehege kommt) nennen wir hier einfach mal 192.168.178.0/24
puffy-lab-1# cat /etc/hostname.em0 inet 172.16.71.1 255.255.255.0 !route add 172.16.65.0/24 172.16.71.2 >/dev/null 2>&1 !route add 172.16.79.0/24 172.16.71.3 >/dev/null 2>&1 puffy-lab-1# cat /etc/hostname.em3 inet 192.168.178.2 255.255.255.0 192.168.178.255 !route add default 192.168.178.1 >/dev/null 2>&1
puffy-lab-2# cat /etc/hostname.em0 inet 172.16.71.2 255.255.255.0 172.16.71.255 !route add default 172.16.71.1 >/dev/null 2>&1 puffy-lab-2# cat /etc/hostname.em1 inet 172.16.65.1 255.255.255.0 172.16.65.255
puffy-lab-3# cat /etc/hostname.em0 inet 172.16.71.3 255.255.255.0 172.16.71.255 !route add default 172.16.71.1 >/dev/null 2>&1 puffy-lab-3# cat /etc/hostname.em1 inet 172.16.79.1 255.255.255.0 172.16.79.255
Lässt man >/dev/null 2>&1 weg, werden bei jedem sh /etc/netstart die Routen angezeigt. Kann beim Debugging hilfreich sein… sonst eher nervig.
Da das jetzt nur die einfachste Form eines NAT Netzwerkes ist, lass ich die anderen /etc/pf.conf einfach weg. Die funktionierten auch ohne Änderungen.
puffy-lab-1# cat /etc/pf.conf # $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
set skip on lo
###block return # block stateless traffic
###pass # establish keep-state
# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010
# Port build user does not need network
block return out log proto {tcp udp} user _pbuild
extif = "em3"
extip = "192.168.178.2"
intnet = "{ 172.16.65.0/24 172.16.71.0/24 172.16.79.0/24 }"
pass out on $extif from $intnet to any nat-to $extip
Man sieht vielleicht, das ich im Grunde nur die unteren 5 Zeilen in der Standard /etc/pf.conf angehängt, und 2 Einträge mit triple-sharp ### auskommentiert habe.
Überprüfung mit pfctl -nf /etc/pf.conf und einbinden mit pfctl -f /etc/pf.conf funktionierten problemlos
Ohne NAT sind eine paar unangenehme Seiteneffekte zu spüren. Wie etwa das sich ein route show und route -F #auf raspbian tot läuft. Auch lässt sich der ISP Router nicht erreichen.
Sobald NAT funktioniert sollte auf den Raspberry Pi’s das WLAN zum ISP Router abgeschaltet werden… sonst fliegt man häufiger mal von den Rechnern, weil die mit den 2 Wegen nicht wirklich umgehen können, wenn man versucht sie aus dem ISP Netzwerk zu Steuern. So hat mir z.B. Ansible diese Warnungen ausgestossen
[WARNING]: sftp transfer mechanism failed on [172.16.65.100]. Use ANSIBLE_DEBUG=1 to see detailed information
[WARNING]: scp transfer mechanism failed on [172.16.65.100]. Use ANSIBLE_DEBUG=1 to see detailed information
raspi-lab-1 | UNREACHABLE! => {
"changed": false,
"msg": "SSH Error: data could not be sent to remote host \"172.16.65.100\". Make sure this host can be reached over ssh",
"unreachable": true
}
Als ich einfach nur ein ansible -i hosts -m setup all ausführen wollte, während auf raspi-lab-1 WLAN im Netz 192.168.178.0/24 eingewählt war, und die Control Machine ebenso.
Nach abschalte des WLAN auf raspi-lab-1, funktionierte das Modul setup anstandslos.