Ich habe gerade einen UniFi US-8 (verwalteter 8-Port-PoE-Switch) gekauft und versuche, ihn einzurichten, aber ich schaffe es nicht, dass der UniFi-Controller das Gerät erkennt. Der Controller sagt nur „Keine Geräte gefunden.“
Meine aktuelle Netzwerkkonfiguration ist:
ISP-Modem/Router ( 192.168.0.1/24) -> Fortigate 30E ( 192.168.1.1/24) -> Desktop ( 192.168.1.10/24)
Der UniFi-Controller ist auf meinem Desktop installiert ( 192.168.1.10/24).
Wenn ich das Fortigate aus der Gleichung entferne:
- Mein ISP-Modem/Router neu konfigurieren, damit es im
192.168.1.0/24Netzwerk ist - Verbinden Sie den Switch und meinen Desktop jeweils mit einem LAN-Port am Modem/Router
Ich kann dann von meinem Desktop aus Kontakt (Ping/SSH) zum Switch aufnehmen ( 192.168.1.10/24), und der auf meinem Desktop laufende Controller sieht den Switch und kann ihn „übernehmen“.
Wenn ich jedoch das Fortigate-Tor wieder in die Gleichung einbeziehe:
- ISP-Modem/Router im
192.168.0.0/24Netzwerk - Fortigate 30E im
192.168.1.0/24Netzwerk (WAN-Port mit einem LAN-Port am ISP-Router verbunden) - Desktop und Switch an LAN-Ports des Fortigate angeschlossen
Mein Desktop kann den Switch nicht mehr sehen. Wenn ich mir das Geräteinventar im Fortigate anschaue, sieht es so aus, als ob der Switch eine DHCP-Lease für bekommt 192.168.1.12/24, aber ich kann nur auf diese Adresse zugreifen, wenn ich einen Laptop direkt an den Switch anschließe und den Laptop so konfiguriere, dass er im 192.168.1.0/24Netzwerk ist.
Blockiert Fortigate den Datenverkehr zum Switch? Wenn ja, was kann ich tun, um den Datenverkehr weiter fließen zu lassen?
show system interfaceAls Referenz ist unten die Ausgabe des Befehls aufgeführt:
FWF30E********** # show system interface
config system interface
edit "wan"
set vdom "root"
set ip 192.168.0.10 255.255.255.0
set allowaccess ping https http fgfm
set type physical
set scan-botnet-connections block
set role wan
set snmp-index 1
next
edit "modem"
set vdom "root"
set mode pppoe
set type physical
set snmp-index 2
next
edit "ssl.root"
set vdom "root"
set type tunnel
set alias "SSL VPN interface"
set snmp-index 3
next
edit "wifi"
set vdom "root"
set type vap-switch
set role lan
set snmp-index 5
next
edit "guestwifi"
set vdom "root"
set ip 192.168.11.1 255.255.255.0
set allowaccess ping https ssh http
set type vap-switch
set device-identification enable
set fortiheartbeat enable
set role lan
set snmp-index 7
next
edit "internal"
set vdom "root"
set ip 192.168.1.1 255.255.255.0
set allowaccess ping https ssh http fgfm capwap
set broadcast-forward enable
set type switch
set device-identification enable
set fortiheartbeat enable
set role lan
set snmp-index 6
next
edit "lan"
set vdom "root"
set type hard-switch
set stp enable
set role lan
set snmp-index 4
next
end
Antwort1
Ich glaube, ich habe das Problem gelöst – unten sind meine Notizen:
Mir ist aufgefallen, dass der Switch die Firewall übernimmt, wenn ich sie neu starte, kurz bevor sie fertig ist. Sobald die Firewall fertig ist, verliert der Switch die Verbindung. Ich kann auch keine Verbindung zu anderen Geräten in meinem Subnetz herstellen.
Wenn ich „lan“ aus den Mitgliedern des standardmäßigen „internen“ Software-Switches entferne, stellt der Switch (der immer noch standardmäßig 192.168.1.20/24 ist) eine Verbindung zu meinem Desktop her (und ich kann eine Verbindung zu anderen Geräten im Netzwerk 192.168.1.0/24 herstellen), aber ich verliere die Internetverbindung. Die Firewall erstellt automatisch eine neue Hardware-Switch-Schnittstelle namens „lan“, die aus allen 4 physischen LAN-Schnittstellen als Mitgliedsschnittstellen besteht.
Um von meinem Desktop aus wieder eine Verbindung zur Firewall herzustellen, musste ich mich mit meinem Telefon (das sich im internen WLAN-Netzwerk 192.168.1.0/24 befindet) bei 192.168.1.99 (der IP der Firewall) anmelden und die neue „LAN“-Gateway-IP auf 192.168.10.99/24 einstellen und dann meinen Computer so einrichten, dass er sich im neuen Subnetz befindet (ich habe ihn auf 192.168.10.10/24 eingestellt, mit Gateway 192.168.10.99). Aber jetzt, da sich mein Desktop in einem anderen Subnetz befindet, verliere ich die Verbindung zum Switch.
Von meinem Desktop (192.168.10.10/24, Gateway 192.168.10.99) aus habe ich in der „IPv4-Richtlinie“ eine neue Firewall-Regel erstellt, um den gesamten Datenverkehr von „LAN“ zu „WAN“ zuzulassen. Dadurch wurde meine Verbindung zum Internet wiederhergestellt, aber wie erwartet kann ich weder einen Ping noch eine SSH-Verbindung zum Switch oder zu anderen Hosts im Netzwerk 192.168.1.0/24 herstellen. Ich habe dies bestätigt, indem ich meinen Desktop wieder auf das Netzwerk 192.168.1.0/24 (Gateway 192.168.1.99) eingestellt habe, wodurch mein Internet unterbrochen wird, aber ich kann erneut einen Ping/SSH-Verbindung zu anderen Hosts in diesem Subnetz herstellen und der Switch stellt die Verbindung wieder her.
Da ich weiß, dass der Switch standardmäßig auf 192.168.1.20/24 eingestellt ist, wenn er keine DHCP-Lease erhält, habe ich den DHCP-Server für die „LAN“-Schnittstelle eingeschaltet und dem Switch wurde schließlich eine IP zugewiesen und er wurde mit meinem Desktop verbunden.
Das nächste Problem bestand nun darin, herauszufinden, wie man Geräten an der „internen“ Schnittstelle (WLAN-Geräte) die Kommunikation mit Geräten an der „LAN“-Schnittstelle (kabelgebundene Geräte) ermöglicht. Dazu habe ich zwei IPv4-Richtlinien eingerichtet: allen Datenverkehr von „LAN“ nach „intern“ zulassen und allen Datenverkehr von „intern“ nach „LAN“ zulassen.
Mit dieser Lösung wird das gewünschte Ergebnis erzielt, aber ich bin nicht sicher, ob dies der sicherste (oder der „beste“) Weg ist, dies zu erreichen.