4
Netzwerk Routing Frage
Hallo zusammen,
ich hab hier mal ein kleine netzwerktechnisches Problemchen....
Ich hab einen Monitoring Server (MON-SRV 192.168.0.10) welcher mit einem Agent einen Host (Host A 192.168.0.20) überwacht.
Host A hat einen VPN Tunnel übers WWW zu HOST B (172.16.10.10)
Nun würde ich gerne vom MON-SRV einen PING-CHECK zu HOST-B durchführen.
Hierfür habe ich die Routingtabelle auf dem MON-SRV, mit folgenden Eintrag ergänzt:
route add 172.16.10.10 gw 192.168.0.20
Leider bekomm ich keinen PING zustande.
Wo liegt mein Denkfehler?
Viele Grüße
wheasel
PS. Alle drei Devices sind Linux Büchsen.
ich hab hier mal ein kleine netzwerktechnisches Problemchen....
Ich hab einen Monitoring Server (MON-SRV 192.168.0.10) welcher mit einem Agent einen Host (Host A 192.168.0.20) überwacht.
Host A hat einen VPN Tunnel übers WWW zu HOST B (172.16.10.10)
Nun würde ich gerne vom MON-SRV einen PING-CHECK zu HOST-B durchführen.
Hierfür habe ich die Routingtabelle auf dem MON-SRV, mit folgenden Eintrag ergänzt:
route add 172.16.10.10 gw 192.168.0.20
Leider bekomm ich keinen PING zustande.
Wo liegt mein Denkfehler?
Viele Grüße
wheasel
PS. Alle drei Devices sind Linux Büchsen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 316149
Url: https://administrator.de/contentid/316149
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
Standort zu Standort VPN oder ein Client zu Standort?
Gruß,
Peter
Standort zu Standort VPN oder ein Client zu Standort?
Leider bekomm ich keinen PING zustande.
Wenn dein Ping erfilgreich am Clint Horts B ankommt, woher sollder Client dort wissen wohin er die Antwort zu senden hat? Weis dein VPN Horst A denn überhaupt das es deine ICMP Anfrage auf sein VPN Tunnel auf reise schiecken soll? Was passiert falls erfolgreich, mit den Antworten deiner ICMP Anfragen? Dir mal angeschaut wo deine ICMP Anfragen oder ICMP Antworten stecken bleiben?Wo liegt mein Denkfehler?
TCPIP ist immer eine Bidirektionale Kommunikation. Einbahnstrassen helfen nicht.Gruß,
Peter
Servus.
Stell dir einfach vor wie die Pakete fließen, welche Quell- und Zieladressen die Pakete auf dem jeweiligen Device haben und was die Hosts für Routingtabellen haben.
MON-SRV möchte ein Paket an die IP-Adresse von Host B schicken, dazu schaut er in seine Routing-Tabelle und sieht, aha, das Paket muss ich an Host A weiterleiten. Bis dahin alles OK. Host A müsste jetzt dieses Paket anhand seiner Routingtabelle über den Tunnel weiterleiten, er tut dies aber nur wenn bei Ihm das IP-Forwarding aktiviert worden ist und die Firewall das Forwarding des Pakets erlaubt! Ist es das nicht wird das Paket verworfen. Wenn du nun aber das IP-Forwarding aktivierst leitet HOST A das Paket zwar an Host B weiter aber Host B kennt das Subnetz von MON-SRV unter Umständen nicht (wenn es ihm nicht schon durch einen VPN-Payload bekannt gemacht wurde), deswegen müsstest du den Traffic von MON-SRV auf HOST A mit IPTables NATen (SRC-NAT, also die Quelladresse des Pakets auf die von Host A umschreiben) damit die Antworten auf die Pakete auch wieder geregelt zurückfließen, wenn du auf HOST B oder dem Tunnelendpunkt die Routingtabelle nicht modifizieren darfst/kannst.
Ganz einfache und logische Routing-Grundlagen halt.
Nun alles klar
?
Grüße Uwe
Stell dir einfach vor wie die Pakete fließen, welche Quell- und Zieladressen die Pakete auf dem jeweiligen Device haben und was die Hosts für Routingtabellen haben.
MON-SRV möchte ein Paket an die IP-Adresse von Host B schicken, dazu schaut er in seine Routing-Tabelle und sieht, aha, das Paket muss ich an Host A weiterleiten. Bis dahin alles OK. Host A müsste jetzt dieses Paket anhand seiner Routingtabelle über den Tunnel weiterleiten, er tut dies aber nur wenn bei Ihm das IP-Forwarding aktiviert worden ist und die Firewall das Forwarding des Pakets erlaubt! Ist es das nicht wird das Paket verworfen. Wenn du nun aber das IP-Forwarding aktivierst leitet HOST A das Paket zwar an Host B weiter aber Host B kennt das Subnetz von MON-SRV unter Umständen nicht (wenn es ihm nicht schon durch einen VPN-Payload bekannt gemacht wurde), deswegen müsstest du den Traffic von MON-SRV auf HOST A mit IPTables NATen (SRC-NAT, also die Quelladresse des Pakets auf die von Host A umschreiben) damit die Antworten auf die Pakete auch wieder geregelt zurückfließen, wenn du auf HOST B oder dem Tunnelendpunkt die Routingtabelle nicht modifizieren darfst/kannst.
Ganz einfache und logische Routing-Grundlagen halt.
Nun alles klar
?Grüße Uwe
Vielen Dank für eure schnelle Hilfe / Denkanstösse !!
Nachdem ich den Beitrag geschrieben hatte, kam ich auch darauf, dass ich eigentlich NATen muss.
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
IP-Forwarding hatte ich schon aktiv.
Aber so ist das manchmal .....
... mit dem Wald und den Bäumen.
Danke & Gruß
Stephen
Nachdem ich den Beitrag geschrieben hatte, kam ich auch darauf, dass ich eigentlich NATen muss.
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
IP-Forwarding hatte ich schon aktiv.
Aber so ist das manchmal .....
... mit dem Wald und den Bäumen.
Danke & Gruß
Stephen
NATen wäre aber nicht nötig gewesen wenn man dem Host B das Subnetz von Host A mit einer statischen Route hätte bekannt gemacht.
Grundlagen zu dem Thema findest du wie immer hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Es gibt eben viele Wege nach Rom...
Grundlagen zu dem Thema findest du wie immer hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Es gibt eben viele Wege nach Rom...
