zunächst: es ist kein dringendes Problem, da wir hier zwei Internetzugänge haben.
Situation:
ssh (Port 2222) von außen -> 2222 Kabelanschluss (Fritz.Box) 2222 -> 2222 OPNsense (virtualisiert) 2224 -> 2224 Virtualisierungshost (Ubuntu 16.04.6 mit libvirt/KVM) geht nicht, da keine Antwort kommt.
Was geht: von außen statt auf den Virtualisierunghost auf den IPFire von lmn6.2
Was auch geht: über den zweiten Internetzugang T@School direkt auf den Virtualisierungshost
Komischerweise kann ich auch von der Kommandozeile der OPNsense eine ssh-Verbindung zum Virtualisierungshost aufbauen.
Sorry, ich habe an der Formulierung gefeilt, aber es ist glaube ich, noch nicht ganz verständlich, was ich meine. Die ssh-Verbindung scheitert am letzten Schritt vom virtuellen Netz, in dem OPNsense und der Virtualisierungshost sind, zum Host selbst. Hat jemand eine Idee, wer den Zutritt verhindern könnte?
kannst du skizzieren, wie T@school und kabelanschluss physikalisch mit dem(den?) Rechner(n?) verbunden sind?
Welche Netzwerkkarten werden von wo angeschlossen.
Wenn nämlich der Internetzugang @school auf den Host mit offensichtlich einer eigenen Netzwerkkarte klappt. Welches Netz hast du den auf dieser Netzwerkkarte? eines? oder virtuell viele?
am besten paste mal deine network/interfaces bzw. netplan/*.yml je nachdem was du auf dem host verwendest.
Ja, die Firewall des Hostes und zwar dann, wenn man z.B. das Standard-Netz von libvirt verwendet (oder ein eigenes Netz bei dem das virtuelle Netz mit NAT an das Hostnetz angeschlossen wird). Ein über eine Bridge geroutetes Netz wäre die bessere Lösung.
danke für die Vorschläge.
Eine Skizze des Netzwerks kommt hier:
Die vier virtuellen Maschinen OPNsense, firewall der Verwaltung, IPFire der lmn6.2 und der Virtualisierungshost haben Netzwerkkarten im virtuellen Netzwerk fw (wobei die OPNsense das Gateway ist) und der Virtualisierungshost hat eine virtuelle Bridge virbr3 mit Konfigurationsdatei fw.xml:
Außerdem funktioniert ssh von der OPNsense auf den Virtualisierungshost, wenn ich es dort von der Shell aus mache. Andrerseits geht auch ssh vom Kabel über OPNsense zum IPFire.
Wie hast du das mit der Bridge gemeint „WeitDahinten“? Ich bin mit den Begriffen nicht 100% vertraut.
ich vermute, das Problem hängt damit zusammen, dass es keine Route über die OPNsense ins Internet gibt. Letztendlich würden dann zwei Wege ins Internet führen, das geht wahrscheinlich nicht.
Bringt das neue Fragen oder Ideen auf?
VG
Christian
Tja, ich bin immer noch nicht weiter.
Zwischenzeitlich hatte ich ufw und fail2ban angehalten, aber es kam trotzdem keine Passwortabfrage. Auch eine Weiterleitung an die Bridge br0, die direkt am T@School-Anschluss liegt, hat nicht funktioniert.
Mit tshark habe ich den Verbindungsversuch mitgeschnitten:
Inzwischen bin ich auf Port 2227 gelandet, damit ich den Verkehr über den T@School-Anschluss sortiert bekomme.
Evtl. habe ich auch ein Tool ähnlich wie fail2ban installiert, um Serveranfragen, die nicht von mir sind, herauszufiltern. Leider habe ich dazu nichts dokumentiert, daher weiß ich nicht, wonach ich noch suchen könnte.
wieder ein Schrittchen weiter. Das Problem ist, die Antwort geht nicht über den gleichen Weg (Kabel) raus, wie die Anfrage reinkommt. Testweise habe ich also die Weiterleitung wieder auf meine virtuelle Bridge (virbr3) mit IP 192.168.2.99 auf Port 2227 gelegt und dann eine Route angelegt, die jeden Verkehr an meinen Rechner zu Hause über das Gateway im Netz von virbr3 (das ist dann 192.168.2.1) leitet. Und prompt kann ich mich von zu Hause über ssh verbinden. Allerdings klappt dann die bisherige Verbindung über den T@School Anschluss nicht mehr, weil die Antwort jetzt immer über das Kabel rausgeht.
Ich bräuchte also eine Regel (iptables ?), die jeden ausgehenden Verkehr mit source port 2227 über das Gateway 192.168.2.1 leitet (das default gw ist 10.0.0.1).
Kennt sich dazu jemand aus? Ich will hier ungern mein Netz zerschießen.
VG Christian
