Über den VNC Port durch ein VPN Gateway auf ein System zugreifen

[Dati666]

Moin!
Ich versuche mein Vorhaben mal zu schildern.
Vom Büro aus, würde ich gerne eine VNC Verbindung auf meinen PC Zuhause haben. Dies allerdings nicht über die Öffentliche IP.
Im Büro ist eine Sophos Firewall mit UTM 9. Dies ist quasi der VPN Server. (10.90.0.1)(255.255.255.0)
Bei mir im Netzwerk steht ein Raspberry Pi der als VPN Client fungiert (intern 192.168.0.109)(255.255.255.0)
Eine Verbindung wird mit OpenVPN hergestellt und ist auch bereits vorhanden. (pings in beide richtungen funktionieren).
Der virtuelle VPN Adapter hat die IP 10.242.2.2(255.255.255.0)
Ich habe bereits ein Telefon mit dem Ding verbunden. Sprich das Gateway des Telefons auf die interne IP des Pi's gelegt (192.168.0.1).
Funktioniert, kommt bei der Telefonanlage an, interne durchwahlen auf das Ding funktionieren. So.

Jetzt zur eigentlichen Problematik:
Es soll vom Büro aus eine Fernwartung via VNC möglich sein. Sprich VNC->10.90.0.1->Internet->10.242.2.2->192.168.0.109(Datenaustausch zwischen den Adaptern)->192.168.0.111(PC System).
Das Problem an dem ganzen ist: Die VPN Verbindung soll nicht die Standard Verbindung ins Internet sein. Das Standard Gateway sollte der Telekom Speedport bleiben.
Ich habe leider nicht allzu viel Erfahrung mit Linux und Networking und daher keine Idee wie es sich umsetzen lässt, dass eine VPN Verbindung möglich ist, obwohl weiterhin die normale Verbindung ans Internet genutzt werden soll. Ob man dass über den Port machen kann? Dass quasi eine VNC Anfrage geschickt wird an 10.242.2.2:1190, der Pi das ganze an den PC(192.168.0.111) weiterleitet und so eine Verbindung entsteht? Wenn ja: Wie?


PC Betriebssystem ist Win10
Router ist ein Speedport w724v
Auf dem Pi ist ein Raspbian mit OpenVPN installiert.

 

[DTFM]

Hi,

spricht was dagegen, das über die Sophos zu konfigurieren?

 

[Raijin]

Du musst das Routing anpassen.

Der PC im Büro muss eine Route ins heimische 192.168.0.0/24 Subnetz über die Sophos haben; entweder über eine explizite Route oder implizit über das Standardgateway=Sophos.
Die Sophos muss eine Route ins heimische 192.168.0.0/24 Subnetz über die VPN-IP des PI haben (10.242.2.2)
Der PI muss eine Route ins Büro-Subnetz (10.90.0.0/24) über die VPN-IP der Sophos haben (10.242.2.1)
Der Ziel-PC muss eine Route ins Büro-Subnetz (10.90.0.0/24) über die LAN-IP des PI haben

Es muss gewissermaßen jedes Glied der Kette wissen in welche Richtung es die Verbindung weiterreichen muss. Jeder weiß immer nur vom nächsten, wie bei einer Telefonkette.

Darüber hinaus muss die Firewall des Ziel-PCs VNC-Anfragen aus dem Büro-Netzwerk akzeptieren und die Firewall der Sophos muss natürlich überhaupt erstmal die VNC-Verbindung zulassen.

 

[Dati666]

Mehr oder weniger möglich.
Die VNC Adresse soll in einem gemeinsamen Netzwerkordner in einer config gespeichert werden.
Sprich Routing auf dem PC im Büro ist hinfällig.
Allerdings lässt sich der PI vom PC Büro aus anpingen und über Putty öffnen.

Ping wird ausgeführt für 10.242.2.2 mit 32 Bytes Daten:
Antwort von 10.242.2.2: Bytes=32 Zeit=80ms TTL=63
Antwort von 10.242.2.2: Bytes=32 Zeit=81ms TTL=63
Antwort von 10.242.2.2: Bytes=32 Zeit=80ms TTL=63
Antwort von 10.242.2.2: Bytes=32 Zeit=80ms TTL=63

Und der Pi kann den Büro PC anpingen.

PING 10.90.0.137 (10.90.0.137) 56(84) bytes of data.
64 bytes from 10.90.0.137: icmp_seq=1 ttl=127 time=236 ms
64 bytes from 10.90.0.137: icmp_seq=2 ttl=127 time=83.9 ms
64 bytes from 10.90.0.137: icmp_seq=3 ttl=127 time=80.5 ms

Jetzt müsste ich nurnoch erreichen, dass der Heim PC über die 10.242.2.2 irgendwie erreichbar ist, ohne dass es in das Netzwerk wechselt.
Das würde für mich aktuell bedeuten, dass nurnoch Routen auf dem Pi und dem Heim PC gelegt werden müssen.
Könnt ihr mir da unter die Arme greifen? Ich habe noch nie Routen gelegt. Weder in Windows noch in Linux.. Und Theoretisch habe ich nur noch dieses Wochenende Zeit für den Spaß.

 

[Raijin]

Du pingst in dem Falle die VPN-IP des PI an. Wenn das für dich die Lösung sein soll, müsstest du im PI eine Portweiterleitung - auch bekannt als DNAT - einrichten. Alles was am PI auf der 10.242.2.2:5900 ankommt, müsste dieser dann mittels iptables an den PC im LAN weiterleiten.

Oder aber du machst es wie beschrieben und kannst direkt auf die IP des PCs zugreifen, seine LAN-IP. Dazu muss wie gesagt das Routing in beide Richtungen vom Büro-Netzwerk ins Heimnetzwerk und andersherum bei allen beteiligten Komponenten (PC - Sophos - PI - PC) eingerichtet werden. Der PI kann offenbar schon das Büro-Netzwerk erreichen, versuche nun mal vom Büro aus die LAN-IP des heimischen PCs zu pingen. Vermutlich klappt das dann nicht, weil der PC den Ping zur Sophos schickt und diese keine Ahnung vom Heimnetzwerk hat. Innerhalb der OpenVPN-Konfiguration kann an auch angeben, dass bestimmte Netzwerke über einen VPN-Teilnehmer erreicht werden können. Allerdings kenne ich mich mit Sophos nicht aus und kann dir daher nicht sagen wo genau du das einstellen musst.

Eine Route anzulegen ist recht simpel, das findet man bei google in 3 Sekunden raus. Bei Windows sieht der Befehl zB so aus:

"route add 10.90.0.0 mask 255.255.255.0 hier.die.lan.ip.des.pi -p"

Obiger Befehl müsste beim Heim-PC eingegeben werden (mit der korrekten PI-IP versteht sich).

Der PI selbst muss im übrigen überhaupt erstmal zum Durchreichen, also zum Routen überredet werden. Dazu muss man "net.ipv4.ip_forward=1" in /etc/sysctl.conf einfügen bzw. setzen.

Die notwendigen Routen in der Sophos bzw. im PI werden bei OpenVPN-Verbindungen in der Regel durch die OpenVPN-Konfiguration dynamisch erzeugt. Dazu steht dann in der server.conf bzw. client.conf sowas wie "route 192.168.0.0 255.255.255.0 hier.ein.gate.way" oder auch "iroute 192.168.0.0 255.255.255.0". Details dazu kannst du diesem Artikel entnehmen.

 

[Dati666]

Nicht umsetzbar leider... Ist zwar die einfachste Methode allerdings:
Dieses Verfahren soll später bei mehreren Kunden umgesetzt werden.
Und da haben mit Sicherheit mehrere leute eine 192.168.0.0 Domain.
Wenn ich also eine Anfrage an 192.168.0.1:5900 Anfrage abschicke, kann das an 10 verschiedenen Systemen ankommen.
Es MUSS also über die VPN IP laufen.

ip forward ist bereits in der sysctl.conf aktiviert. So weit bin ich immerhin schon.
Die Routen in der Client.conf sollten auch stimmen.
DNAT also... Super. Endlich habe ich für die Thematik mal ein Schlagwort! Ich werde mich hierzu mal ein wenig einlesen sobald ich wieder zuhause bin. Hast du damit ausreichend Erfahrung um mir ggf. auszuhelfen sollte ich am Wochenende irgendwo feststecken?

 

[h00bi]

Du wirst bei jedem Kunden eine andere Infrastruktur vorfinden und überall unterschiedliche Probleme lösen müssen.

Genau deswegen nutzt man i.d.R. einen externen Connection Broker wie Teamviewer, Anydesk o.ä. und genau deswegen kosten diese Services auch Geld.

Andere Möglichkeit:
Installiere auf dem Pi einen SSH Server, verbinde dich durch die Sophos auf den SSH Server beim Kunden. Dort kannst du dir dann beliebige Ports dahin mappen wo du es brauchst.
So habe ich das früher beim IPCop gemacht.

start putty.exe VPNADRESSE -ssh -l USERNAME -L 5901:HOSTADRESSE:5900

Ich hoffe ich hab das richtig angepasst, ist 6-7 Jahre her dass ich das benutzt hab. Das mappt den Port 5900 VNC-Host auf Port 5901 des SSH Servers.
In dem du den Local Port (-L) variierst kannst du mehrere Cients erreichbar machen.
So sah das bei mir aus:

start putty.exe meineip -ssh -l h00bi -L 443:192.168.0.1:8443 -L 3381:192.168.0.105:3389 -L 3380:192.168.0.83:3389 -P 8022

-P 8022 ist der nicht-Standard SSH Port des IPCop.

 

[Raijin]

Ich möchte ehrlich sein: Das klingt irgendwie nach einer gewerblichen Nutzung. Bisher ging ich davon aus, dass es sich um ein Heimnetzwerk handelt. Ob das dann wirklich der richtige Weg ist, sei mal dahingestellt. Es ist am Ende eine Bastellösung, die du scheinbar nur mit externer Hilfe zum Drehen bringen kannst und wenn irgendwas nicht funktioniert, landest du wieder im Forum. Wir helfen immer gern, dafür ist das Forum ja da, aber ich kann bei gewerblichen Lösungen nur dringend zu einer professionellen Lösung raten. Beispielsweise eine große Sophos im Büro und kleinere Sophos Appliances beim Kunden. Ein PI impliziert immer eine gewisse Bastellösung, insbesondere, wenn Linux-Kenntnisse fehlen.


DNAT ist grundsätzlich kein Hexenwerk, aber in der dargestellten Form mit mehreren PIs und dahinterliegenden Netzwerken, ist es fraglich ob es sinnvoll ist, das NAT individuell am PI zu realisieren. Es gäbe bessere Lösungen, die jedoch fortgeschrittenes Netzwerk-KnowHow voraussetzen - wie die individuelle PI-Lösung letztendlich auch. Es bereitet mir einige Bauchschmerzen, wenn du das Konzept erstellen und umsetzen sollst, ohne die notwendigen Kenntnisse zu haben :-/

Wie dem auch sei, der Vollständigkeit halber ein Beispiel wie man NAT am PI einrichten könnte:

# Die Firewall muss den Traffic ggfs erstmal erlauben
iptables -A FORWARD -p tcp -d 192.168.0.123 --dport 5900 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# Das ist die eigentliche Portweiterleitung
iptables -t nat -A PREROUTING -p tcp -i tun0 --dport 5900 -j DNAT --to-destination 192.168.0.123:5900

Da auf dem Rückweg der Verbindung vom PC zum Büro wiederum die die Quell-IP des PCs maskiert werden muss (weil der Büro-PC sonst die VPN-IP des PI fragt, aber eine Antwort von 192.168.0.123 bekommt), muss der PI noch ein SNAT machen, also den PC hinter seiner eigenen IP verstecken bzw. maskieren:

So ein SNAT bzw. Masquerade sähe am PI dann so aus:

iptables -t nat -A POSTROUTING  -o tun0 -j
MASQUERADE

Prinzipiell funktionieren NAT- bzw. Firewall-Regeln nach dem Prinzip Matching und Action. Das Matching beschreibt welche Bedingungen ein Datenpaket erfüllen muss, um die Action auszulösen. Stimmt auch nur ein Parameter nicht mit dem Matching überein, tut die Regel nix.

Solltest du Probleme damit haben, kannst du das natürlich auch über's Wochenende gerne hier posten. Wenn ich - oder jemand anderes - das zeitnah liest, gibt's mit etwas Glück auch rechtzeitig eine Antwort. Dennoch möchte ich nochmals darauf hinweisen, dass es ein Spiel mit dem Feuer ist, Kundenlösungen im Netzwerk ohne fachkundigen IT-Admin zu realisieren.

Ergänzung (7. Dezember 2018)

Nachtrag:

Sofern am Ziel-PC keine Rückroute hinzugefügt werden kann (zB mangels Admin-Rechten), kann man am PI auch den ausgehenden Traffic an eth0 mittels SNAT maskieren. Das ist alles in allem aber eine Menge NAT und ich fürchte, dass es eher früher als später zu Problemen kommen wird, die du ohne das entsprechende KnowHow nicht lösen können wirst.

Netzwerke sind leider deutlich komplexer als Otto Normal denkt. Zu Hause flutscht alles ganz easy, DHCP-Server, zu 99% vorkonfigurierter Router mit Firewall und allem, passt. Drei Haken setzen, zwei Textfelder ausfüllen, läuft. Dein Setup beinhaltet jedoch deutlich mehr Komponenten, die zudem auch noch zu Fuß zu konfigurieren sind (zB der PI). Zwar kannst du aus zahlreichen Tutorials und Videos blind irgendwelche Kommandos abtippen, aber wenn du nicht weißt was sie tun, kann das sogar gefährlich sein. Oder wie würdest du sonst beurteilen wollen ob zB meine obigen Kommandos nicht plötzlich den ganzen PI zerlegen oder eine Backdoor erstellen?

Du siehst, ich bin etwas skeptisch.. Nix gegen dich, aber ich bin ein gebranntes Kind. Viele Firmenchefs (vor allem im Mittelstand) meinen, dass jeder, der auf des Chefs Laptop einen Drucker einrichten kann, auch das Zeug zum IT-Admin hat - und wenn der Typ dann auch noch super-schlau über Grafikkarten parliert, weil er Gamer ist, dann hat er ja voll den Durchblick! Die Realität sieht aber anders aus. Nicht ohne Grund hat ein richtiger IT-Administrator eine Ausbildung oder gar ein Studium (oder beides) hinter sich. Das ist kein elitäres Denken oder so, sondern eine Tatsache.

Wenn du wüsstest mit wievielen "IT-Admins" ich schon zu tun hatte, die mir auf die Bitte um eine freie IP-Adresse in ihrem Netzwerk für unser VPN-Gateway mit "255.255.255.0" geantwortet haben................................

 

[Dati666]

Ich beruhige euch erstmal und schildere die aktuelle Situation.
Zu meiner Wenigkeit:
Ich bin Auszubildender im ersten Lehrjahr für den Beruf Fachinformatiker - Systemintegration. Daher mein fehlendes Wissen in dem Bereich.
Das ganze wurde mir als Weihnachtsprojekt von meinem ehemaligen Ausbilder zugeteilt. Dieser Ausbilder hat den Betrieb vor etwas mehr als einem Monat verlassen. Mein jetziger Ausbilder ist in dem Gebiet auch noch nicht allzu erfahren und kann mit daher nur sehr schwer helfen. Mal abgesehen davon, dass er gerade den Laden alleine schmeißen muss, worauf er nicht wirklich vorbereitet war. Ob und wie es tatsächlich hinterher eingesetzt wird ist ein gaaanz anderes Thema.
Die kompletten Texte werde ich mir durchlesen, sobald ich im Heim angekommen bin. Bis jetzt habe ich nur die Sorgen überflogen.
Wofür ich das Teil allerdings Tatsächlich in betracht ziehe ist die Verbindung der Telefone in den Home Offices. Das VOIP LAN ist getrennt von jeglichen anderen Netzwerken. Und eingerichtet habe ich das Ding problemslos alleine..

 

[Raijin]

Nun gut, das ist nachvollziehbar. Dennoch klingt die IT in eurer Firma etwas fragil.

Wie dem auch sei, ich habe dir oben ja eine Handvoll Kommandos für iptables unter Linux an die Hand gegeben. Damit solltest du schon mal einem Schritt weiterkommen.

Einen Tip gebe ich dir dazu noch: tcpdump.

Mit tcpdump kannst du am PI den Datenverkehr mitschneiden. Das ist im Grunde nichts anderes als WireShark für die shell, wenn dir das was sagt. So kannst du prüfen ob Pakete aus/ins VPN kommen/gehen bzw. aus/ins lokale Netzwerk. Denn wenn zB die Firewall im PI blockt, siehst du von außen nur, dass nix geht - wo auch immer es hakt. Mit tcpdump könntest du dann wenigstens sehen, das vnc aus dem VPN ankommt und auch ins LAN rausgeht, aber es kommt keine Antwort zurück --> der PC antwortet nicht.

 

[Dati666]

tcpdump ist ein wunderwerk verbunden mit tcpdump port 5900.
Da sehe ich zumindest, dass die Anfragen durchkommen. Aber eine VNC Verbindung kommt leider nicht zu stande. Ich sehe zwar, dass es komplett durchläuft und korrekt ankommt, aber mehr passiert leider auch nicht. Aus den Wireshark angaben kann ich leider nicht allzu viel anfangen. Muss auf dem Ziel PC noch etwas konfiguriert werden?
Pi

Wireshark

 

[Raijin]

Sofern der PI nicht wie oben beschrieben zusätzlich Snat bzw. Masquerade an eth0 ausgehend macht, kommt am Ziel-PC die VNC-Anfrage mit der Quell-IP aus dem Büro an und dieser blockt das dann wegen der unbekannten Herkunft (firewall) bzw. weiß damit gar nix anzufangen (Routing). In beiden Fällen würde er nicht antworten bzw. nicht antworten können. Der Ziel-PC braucht dann

1) in der Firewall eine Regel, die Verbindungen auf 5900 auch von fremden IPs (alle oder explizit anzugebende Quellen) akzeptiert
2) eine Rückroute ins Büro-Subnetz über den PI

Ersteres gibt es vermutlich schon, aber der zulässige Quell-Bereich steht standardmäßig auf "lokales Subnetz". Entweder auf "beliebig" umschalten oder explizit das lokale und das Büro-Subnetz als gültige Quelle eintragen. Dazu in die erweiteren Firewalleinstellungen gehen und dort bei den eingehenden Regeln die VNC-Regel bzw. die 5900er Regel suchen. Eigenschaften aufrufen und unter "scope" oder Bereich dann die zulässigen Quellen konfigurieren.

Letzteres wiederum geht wie folgt:

route add 192.168.0.0 mask 255.255.255.0 hier.die.pi.lan.ip -p

Oder aber du machst beim PI wie oben beschrieben NAT. Dann denkt der PC die VNC-Anfrage käme vom PI selbst.

 

[Dati666]

Das war aber eine verdammt schnelle Antwort.
Wenn ich mich nicht irre, sollte das NAT bereits eingerichtet sein.

 

[Raijin]

Ah, mein Fehler. -o tun0 macht das Masquerade natürlich bei traffic, der ins VPN geht, es müsste aber andersherum sein.

Grundsätzlich ist SNAT/Masquerade stets die letzte Option, wenn man es ohne so gar nicht schafft. Ansonsten kannst du wie gesagt gucken ob die Firewall des Ziel-PC die Verbindung überhaupt akzeptiert.

Also:

1) Die Masquerade-Regel erstmal wieder löschen (ist eh falsch)
2) nochmal vnc testen
3) Wenn's nicht klappt, in der Ziel-Firewall die eingehende VNC-/5900er-Regel prüfen und als Quelle zusätzlich das Büro-Subnetz eintragen
4) nochmal testen
5) wenn's nicht klappt, prüfen ob der Ziel-PC eine Route ins Büro-Subnetz hat; ggfs hinzufügen (s.o.)
6) testen

Ich hoffe übrigens ich hab die Subnetze nicht durcheinander gebracht. Eine Skizze der Netzwerke samt IPs ist immer besser als eine textuelle Beschreibung. Wenn ich nämlich dein Setup verdreht habe, sind natürlich auch die Kommandos falsch herum.

 

[Dati666]

1) Masquerade entfernt
2) Test nicht erfolgreich
3) Alle Ports offen. Von jeder IP möglich. Jedes Protokoll (Nur in der Testphase versteht sich)
4) erfolglos
5) route add 192.168.0.0 mask 255.255.255.0 hier.die.pi.lan.ip -p aufgeführt
6) erfolglos.
Ich teste mal, ob ich eine VNC Verbindung auf den Pi bekomme. Über einen anderen Port natürlich.

edit: Auf anhieb eine VNC Verbindung auf den PI über port 5901 möglich. Genutzte IP aus dem Büro 10.242.2.2::5901
das heißt, das Problem liegt zwischen PC und Pi. Ich schaue mir mal die VNC logs an.

 

[Raijin]

Wie gesagt, mach bitte mal eine Skizze von den Netzwerken samt IPs. Es ist gut möglich, dass bei den Kommandos die IPs/Subnetze verdreht sind, weil deine Beschreibung unvollständig oder missverständlich ist.

Und wenn du die Kommandos abtippst, darfst du natürlich auch immer mitdenken. Blind irgendwelche Befehle aus dem Internet abzutippen, kann eine böse Falle sein. Man sollte die Anleitungen nachvollziehen können, um sie ggfs an die eigene Situation anpassen zu können. Das heißt, dass man eben auch mal nach dem Kommando und den Parametern googlen darf

Also:

Skizze der beteiligten Netzwerke mit IPs für PC, Sophos, PI, PC. Ggfs lokale IP und VPN-IP.

 

[Dati666]

Reicht dir das so?

 

[Raijin]

Ja, das bringt Licht ins Dunkle

1. Route im Büro-PC zum VPN-Subnetz (nur wenn VPN-Gateway != Standard-Gateway):
   route add 10.242.2.0 mask 255.255.255.0 10.90.0.1
   --> Wenn der PC bereits auf den PI zugreifen kann, ist dieser Punkt hinfällig.
   
   
2. Firewall im PI:
   iptables –A FORWARD –p tcp –d 192.168.0.104 –-dport 5900 -j ACCEPT
   --> Akzeptiert explizit ausschließlich die Portweiterleitung, also VNC-Verbindungen auf den Ziel-PC
   
   
3. DNAT im PI:
   iptables -t nat -A PREROUTING -p tcp -i tun0 --dport 5900 -j DNAT --to-destination 192.168.0.104:5900
   --> Die Portweiterleitung im PI
   
   
4. Firewall im Ziel-PC:
   Windows Firewall --> Erweiterte Einstellungen --> Eingehend --> vnc/5900 --> Eigenschaften --> Bereich --> Quelle = Alle oder explizit alle erlaubten Quellen angeben
   
   
5. Route im Ziel-PC:
   route add 10.90.0.0 mask 255.255.254.0 192.168.0.108
   
   
6. (optional) SNAT im PI
   iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Variante A (1-5):
Am Ziel-PC würde ein VNC-Request von der Quell-IP 10.90.0.137 ankommen. Sofern dessen Firewall eingehenden Traffic von 10.90.0.0/23 auf dem VNC-Port erlaubt (4), würde der Ziel-PC an 10.90.0.137 antworten. Die Antwort schickt er an den PI als Gateway (5). Ohne diese Route (5) würde er die Antwort ans Standard-Gateway schicken, also den lokalen Router (192.168.0.1).

Variante B (1+2+3+6):
Am Ziel-PC würde ein VNC-Request von der Quell-IP 192.168.0.108 ankommen, weil der PI die Quell-IP maskiert (6) und mit seiner eigenen ersetzt. Die Firewall denkt, dass der Zugriff aus dem lokalen Netzwerk kommt und akzeptiert ohne weiteres Zutun. Die Antwort wird an die vermeintliche lokale Quelle geschickt, den PI. Der PI "re-NATtet" sozusagen die Antwort und reicht sie wieder an den Quell-PC zurück.



Ich würde definitiv zu Variante A raten. NAT ist grundsätzlich ein "pain in the ass" wie man so schön sagt. Durch die Portweiterleitung muss eh schon geNATtet werden, aber das Masquerade ist gewissermaßen die Lösung für jene, die es partout nicht ohne hinbekommen. Quasi quick and easy, aber auch quick and dirty. Man spart sich nämlich zB Einstellungen in der Firewall am Ziel, verliert dadurch aber auch die Möglichkeit, eben gerade diesen Zugriff gezielt zu unterbinden. Vom Standpunkt der IT-Sicherheit, ist Masquerade also eher kontraproduktiv, da man Masquerade-Traffic nicht erkennen kann. Für das Ziel sieht es so aus als wenn der PI selbst die VNC-Verbindung herstellen will. Das mag in deinem Szenario "egal" sein, aber Firewalls sind in der Regel rasiermesserartig konzipiert, alles wird geblockt, aber nur ganz bestimmte Dinge werden erlaubt. Bei Masquerade verliert man diese Möglichkeit.

Ergänzung (10. Dezember 2018)

Nachtrag:

Du musst natürlich ggfs bisherige Einstellungen wieder entfernen.

Hab übrigens noch ein paar Kommentare angefügt.

 

[Dati666]

Findet er doof.

iptables –A FORWARD –p tcp –d 192.168.0.104 –-dport 5900 -j ACCEPT
Bad argument `–A'

Edit:
JAWOHL! Den brauchte er nichtmal!
Ich bin drauf!

 

[Raijin]

Findet er wahrscheinlich doof, weil die Regel schon vorhanden war? Wenn du sie schon gelöscht hattest und es jetzt trotzdem funktioniert, kann es sein, dass die FORWARD chain auf "Default: ACCEPT" steht.

Egal, Hauptsache funktioniert

Du hast somit dein erstes Setup mit iptables erfolgreich eingerichtet. Das wird dir im Laufe der Ausbildung (hoffentlich) noch häufiger begegnen. Ansonsten schadet es nicht, sich damit auch im Selbststudium zu beschäftigen.