- NATting?
- Im Idealfall kein NAT verwenden.
- Ggf. SRCNAT-IP, die nicht zur relevanten Route / Routing-Table / Interface-IP passt?
- Lösungsoptionen: MASQUERADE statt SRC-NAT oder die richtige IP-Adresse für das SRC-NAT verwenden.
- Firewall Regel: fehlende Forward-Regel?
- Routes: Hin- und Rückweg korrekt definiert?
- Mangle / Routing Tables: Traffic landet in richtiger Table und dort ist auch eine passende Route vorhanden?
- Beispiel: Traffic landet wegen Mangle-Regel in der Routing-Table inet1, wo jedoch nur globale Default Routes definiert sind. Soll der Traffic aber bspw. mittels einer spezifischen Route in der Routing-Table main über ein VPN-Netzwerk geleitet werden, so würde genau diese spezifische Route nicht greifen, da wegen der Mangle-Regeln die Routes in inet1 verwendet werden.
Seite 6 von 14
MikroTik CAPsMAN Local Forwarding
Der Local Forwarding Mode wird genutzt, um WLAN-Traffic direkt am Access Point (AP) in das gewünschte Netzwerk zu leiten. So kann lokal am AP der Traffic mehrerer SSIDs in unterschiedliche VLANs geleitet werden. Dem gegenüber steht der Manager Forwarding Mode, bei dem der gesamte Traffic über den zentralen CAPsMAN geleitet wird und von dort aus weiter prozessiert und separiert werden kann.
Wichtiger Hinweis: Der Local Forwarding Mode kann auf dem AP nicht gemeinsam mit Bridge VLAN Filtering genutzt werden!
Lösungsoptionen:
a) Bridged VLAN (alle Ports in einer Bridge zusammenführen; zudem VLAN-Interfaces auf der Bridge anlegen)
b) AP manuell und ohne CAPsMAN konfigurieren.
Hinweis zu CAPsMAN 2
Der Manager Forwarding Mode wird von CAPsMAN in der neuen Version 2 nicht mehr unterstützt! (Quelle 1 2)
Check_MK: DNS Cache
Check_MK hat einen internen DNS-Cache, der die IP-Adressen aufgelöster Hostnames eine gewisse Zeit speichert. Auch wenn der betriebssystemseitige Cache geleert wurde und das Betriebssystem korrekt auf neue IPs auflöst, nutzt Check_MK ggf. weiterhin veraltete IPs.
Um auch innerhalb Check_MK die Verwendung aktualisierter IP-Adressen zu forcieren, sind folgende Befehle nötig:
su -l monitoring
cmk -v --update-dns-cache
cmk -OMikroTik Reset für CAPs Mode
- Gerät vom Stromnetz bzw. bei PoE vom Netzwerk trennen.
- Direkt nach dem Einstecken der Stromversorgung die Reset-Taste drücken und gedrückt halten (die LED beginnt für 5 Sekunden zu blinken)
- Die Reset-Taste für weitere 5 Sekunden gedrückt halten, bis die LED dauerhaft leuchtet.
- Danach startet der Access Point neu und befindet sich im CAPs Mode.
Settings für NextCloud auf ISPConfig
Bei einer frisch installierten NextCloud sind noch einige Einstellungen zu machen, um die Warnmeldungen abzuarbeiten. Das stellt eine Minimal-Config dar:
Folgendes Paket muss noch installiert werden, für den php-cache:
sudo apt install php-apcu
In der Web-GUI des ISP Config im entsprechenden Web für die NextCloud sind die Optionen wie folgt gesetzt:
php.ini ==>
apc.enable_cli=1
memory_limit = 512Mapache-Direktive ==>
Header always add Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"In der config.php im NextCloud Web-Verzeichnis wurde noch die letzten beiden Zeilen ergänzt, um die Telefoneinstellungen und den Cache zu aktivieren.
config.php ==>
'default_phone_region' => 'DE',
'memcache.local' => '\OC\Memcache\APCu',Im Anschluss einmal den Webserver neu gestartet, und die NextCloud gibt sich zufrieden.
Nachtrag zur cron.php
In manchen fällen wird die cron.php nicht ordnungsgemäß ausgeführt. Im Backend wird hierzu die 3. Option gewält, das der Systerm-Cron-Dienst die cron.php aufrufen soll.
Allerdings greift bei eingeschaltetem Memcache die „apc.enable_cli=1“ Direktive nicht.
Eine Option wäre, die „apc.enable_cli=1“ in die php.ini in jeder Option in den Unterordner „/etc/php/8.0/cli/php.ini“ zu schreiben. Bei einer neuen PHP Version bricht der cronjob dann allerdings wieder.
Die cron.php muss auch mit dem Web-User aufgerufen werden, dieser hat aber (vermutlich) nicht die Berechtigung den PHP Aufruf mit „–define apc.enable_cli=1“ zu starten.
Die nachhaltigste Lösung ist, den Cronjob als Root-User anzulegen und dort den Aufruf wie folgt zu gestalten:
*/5 * * * * sudo -u web1 php -f /var/www/nextcloud.example.com/web/cron.php --define apc.enable_cli=1
Nun wird alle 5 Minuten die cron.php mit dem User web1 im Webroot /var/www/nextcloud.example.com/web/ aufgerufen.
Der User und der Pfad sind natürlich an die eigenen Gegebenheiten anzupassen.
MikroTik Hints
- Bridge VLAN Filtering ist der bevorzugte Weg für VLAN-Konfiguration. Auch auf CRS100/200 Series, dann jedoch kein Hardware Offloading.
- VLAN Interface: Use Service Tag nur für Q-in-Q (IEEE 802.1ad) relevant
- Bridge mit PVID: Frame Types auf „admit only VLAN tagged“
- Hinweis: Bridge auch unter Bridge VLAN in „Tagged“ aufnehmen
- Ingress Filtering: Bei Nutzung von Bridge VLAN Filtering immer aktivieren (in Kombination mit frame-types). Aktivieren auf: Bridge und Bridge Ports!
- MSTP an Stelle von RSTP verwenden!
- Hinweis: MSTP benötigt Bridge VLAN Filtering!
- Bei Bridges immer Admin. MAC Address setzen!
MikroTik Hardware Offloading
Bei aktivem HW-Offloading:
- Bridge Filter greifen nicht
- Hinweis zu Bridge VLAN Filtering: HW-Offloading abhängig vom Switch Chip
- IP Firewall Rules greifen nicht
- Queuing ist inaktiv
- Workaround: Nutzung von Switch -> Port -> Ingress Rate / Egress Rate zur Limitierung der Datenraten
- Tools (Torch, Sniffer o.ä.) zeigen nur Traffic, der durch CPU processed wird
Features, welche HW-Offloading selbständig deaktivieren:
- Split Horizon
- (… ?)
Features, welche HW-Offloading benötigen:
- Switch Port Isolation: Forwarding Override
- (… ?)
Weitere Informationen:
- Switch Chip Features
- Bridge Hardware Offloading
- Kursunterlagen zu MTCSWE
WinBox Session & Config Folder
Wo befinden sich Session- und Konfigurationsdateien von WinBox unter macOS?
Bei manueller Installation von Wine und WinBox:
/Users/$Username/.wine/drive_c/users/$Username/Application Data/Mikrotik/Winbox
Bei nrlquaker-winbox (Brew / Cask):
/Users/$Username/Library/Application Support/com.mikrotik.winbox
RouterOS 7: OSPF Redistribute Connected Routes
/routing/filter/rule/add chain=ospf-redist rule={if [protocol connected] then={action do=accept}
/routing/ospf/instance/set default out-filter-chain=ospf-redistZudem Bug bei IP-Addresses vermutet (RouterOS 7.0.2): Erst das Ändern der IP-Adresse auf der VPN-Bridge (/24 entfernen und wieder hinzufügen) hat ein korrektes Routing über die VPN-Bridge ergeben.
Quellen:
MikroTik: CAPsMAN und CAP auf einem Device
Wenn ein MikroTik-Device als CAPsMAN fungiert und gleichzeitig die internen WLAN-Interfaces im CAP-Mode betrieben werden sollen, so muss bei den CAP-Einstellungen unter „CAPsMAN Addresses“ die lokale IP des CAPsMAN eingetragen werden.
Ansonsten ist eine Verbindung zwischen CAPsMAN und CAP nicht möglich, so dass die CAP WLAN-Interfaces nicht durch den CAPsMAN verwaltet werden.
Zudem ist eine Firewall-Freigabe in der Input-Chain erforderlich, die den Zugriff der lokalen CAPsMAN-IP auf sich selbst (Loopback) gestattet.
Hinweis zu CAPsMAN 2
Lokale Access Points werden von CAPsMAN in der neuen Version 2 nicht mehr unterstützt! (Quelle)
New capsman explicitly doesn’t support provisioning local devices (MT is very clear on that).