Routing-Tabelle konfigurieren in virtuellem Netz

scooter010

Commander
Registriert
Sep. 2014
Beiträge
2.532
Moin!

ich habe ein Netzwerk via Virtual-Box erstellt. Es besteht aus 3 Maschinen, nur die im Screenshot mittlere hat ein IFace (10-ner IP) per NAT zum Netzwerk des Hosts.
Im Screenshot sieht man rechts und links jeweils die Maschinen in den Subnetzen. Mitte ist der designierte Router.
Die Maschinen erreichen jeweils den Router per Ping. Jedoch kommen die Maschinen weder in das jeweils andere Subnetz noch ist das Internet über die Default-Route des Gateways erreichbar.
Wie habe ich die routen anzupassen, damit das klappt?


netzwerk.png

Oder liegt das an meiner Virtual-Box-Konfig? Hier die Konfig eines der Interfaces zu einem Subnetz am "Router":
virt_if_conf.png


Die Namen der Internen Netzwerke unterscheiden sich natürlich bei jedem Adapter. Und je ein Client im Subnetz gehört auch zu einem "internen Netz".
 
du musst das forwarding auf der mittleren vm erst aktivieren (siehe auch z.b. hier), per default ist das deaktiviert:
echo 1 > /proc/sys/net/ipv4/ip_forward
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: scooter010, snaxilian und Raijin
Abgesehen davon, musst du auch folgendes bedenken:

Von einem der anderen VM-Netze (192.168.20.0/24 bzw. 192 168.21.0/24) Richtung Internet, also über die mittlere VM ins physische Netzwerk und von dort zum Router ins www, ist die NAT-Konfiguration durch eben diese quasi-WAN-Schnittstelle gewährleistet. D.h. dein Internetrouter wird stets nur die IP deines Hosts sehen und keine Ahnung von den VMs haben, weder von den beiden separaten VMs noch von der mittleren VM.

Willst du nun aber von einer VM durch die Router-VM in die andere VM, gibt es erstmal kein NAT. Das heißt, dass die VM mit der .20.3 bei der 21.3 eben auch mit genau dieser 20.3 als Quell-IP ankommt. Das Routing stimmt nach wie vor, weil die mittlere VM in jedem Fall das Gateway ist, aber die Firewall in der 192.168.21.3er VM blockt womöglich eingehende Verbindungen aus fremden Subnetzen wie zB 192.168.20.0/24.
Entweder müssen die Firewalls der Seiten-VMs den eingehenden Traffic explizit erlauben oder aber die mittlere VM muss auch auf den Schnittstellen 2 und 3 jeweils (S)NATten bzw. masqueraden (geiles Wort).
 
  • Gefällt mir
Reaktionen: scooter010 und spcqike
0x8100 schrieb:
du musst das forwarding auf der mittleren vm erst aktivieren (siehe auch z.b. hier), per default ist das deaktiviert:
echo 1 > /proc/sys/net/ipv4/ip_forward
Wer kommt denn auf sowas...
Ja, das ist super. Jetzt erreichen sich die Subnetze gegenseitig, ohne Spielchen an iptables (@Raijin ). Aber mal angenommen, ich würde (S)NATen oder masqueraden wollen, wie ginge das? Hast du dazu einen brauchbaren Link?.
Es bleibt aber das Problem, dass ich aus den Subnetzen nicht erfolgreich 8.8.8.8 pingen kann, vom "Router" jedoch schon. Ziel ist ja, dass die Pakete für 8.8.8.8 aus den Subnetzen an 10.0.2.2 "geschaufelt" werden, der es in mein physisches Netzwerk "NATet".
 
scooter010 schrieb:
Jetzt erreichen sich die Subnetze gegenseitig, ohne Spielchen an iptables
Man achte auf die Details. womöglich blockt die Firewall an der Ziel-VM. Wenn die auf Default Accept/Allow steht und der Service dahinter seinerseits auch nichts dagegen hat, braucht man auch nichts in der Firewall.


scooter010 schrieb:
Aber mal angenommen, ich würde (S)NATen oder masqueraden wollen, wie ginge das?
So aus dem Stegreif:

Code:
iptables -t NAT -A POSTROUTING -o ethx -j MASQUERADE
iptables -t NAT -A POSTROUTING -o ethx -j SNAT --to aa.bb.cc.dd

Ersteres nimmt automatisch die primäre IP der Schnittstelle, letzteres definiert explizit welche IP geSNATtet werden soll.

scooter010 schrieb:
Es bleibt aber das Problem, dass ich aus den Subnetzen nicht erfolgreich 8.8.8.8 pingen kann, vom "Router" jedoch schon.
Dann musst du mal mit tcpdump prüfen bis wohin der Ping geht und bis wohin er zurückkommt, wenn überhaupt. Sprich: an jeder VM mittels tcpdump -i ethx host 8.8.8.8 bzw. auch tcpdump icmp laufen lassen. So kannst du den Weg des ICMP-Echo-Request und des ICMP-Echo-Reply verfolgen. Da müsstest du sehen wo er hängt.


*edit
tcpdump Befehl bitte notfalls nachschlagen, ich vertue mich da gern.
 
  • Gefällt mir
Reaktionen: scooter010
tcpdump ist natürlich nicht installiert... Aber ein traceroute ergab, dass die Anfrage nach 8.8.8.8 bis zum 20.1 bzw. 21.1 Interface am Router kommt und dann nicht weiter.
Liegt es daran, dass das ein privates Netz ist (192.168.20.3) und dafür der Router in das nächste private Netz NATten muss? Selbiges müsste sicherlich auch erstmal aktiviert und konfiguriert werden.

Raijin schrieb:
iptables -t NAT -A POSTROUTING -o ethx -j SNAT --to aa.bb.cc.dd


Oder aber die Anfrage geht tatsächlich raus, aber die Antwort auf den ICMP-Request kann nicht zurück kommen.

Edit:
Code:
iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE

Funktioniert, 8.8.8.8 ist erreichbar, apt funktioniert auch im Subnetz. Mega klasse, danke für die sehr guten Hints!

@Raijin Der Ping auf die Subnetze gegenseitig hat möglicherweise nur deswegen funktioniert, weil bei der Debian-Standardinstallation offenbar nichtmal iptables dabei ist und es somit keine Firewall gibt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Raijin
scooter010 schrieb:
weil bei der Debian-Standardinstallation offenbar nichtmal iptables dabei ist und es somit keine Firewall gibt.
Ich tippe eher auf nftables, den Nachfolger von iptables. iptables gilt als veraltet und wird aktuell sukzessive in den Distributionen durch nftables ersetzt. Keine standardmäßig installierte Firewall wäre fatal. Sie steht aber vermutlich auf default accept, ist also komplett offen. Deswegen merkst du nicht, dass sie da ist ;)
 
Stimmt, nftables scheint installiert zu sein, zumindest das Verwaltungstool nft.

Aber...

nft.png

Scheint jetzt nicht so viel konfiguriert zu sein.
 
Zurück
Oben