Tach!

 

Wie hier angedroht schreibe ich etwas über eines meiner Lieblingsspielzeuge – VyOS!

Bis vor ein paar Jahren gab es Vyatta als Software Router auf Debian basierend als „freemium“ Modell. Der Hersteller wurde 2012 aufgekauft und die freie Version vom Markt genommen.

Einige Entwickler haben das Thema weiterverfolgt und die Software wird unter GPL offen als VyOS weiterentwickelt.

 

VyOS läuft auf so ziemlich allem was in irgendeiner Art und Weise x86 kompatibel ist und natürlich als VM auf so ziemliche jedem Hypervisor.

Die benötigten Ressourcen tendieren gegen Null!

 

VyOS ist nicht nur ein kostenloser Einstieg in "network feature virtualization" sondern auch ein hervorragendes Labdevice.

Unterstützt OSPF und BGP durch Quagga, bringt einen ISC kompatiblen DHCP, eine zonen-basierende Firewall und ein nettes CLI sowie Netflow.

Die Dokumentation ist klasse, setzt jedoch voraus, dass man sich mit der Materie auskennt und schon einmal mit der CLI der Jungs in Grün oder Blau gearbeitet hat.

Davon gehe ich hier einmal aus und halte mich nicht länger mit Basics auf.

 

Setzen wir einmal eine kleine VM auf; das erste Interface geht nach draussen (eth0), das zweite ist innen (eth1):

01.png

 

ISO einwerfen und auf geht’s.

Die Installation ist so simpel. Das System bootet (Zugang: vyos/vyos) und wir tippen „install image

02.png

 

Dann folgen wir den Schritten die vorgeschlagen werden und müssen nur einmal aufpassen, wenn das System uns fragt ob wir wirklich die Disk formatieren möchten.

Wenn es nur immer so einfach wäre…“Möchtest du wirklich die Erinnerungen an die letzte Party löschen?“…

 

Wenn der Prozess beendet ist einmal bitte „reboot“, dann mit dem neuen Passwort einloggen.
Konfigurieren in der VM Konsole ist aber unkomfortabel; wir brauchen SSH also „configure“ und  „set service ssh allow-root“.

Natürlich brauchen wir auch eine IP auf zumindest einem Interface mit „set interfaces ethernet eth1 address 10.0.0.12/24“ in meinem Fall.

Nach erfolgreichem Senden ein „commit“ (woher kenne ich das nur) und „save“.

03.png

 

Zum Ansehen der Konfiguration einfach ein „show config“ oder aber „show config commands

Ein paar Standards, recht selbsterklärend:

 

set service lldp
set service snmp community private authorization rw
set service snmp community public authorization ro
set service snmp contact administrator@galaxy.local
set service snmp description VYOS
set service snmp location VIRTUAL
set system domain-name GALAXY.LOCAL
set system host-name VYOS
set system name-server 10.0.5.10
set system ntp server 10.0.6.4 prefer
set system time-zone Europe/Dublin

 

Statische Routen die zu meinem Multilayer Switch führen der auf 10.0.0.5 intervlan betreibt:

 

set protocols static route 10.0.5.0/24 next-hop '10.0.0.5'
set protocols static route 10.0.6.0/24 next-hop '10.0.0.5'

 

Für OSPF brauchen wir natürlich ein Loopback sowie eine ACL:

 

set interfaces loopback lo address 4.4.4.4/32
set policy route-map CONNECT rule 10 action permit
set policy route-map CONNECT rule 10 match interface lo
set protocols ospf area 0 network 10.0.0.0/16
set protocols ospf parameters router-id 4.4.4.4
set protocols ospf redistribute connected metric-type 2
set protocols ospf redistribute connected route-map CONNECT

 

Wenn VyOS nach draussen geht wollen wir source-NAT:

 

set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 10.0.0.0/16
set nat source rule 100 translation address masquerade

 

Netflow; 10.0.5.15 auf Port 2055 ist mein Orion:

 

set system flow-accounting interface eth1
set system flow-accounting netflow engine-id 1
set system flow-accounting netflow server 10.0.5.15 port 2055
set system flow-accounting netflow timeout expiry-interval 60
set system flow-accounting netflow timeout flow-generic 3600
set system flow-accounting netflow timeout icmp 300
set system flow-accounting netflow timeout max-active-life 604800
set system flow-accounting netflow timeout tcp-fin 300
set system flow-accounting netflow timeout tcp-generic 3600
set system flow-accounting netflow timeout tcp-rst 120
set system flow-accounting netflow timeout udp 300
set system flow-accounting netflow version 9
set system flow-accounting syslog-facility daemon

 

Syslogs auch, hier direkt zu meiner LEM Appliance:

 

set system syslog global facility all level debug
set system syslog global facility protocols level debug
set system syslog host 10.0.5.17 facility all level debug
set system syslog host 10.0.5.17 facility all protocol udp

 

PPPoe:

 

set interfaces ethernet eth0 pppoe 0 password xxx
set interfaces ethernet eth0 pppoe 0 user-id yyy

 

Und schliesslich die Firewall.

Im Grunde genommen haben wir es mit ganz normalen ipTables zu tun und können zwischen verschiedenen Verhaltensweisen wählen. Ich bin seit dem Lernen für irgendeine Zertifizierung vor einer Weile ein Freund von ZBF und nutze den Ansatz auch in VyOS.

Hier nur ein Grundgerüst aus Beispielen – es gibt Tonnen von Dokumentation zu dem Thema im Netz.
Zuerst Erstelle ich Variablen, die mir das Leben erleichtern:

 

set firewall group address-group DC address 10.0.5.10
set firewall group address-group GoogleDNS address 8.8.8.8
set firewall group address-group GoogleDNS address 8.8.4.4
set firewall group address-group LEM address 10.0.5.17
set firewall group address-group ORION address 10.0.5.15
set firewall group address-group OpenDNS address 208.67.222.222
set firewall group address-group OpenDNS address 208.67.220.220

 

Nun fangen wir ganz einfach an und definieren ein Grundverhalten:

 

set firewall name allow-est-drop-inv default-action drop
set firewall name allow-est-drop-inv enable-default-log
set firewall name allow-est-drop-inv rule 1 action accept
set firewall name allow-est-drop-inv rule 1 state established enable
set firewall name allow-est-drop-inv rule 1 state related enable
set firewall name allow-est-drop-inv rule 2 action drop
set firewall name allow-est-drop-inv rule 2 log enable
set firewall name allow-est-drop-inv rule 2 state invalid enable

 

Ich nenne die Regel also (gekürzt) allow established, drop invalid und genau das passiert da oben auch.

Ich habe drei Zonen, lan und wan und local. Lan und wan sind klar; local ist die Firewall selbst.
Zonen kommunizieren nur wenn sie als Paar miteinander gekoppelt werden. Die Paarung kommt weiter unten und verweist auf vordefinierte Regeln. Erstellen wir diese Regeln zuerst!
Diese hier ist ganz einfach – Monitoring und Management aus dem LAN zum Router:

 

set firewall name lan-local rule 100 action accept
set firewall name lan-local rule 100 description PING
set firewall name lan-local rule 100 protocol icmp
set firewall name lan-local rule 200 action accept
set firewall name lan-local rule 200 description SNMP
set firewall name lan-local rule 200 destination port 161
set firewall name lan-local rule 200 protocol udp
set firewall name lan-local rule 300 action accept
set firewall name lan-local rule 300 description SSH
set firewall name lan-local rule 300 destination port 22
set firewall name lan-local rule 300 protocol tcp

 

Die zwei ersten Regeln aus dem LAN in die Weite Welt hinaus:

 

set firewall name lan-wan rule 100 action accept
set firewall name lan-wan rule 100 description BROWSING
set firewall name lan-wan rule 100 destination port 80,443
set firewall name lan-wan rule 100 protocol tcp
set firewall name lan-wan rule 100 source group network-group GALAXY
set firewall name lan-wan rule 200 action accept
set firewall name lan-wan rule 200 description DNS
set firewall name lan-wan rule 200 destination group address-group OpenDNS
set firewall name lan-wan rule 200 destination port 53
set firewall name lan-wan rule 200 protocol udp
set firewall name lan-wan rule 200 source group address-group DC

 

Sobald alle Regeln aufgesetzt sind definieren wir die Zonen mit dem jeweiligen Interface:

 

set zone-policy zone lan default-action drop
set zone-policy zone lan interface eth1

set zone-policy zone local default-action drop
set zone-policy zone local local-zone

set zone-policy zone wan default-action drop
set zone-policy zone wan interface eth0

 

Wer darf jetzt mit wem kommunizieren und welche Regeln werden beachtet:

 

set zone-policy zone lan from wan firewall name allow-est-drop-inv
set zone-policy zone local from lan firewall name lan-local
set zone-policy zone local from wan firewall name allow-est-drop-inv
set zone-policy zone wan from lan firewall name lan-wan

 

Ja, es gibt bequemere Firewalls. Es gibt auch Firewalls mit mehr Optionen.

Es gibt aber auch viele so genannte „Firewall Distributions“ die noch nicht einmal das Filtern von Sourceports erlauben – hier können wir das durchaus.

 

Bringen wir das Ding einmal in Solarwinds hinein! Manuell zu NPM hinzufügen; viel zu sehen gibt es nicht ausser tausenden von Volumes die mich nicht interessieren und daher entfernt werden.

Ebenso tausche ich das loopback gegen eth0 obwohl das gerade noch nicht verbunden ist:

04.png

Anhand OID identifiziert sich das System noch als Vyatta:

05.png

 

Die Neugier hat mich dazu getrieben zu schauen wer hier nachbessern muss:

 

06.png

NCM:

07.png

Aber! Wir brauchen dazu eine Vorlage aus der Community:

 

08.png

 

Einfach importieren. Wie das geht haben wir ja schon gelernt

09.png

 

Dann funktioniert es auch mit dem Nachbarn:

10.png

11.png

 

Man kann die Vorlage übrigens anpassen um wie oben gleich die Kommandos angezeigt zu bekommen – oder eben auch nicht:

 

12.png

 

Netflow kommt ohne weitere Konfiguration automatisch rein:

 

13.png

 

Logs werden auch geliefert:

14.png

 

 

Grundsätzlich alles wirklich einfach und erlaubt es, schnell einen Sandkasten zu bilden um irgendwelche Dinge zu testen.

 

Ich nehme auch manchmal auch gerne eine VM mit auf irgendwelche Veranstaltungen und lasse dort z.B. Netpath aus Orion live laufen – das Problem hier ist, dass Orion es nicht mag wenn sich die Adresse ändert, was aber dem unterliegenden Netzwerk geschuldet ist.

Wenn Vyos vor Orion sitzt bleibt das System permanent bei seiner statischen IP und alles funktioniert wie gedacht.

 

Und wenn Orion glücklich ist, bin ich es auch!

15.png