Es sieht so aus, als würde die Range-Variante funktionieren. Ich werde heute Abend mal von zu Hause auf den Pi zuzugreifen versuchen und euch berichten.
Vielen lieben Dank für die ganze Hilfe bis jetzt!
Es sieht so aus, als würde die Range-Variante funktionieren. Ich werde heute Abend mal von zu Hause auf den Pi zuzugreifen versuchen und euch berichten.
Vielen lieben Dank für die ganze Hilfe bis jetzt!
Ich könnte bei uns im Rechenzentrum fragen, aber da ist die Abfertigung solcher Anliegen meist etwas schwierig.
Auch auf die Gefahr hin, dass ich die Ausgabe nicht richtig anonymisiere: hier das, was der Pi bei Eingabe der Befehle auswirft...
pi@octopi:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 111.22.333.444 netmask 255.255.255.0 broadcast 111.22.333.255
inet6 ab12::ab12:ab12:ab12:ab12 prefixlen 64 scopeid 0x20<link>
ether a1:a1:a1:a1:a1:a1 txqueuelen 1000 (Ethernet)
RX packets 10000 bytes 8000000 (***.* MiB)
RX errors 121 dropped 30551 overruns 0 frame 0
TX packets 10000 bytes 8000000 (*.* GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 111.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 10000 664 bytes 8000000 (*.* GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 535664 bytes 4052281782 (3.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
pi@octopi:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 111.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether a1:a1:a1:a1:a1:a1 brd ff:ff:ff:ff:ff:ff
inet 111.22.333.444/24 brd 111.22.333.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 ab12::ab12:ab12:ab12:ab12/12 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether a1:a1:a1:a1:a1:b1 brd ff:ff:ff:ff:ff:ff
Display More
Ich hoffe, das hilft bei dem Problem weiter. Ich dachte ja schon fast, die Broadcast-IP sei jetzt die richtige, aber doch nicht. Bitte entschuldigt, dass sich das Problem so zieht. Ich bin leider wirklich nicht sehr fit in derlei Dingen.
Dennoch tausend Dank!
Hello again,
ich habe die Subnetzmaske in den Netzwerkeinstellungen meines Arbeitsrechners eingesehen. 255.255.255.0/24
So habe ich sie eingegeben, mit dem Ergebnis, dass der Pi die Verbindung vom Arbeitsrechner aus verweigert hat. Ich habe versucht, das, was Du geschrieben hast, zu verstehen. Wie gesagt: ich hab bis jetzt nie etwas in dieser Syntax formuliert. Soweit habe ich auch den Großteil begriffen, bis auf das "!".
Aus gängigen anderen Programmsprachen verstehe ich das "!" als NOT. Vermutlich ist das aber nicht so gemeint.
Hallo nochmal,
ich habe mich heute mal am vorgeschlagenen Code probiert. Offenbar mache ich aber was falsch. Ich habe die Subnetzmaske vom Uni-Netz eingetragen. Nach der ersten Zeile konnte ich den Pi innerhalb des Uni-Netzes noch anpingen, aber schon die Weboberfläche nicht mehr erreichen. Nach der zweiten Zeile war er dann ganz dicht.
Also entweder bewirkt der Code nicht das, was ich will, oder ich mache es falsch, und ich gehe von Letzterem aus. "Uni-Netz-mit-der-richtigen-Syntax" heißt wahrscheinlich, dass ich keine IP à la 123.456.789.0 angeben kann, oder?
Danke vorab, vor allem für die Geduld mit so einer IT-Gurke
Vielen Dank für die Info!
Ich werde es morgen gleich ausprobieren. Im Moment läuft noch ein Druck, den ich nur ungern unterbrechen möchte. Ich melde mich dann zurück, ob und wie es klappt.
Teste erstmal mit nicht persistenten iptables-Regeln:
Codesudo iptables -I INPUT 1 -i <input-Interface> -p tcp ! -s <Uni-Netz-mit-der-richtigen-Syntax> -m state --state NEW,INVALID -j DROP sudo iptables -I INPUT 2 -i <input-Interface> -p icmp ! -s <Uni-Netz-mit-der-richtigen-Syntax> -j DROP
Nach einem reboot sind diese Regeln nicht mehr aktiv. Vorsicht mit iptables, damit Du dich nicht vom PI aussperrst.
Vielen Dank für die schnelle Hilfe. Ist <input-Interface> hier auch ein Platzhalter? Was müsste ich da eintragen?
ich weiß nicht, ob das hilfreich zur OS-Frage ist, aber der Pi gibt bei uname -a folgende Info:
Linux octopi 4.19.58-v7+ #1245 SMP Fri Jul 12 17:25:51 BST 2019 armv7l GNU/Linux
Ist das eine feste IPv4-Adresse (d. h. sie ändert sich nie)? Wenn ja, und der Zugriff Uni-Netz erfolgt aus einem ( oder mehreren) immer bekannten Subnetz, könnte man z. B. mit iptables nur diese Zugriffe zulassen.
Ganz genau so ist es. Dahin führt ja auch meine Fragestellung. Alles, was ich eigentlich nur tun will, ist in iptables definieren, dass er nur das Subnetz der Uni für eingehende Anfragen zulässt (Zugang über VPN ist ja dann auch möglich). Ich habe schlichtweg keine Ahnung, wie ich das in der dafür nötigen Syntax definiere.
Hat dein PI evtl. eine öffentliche IPv4-Adresse oder eine IPv6-Adresse zugewiesen bekommen, mit der der PI so erreichbar ist?
Hallo rpi444,
ja genau. Ich hoffe, ich verwechsle nichts, aber er hat eine ipv4 erhalten. also Nur Ziffern XXX.XX.XXX.XXX . Mit dieser IP ist er von überall erreichbar.
Liebe Forengemeinde,
zu erst einmal hallo von meiner Seite. Ich bin Neuling hier und auch bei Debian erst einmal nur grundsätzlich zu allen Dingen imstande. Ich betreibe an der Uni einen 3D - Drucker in meinem Fachgebiet, der so weit ab vom eigentlichen Ort des Geschehens steht, dass wir uns entschieden haben, ihn an das Netzwerk via Octoprint anzubinden. Dafür nutze ich einen Raspberry Pi 3 Model B+.
Wichtig für die Einrichtung ist, dass dem Pi vom Rechenzentrum immer dieselbe IP zugewiesen wird, was natürlich für das Erreichen des Druckers sehr günstig ist. Allerdings lässt sich der Pi auch außerhalb des Uni-Netzes anpingen und die OctoPrint Oberfläche ist auch problemlos erreichbar, womit ich etwas Bauchweh habe. Ich nutze für die Netzwerkkonfiguration den networking dienst, da dhcpcd nicht funktioniert hat. Das Port-Forwarding wird global vom Rechenzentrum geregelt, darauf habe ich also keinen Einfluss.
Meines Wissens nach sollte man mit iptables grundsätzlich in der Lage sein, den Zugang auf das Subnetz der Uni zu begrenzen. Ich wäre also froh, wenn der Pi auf Pings und Anfragen von Außerhalb schlicht nicht antwortet. Nun habe ich im Internet auf verschiedenen Wegen danach gesucht, wie ich diese Restriktionen programmieren kann und fand heraus, dass in iptables der Ausschluss spezifischer Subnetze möglich ist; ich möchte aber nun alle bis auf ein Subnetz ausschließen.
Hat jemand eine Ahnung, wie das funktioniert bzw. eine Anlaufstelle, an der ich mich dazu belesen kann? Seid bitte milde mit den Antworten. Ich bin wirklich noch frisch in der Sache und will noch viel lernen.
Tausend Dank Euch allen schon vorab,
mit liebem Gruß,
Philipp.