Schlagwort: mikrotik

MikroTik Mangle / Routing

Bei Anpassungen der Mangle-Regeln mark routing oder der Routen in der „Route List“, ggf. den Router neustarten.
Ansonsten kann es vorkommen, dass das Routing (wie in der Routing Table dargestellt) nicht greift bzw. davon betroffene, neue Connections abgelehnt werden.

Teilweise kommt es in WinBox auch vor, dass die aktiven / inaktiven Routen in der Route List bei einem Statuswechsel nicht korrekt aktualisiert werden (Flags und farbliche Darstellung sind falsch). Hier hilft es, das Fenster „Route List“ innerhalb der WinBox zu schließen und neu zu öffnen. (Quelle zum WinBox-Bug)

RS-232 via SSH mit MikroTik

# settings for port "usb1"
/port set usb1 baud-rate=115200 data-bits=8 flow-control=none parity=none stop-bits=1

# disable system console for serial usb
# cave: "0" may be the integrated serial port
/system console disable 0

/user add name=rs232_ssh group=read password=my-secret-password

/special-login add port=usb1 user=rs232_ssh

Quelle

Eingesetzte Hardware:

  • MikroTik Router (z.B. mAP oder hEX S; beide können PoE-In und benötigen daher kein extra Netzteil)
  • USB auf RS-232

MikroTik FastTrack and FastPath

FastTrack = FastPath + Connection Tracking

All related information and sources:

FastPath
FastPath allows to forward packets without additional processing in the Linux kernel. It improves forwarding speeds significantly. For FastPath to work, interface support and specific configuration conditions are required. Automatically use of IPv4 FastPath if criterias are matching, see here.
Packets can be forwarded by fast path handler (e.g. ipv4 fasttrack) only if at least source interface support FastPath. For complete FastPath forwarding destination interface support is also required (see here).

FastTrack
IPv4 FastTrack handler is automatically used for marked connections. Use firewall action „fasttrack-connection“ to mark connections for FastTrack. Currently only TCP and UDP connections can be actually FastTracked. IPv4 FastTrack handler supports NAT.
Note that not all packets in a connection can be FastTracked, so it is likely to see some packets going through slow path even though connection is marked for FastTrack. This is the reason why fasttrack-connection is usually followed by identical accept-rule. FastTracked packets bypass firewall, connection tracking, traffic shaping queues, IPSec*, and several other configurations. So it is up to the administrator to make sure FastTrack does not interfere with other configuration.

Again, please keep in mind: Firewall filter and mangle rules will not be applied for FastTracked traffic!

*FastTrack can break connections running via IPSec! See video Most underused and overused RouterOS tools and features for details. Solutions: Disabling FastTrack or using Raw Firewalling rules for „no track“.

Automatisiertes MikroTik Firmware-Upgrade

/system scheduler
add name=UpgradeFirmware on-event="if ([/system routerboard get current-firmware] !=  [/system routerboard get upgrade-firmware]) do={ :log info message=\"initiate routerboard upgrade\"; /system routerboard upgrade; log info message=\"upgrade routerboard done\"; :delay 10; :log info message=\"initiate reboot after routerboard upgrade\"; /system reboot }" policy=reboot,read,write,policy,test,password,sensitive start-time=startup

MikroTik SNMP OID

MikroTiks RouterOS bietet auf der Kommandozeile die Möglichkeit, zu gewissen Werten die OIDs auszugeben. Dadurch erhält man schnell und einfach eine Zuordnung von Parametern zu OIDs, welche für das Monitoring mittels SNMP genutzt werden können. Mit Hilfe des folgenden Befehls können OIDs überall dort ermittelt werden, wo entsprechende Parameter seitens des Herstellers implementiert wurden:

print oid

Gängige Beispiele:

/system health print oid 
            voltage: .1.3.6.1.4.1.14988.1.1.3.8.0
            current: .1.3.6.1.4.1.14988.1.1.3.13.0
        temperature: .1.3.6.1.4.1.14988.1.1.3.10.0
  power-consumption: .1.3.6.1.4.1.14988.1.1.3.12.0

/interface print oid 
Flags: D - dynamic, X - disabled, R - running, S - slave 
 0  R  ;;; ether1 - WAN
       name=.1.3.6.1.2.1.2.2.1.2.463 
       actual-mtu=.1.3.6.1.2.1.2.2.1.4.463 
       mac-address=.1.3.6.1.2.1.2.2.1.6.463 
       admin-status=.1.3.6.1.2.1.2.2.1.7.463 
       oper-status=.1.3.6.1.2.1.2.2.1.8.463 
       bytes-in=.1.3.6.1.2.1.31.1.1.1.6.463 
       packets-in=.1.3.6.1.2.1.31.1.1.1.7.463 
       discards-in=.1.3.6.1.2.1.2.2.1.13.463 
       errors-in=.1.3.6.1.2.1.2.2.1.14.463 
       bytes-out=.1.3.6.1.2.1.31.1.1.1.10.463 
       packets-out=.1.3.6.1.2.1.31.1.1.1.11.463 
       discards-out=.1.3.6.1.2.1.2.2.1.19.463 
       errors-out=.1.3.6.1.2.1.2.2.1.20.463 

Quelle

MikroTik Wishlist

Isch hätt gern für bestimmte Use Cases ein MikroTik-Device mit folgenden Eigenschaften:

  • LACP 802.3ad (Bonding) mit Hardware Offloading
  • IPsec Hardware acceleration
  • mind. 1 * PoE-Out 802.3af/at oder Passive PoE
  • mind. 2 * 10GbE, bevorzugt SFP+ oder alternativ 10GBASE-T
  • x * GbE (1000BASE-T)
  • redundante Netzteile
  • passive Kühlung bzw. kein Lüfterbetrieb bei Raumtemperatur

Optional:

  • PoE-In
  • Serial Console Port
  • 19″ Chassis

Die o.g. Anforderungen mögen als eine Art Zwitter bisheriger MikroTik-Devices erscheinen. Teile davon finden sich derzeit überwiegend in den Switch-Modellen (bspw. LACP Hardware Offloading), andere wiederum eher in Routern (IPsec Hardware acceleration).

VPN mit Proxy ARP

Use case: VPN-Einwahl, bei der die VPN-Clients IP-Adressen des Zielnetzes erhalten.

Problem: Forwarding / Routing der Pakete zu Geräten im Zielnetz funktioniert nicht. Tx-Pakete gehen an das Zielgerät, Rx-Pakete (Antworten) kommen nicht zurück.

Lösung: Proxy ARP auf lokalem Netzwerk-Interface des VPN-Servers konfigurieren. Kommt auf dem Gateway für das lokale Netz eine Bridge zum Einsatz, ist auf dieser Proxy ARP zu aktivieren.

Quelle

MikroTik RSA-Key Login

In meinem letzten Blog-Post habe ich mich mit OpenSSH (ab Version 7.0) und dem SSH-Login bei MikroTik beschäftigt, genauer gesagt mit dem DSA-Algorithmus. Dieser wurde bei OpenSSH neuerdings deaktiviert. Nachdem ich den „Workaround“ eingerichtet und geposted hatte, habe ich mich auf die Suche nach dem RSA Support in der Feature-Liste für die nächsten RouterOS Versionen gemacht. Hätte ich mal lieber im Changelog gesucht, wäre ich auch fündig geworden. Seit RouterOS 6.33 wird RSA beim SSH-Login mit 2048 Bit unterstützt. Das zum Thema „Wer lesen kann ist klar im Vorteil“ oder auch #RTFM, wobei im MikroTik Manual an entsprechender Stelle auch nur DSA erwähnt wird.
Und wenn ich schon dabei bin, teste ich doch gleich mal meinen 4096-bitigen Schlüssel, welchen ich generell für Backups schon erzeugt habe. Funktioniert zu meiner Überraschung.
Und wenn ich eh schon beim „Hardening“ angekommen bin, habe ich noch zwei optionale Parameter für RouterOS gesetzt, welche ich euch ebenfalls empfehlen würde auf dem Terminal zu setzen:

/ip ssh set host-key-size=4096 strong-crypto=yes

MikroTik: SSH Login ab Debian 9.0

UPDATE: Diese Information ist nur noch für ältere RouterOS Versionen vor 6.33 gültig, für neuere Versionen gibt es hier eine ordentliche Lösung.

Nachdem ich vor Kurzem meinen Backup-Server auf das aktuelle Debian 9.0 (stretch) aktualisiert habe, läuft mein Backup-Script für meine MikroTiks nicht mehr. Kein Ein Fall für eine akute Fehlersuche. Meine RouterOS-Config ist im Moment recht statisch, denoch wichtig genug um ein paar Minuten am Wochenende dafür zu opfern. Denn wie heißt es so schön im Buch „Zeitmanagement für Systemadministratoren“ — „Backups, Backups und Backups…“.
Das Backup läuft über SSH mit Key-Authentication mit einem eigenen Script:

#!/bin/bash
MT_HOSTS="mikrotik01.example.com mikrotik02.example.com"
MT_PORT=22
MT_USER=backup
MT_KEY="/root/.ssh/id_dsa"
MT_DIR="/backup/mikrotik"
MT_DATE=$(date +"%Y%m%d-%H%M")
for MT in ${MT_HOSTS}; do
[ ! -d ${MT_DIR}/${MT} ] && mkdir -p ${MT_DIR}/${MT}
ssh -p ${MT_PORT} -i ${MT_KEY} ${MT_USER}@${MT} "/export file=${MT}.rsc"
scp -P ${MT_PORT} -i ${MT_KEY} -B -q ${MT_USER}@${MT}:${MT}.rsc ${MT_DIR}/${MT}/${MT}_${MT_DATE}.rsc
done

Leider akzeptiert MikroTik bisher nur DSA und keine RSA-Keys. Hier liegt auch schon der Fehler: Debian stretch verwendet OpenSSH 7.4 und ab OpenSSH 7.0 wird der DSA-Algorithmus als „weak“ nicht mehr unterstützt. Solange MikroTik keinen RSA-Support implementiert, kann man den DSA-Algorithmus explizit wieder erlauben. Hierfür hab ich im Home-Directory meines Backup-Servers die Config-Datei (~/ssh/config) mit folgender Zeile ergänzt:

PubkeyAcceptedKeyTypes +ssh-dss

Ab dann funktioniert der SSH-Login per PublicKey (und damit mein Backup) wieder tadellos. Alternativ kann auch die Option nur bei dem BackupScript mitgegeben werden. Dafür müssen die SSH Aufrufe im Script mit folgender Option ergänzt werden:

ssh -oHostKeyAlgorithms=+ssh-dss

Quellen:
OpenSSH