Subnet Routing 27-Netz über VPN in 2x 28 -Netz
Hallo zusammen
Ich stehe vor folgendes Problem:
Ich bekomme auf eine Debian Maschine über eine OpenVPN Tunnel ein /27 - Subnet geroutet. Dieses würde ich gerne über 2 Standorte via VPN (OpenVPN) aufteilen.
Subnet / 27 => (tun1) Debian 1 wo mir an ens224 das 1. Subnet /28 ausgibt => Subnet /28 (tun1) Debian 2 wo mir an ens256 das 2. Subnet /28 ausgibt.
Anbei mal eine Skizze wie das aussehen sollte. Eigentlich müsste das doch so funktionieren?
Ich habe das Problem mit den Routing/Iptables Regel auf den zwei Maschinen.
Kann mir dabei jemand dabei helfen?
Momentan führe ich nach Verbindungsaufbau folgendes Regelwerk aus:
auf Maschine Standort 1:
ip route add 46.xxx.xxx.240/28 via 10.98.243.2
ip route add default table 10 dev tun1 metric 0
ip rule add from 46.xxx.xxx.224/28 to all prio 0 table 10
ip rule add from 46.xxx.xxx.240/28 to all prio 2 table 10
ip rule add from 10.98.243.2/32 to all prio 3 table 10
ip rule add from all to 46.xxx.xxx.240/28 prio 1 dev tun0
ip rule add from 2a02:xxx:xxx:xxx::0/56 to all prio 9999 table 10
ip -6 route add default dev tun1 metric 1
auf Maschine Standort 2:
ip route add 46.xxx.xxx.224/28 via 10.98.243.1
ip route add default table 10 dev tun0 metric 10
ip rule add from 46.xxx.xxx.240/28 to all prio 9992 dev tun0
ip rule add from all to 46.xxx.xxx.240/28 prio 30 dev ens256
ip route add from all to 10.99.99.0/24 prio 9997 dev ens224
ip.forwading ist auf beiden Eingeschaltet.
An Standort 1 mit dem /28 funktioniert es aber das andere /28 Netz an Standort 2 ist von aussen nicht erreichbar.
Grüsse
Ich stehe vor folgendes Problem:
Ich bekomme auf eine Debian Maschine über eine OpenVPN Tunnel ein /27 - Subnet geroutet. Dieses würde ich gerne über 2 Standorte via VPN (OpenVPN) aufteilen.
Subnet / 27 => (tun1) Debian 1 wo mir an ens224 das 1. Subnet /28 ausgibt => Subnet /28 (tun1) Debian 2 wo mir an ens256 das 2. Subnet /28 ausgibt.
Anbei mal eine Skizze wie das aussehen sollte. Eigentlich müsste das doch so funktionieren?
Ich habe das Problem mit den Routing/Iptables Regel auf den zwei Maschinen.
Kann mir dabei jemand dabei helfen?
Momentan führe ich nach Verbindungsaufbau folgendes Regelwerk aus:
auf Maschine Standort 1:
ip route add 46.xxx.xxx.240/28 via 10.98.243.2
ip route add default table 10 dev tun1 metric 0
ip rule add from 46.xxx.xxx.224/28 to all prio 0 table 10
ip rule add from 46.xxx.xxx.240/28 to all prio 2 table 10
ip rule add from 10.98.243.2/32 to all prio 3 table 10
ip rule add from all to 46.xxx.xxx.240/28 prio 1 dev tun0
ip rule add from 2a02:xxx:xxx:xxx::0/56 to all prio 9999 table 10
ip -6 route add default dev tun1 metric 1
auf Maschine Standort 2:
ip route add 46.xxx.xxx.224/28 via 10.98.243.1
ip route add default table 10 dev tun0 metric 10
ip rule add from 46.xxx.xxx.240/28 to all prio 9992 dev tun0
ip rule add from all to 46.xxx.xxx.240/28 prio 30 dev ens256
ip route add from all to 10.99.99.0/24 prio 9997 dev ens224
ip.forwading ist auf beiden Eingeschaltet.
An Standort 1 mit dem /28 funktioniert es aber das andere /28 Netz an Standort 2 ist von aussen nicht erreichbar.
Grüsse
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 497241
Url: https://administrator.de/forum/subnet-routing-27-netz-ueber-vpn-in-2x-28-netz-497241.html
Ausgedruckt am: 15.05.2025 um 06:05 Uhr
5 Kommentare
Neuester Kommentar
Das kann so nicht gehen. Sieh selber mal hin, dann wirst du das auch sehen.
Knackpunkt ist das .224 /27 er Netz ! Das kannst du nicht weiter subnetten !! Theoretisch zwar schon aber dann musst du beide Subnetzmasken auf /28 abändern !
Links kommt ja das .224er Subnetz mit einem /27er Prefix also den Hostadressen .225 bis .254. auf das Tunnel Interface am linken Rechner.
Das .224 /27er Subnetz inkludiert ja aber das .224 /28 !
Für das linke Tunnelinterface sind also folglich die /28 er Hostadressen .225 bis .238 ja dann Teil ihres eigenen /27er Netzes. Routing bzw. eine eindeutige Wegefindung ist damit dann unmöglich.
Du hast nur eine Möglichkeit das zu fixen und zwar das Tunnelinterface links auch auf einen /28er Prefix zu setzen.
Damit hast du dann sauber das /27er in 2 separate /28 er aufgeteilt.
Rechts ist es auch falsch ! Das Netzwerk 46.x.x.240 /28 ist da ja doppelt vergeben !
Das müsste wenn dann 46.x.x.224 /28 und 46.x.x.240 /28 lauten, ansonsten ist hier auch Routing unmöglich.
Das geht jetzt davon aus das das ".xx.xx" in der Mitte der netzwerk IP Adresse immer gleich ist ?!
Knackpunkt ist das .224 /27 er Netz ! Das kannst du nicht weiter subnetten !! Theoretisch zwar schon aber dann musst du beide Subnetzmasken auf /28 abändern !
Links kommt ja das .224er Subnetz mit einem /27er Prefix also den Hostadressen .225 bis .254. auf das Tunnel Interface am linken Rechner.
Das .224 /27er Subnetz inkludiert ja aber das .224 /28 !
Für das linke Tunnelinterface sind also folglich die /28 er Hostadressen .225 bis .238 ja dann Teil ihres eigenen /27er Netzes. Routing bzw. eine eindeutige Wegefindung ist damit dann unmöglich.
Du hast nur eine Möglichkeit das zu fixen und zwar das Tunnelinterface links auch auf einen /28er Prefix zu setzen.
Damit hast du dann sauber das /27er in 2 separate /28 er aufgeteilt.
Rechts ist es auch falsch ! Das Netzwerk 46.x.x.240 /28 ist da ja doppelt vergeben !
Das müsste wenn dann 46.x.x.224 /28 und 46.x.x.240 /28 lauten, ansonsten ist hier auch Routing unmöglich.
Das geht jetzt davon aus das das ".xx.xx" in der Mitte der netzwerk IP Adresse immer gleich ist ?!
Hallo aqui
Vielen Dank erstmal für deine Antwort.
Ich glaube ich habe ein kleinen Fehler in der Skizze. Die IP (mit 164 am Ende) welche im Tunnel reinkommt und an das Interface tun1 gebunden ist hat die netmask 255.255.252.0 und fällt nicht in das /27 Netz.
Ich habe auch mal beim Provider angefragt ob das Grundsätzlich geht, laut seiner Aussage geht das:
...das ist kein Problem, das Netz kann durch Sie beliebig aufgeteilt werden - auch in /32-Routen, wenn es notwendig ist
Wir routen das 46.xx.xx.224/27 zu Ihrem Router, wie der dann auf Basis seiner lokalen Routingtabelle weiter verfährt, ist dann seine Sache.
...
Es sollte nur ggf. sichergestellt sein, dass an den beteiligten Routern eine Nullroute mit schlechter Metrik für das gesamte /27 existiert, da sonst, wenn z.B. Tun0 einmal nicht aufgebaut ist, keine Routing-Loops entstehen.
Die spezifischeren /28-Routen (oder länger) überschreiben die Nullroute ja in jedem Fall, solange sie existieren.
Vielen Dank erstmal für deine Antwort.
Ich glaube ich habe ein kleinen Fehler in der Skizze. Die IP (mit 164 am Ende) welche im Tunnel reinkommt und an das Interface tun1 gebunden ist hat die netmask 255.255.252.0 und fällt nicht in das /27 Netz.
Ich habe auch mal beim Provider angefragt ob das Grundsätzlich geht, laut seiner Aussage geht das:
...das ist kein Problem, das Netz kann durch Sie beliebig aufgeteilt werden - auch in /32-Routen, wenn es notwendig ist
Wir routen das 46.xx.xx.224/27 zu Ihrem Router, wie der dann auf Basis seiner lokalen Routingtabelle weiter verfährt, ist dann seine Sache.
...
Es sollte nur ggf. sichergestellt sein, dass an den beteiligten Routern eine Nullroute mit schlechter Metrik für das gesamte /27 existiert, da sonst, wenn z.B. Tun0 einmal nicht aufgebaut ist, keine Routing-Loops entstehen.
Die spezifischeren /28-Routen (oder länger) überschreiben die Nullroute ja in jedem Fall, solange sie existieren.
Die IP-Adresse 46.xx.0.164, welche direkt auf Tun1 gebunden ist, ist für das Routing zwischen dem Provider und dir interessant (auf diese IP wird der Provider dir das Netz routen), aber für das Routing zu Standort 2 hat sie keine Auswirkungen mehr.
Diese IP dient letztlich nur dazu, dass eine Kommunikation zwischen deinem Router und dem Provider stattfinden kann.
Versuche mal die Regeln
nicht direkt auf tun0 zeigen zu lassen sondern auf die Gegenstellen-IP, bspw.:
Ansonsten lausche mal mit tcpdump an tun0 von Standort 1, ob du dort ausgehende Pakete siehst.
Wenn je, prüfe an Standort 2, ob du die Pakete auf tun0 ebenfalls siehst u.s.w.
Eine einfache tcpdump-Regel dazu wäre:
Damit kannst du dann sehen, ob die Pakete überhaupt ankommen und ob sie evtl. über ein unerwartetes Interface wieder hinaus gehen. Und du siehst natürlich auch, in welche Richtung es klemmt.
Diese IP dient letztlich nur dazu, dass eine Kommunikation zwischen deinem Router und dem Provider stattfinden kann.
Versuche mal die Regeln
# Standort 1
ip rule add from all to 46.xxx.xxx.240/28 prio 1 dev tun0
# Standort 2
ip route add default table 10 dev tun0 metric 10
ip rule add from 46.xxx.xxx.240/28 to all prio 9992 dev tun0nicht direkt auf tun0 zeigen zu lassen sondern auf die Gegenstellen-IP, bspw.:
ip rule add from all to 46.xxx.xxx.240/28 prio 1 via 10.98.243.2 dev tun0Ansonsten lausche mal mit tcpdump an tun0 von Standort 1, ob du dort ausgehende Pakete siehst.
Wenn je, prüfe an Standort 2, ob du die Pakete auf tun0 ebenfalls siehst u.s.w.
Eine einfache tcpdump-Regel dazu wäre:
tcpdump -nn -i tun0 "net 46.xx.xx.240/28 && not port 22" Damit kannst du dann sehen, ob die Pakete überhaupt ankommen und ob sie evtl. über ein unerwartetes Interface wieder hinaus gehen. Und du siehst natürlich auch, in welche Richtung es klemmt.
Zitat von @Kufstein:
ip.forwading ist auf beiden Eingeschaltet.
An Standort 1 mit dem /28 funktioniert es aber das andere /28 Netz an Standort 2 ist von aussen nicht erreichbar.
ip.forwading ist auf beiden Eingeschaltet.
An Standort 1 mit dem /28 funktioniert es aber das andere /28 Netz an Standort 2 ist von aussen nicht erreichbar.
Der wesentliche Knackpunkt ist, daß auf dem VPN-Router auf Standort 2 eine Source-Route für das Netz 46.xxx.xxx.240/28 auf den VPN-Router an Standort 1 gesetzt sein muß.
Wie sieht denn die Routingtabelle jeweils auf den Routern in Standort 1 und Standort 2 aus?
ich würde an Standort 2 einfach einen tcpdump oder wireshark an allen Interfaces mitlaufen lassen und schauen, welchen Weg die Pakete gehen.
lks
Hab das nun lösen können. Woran es genau gelegen hat, kann ich leider nicht sagen (so wie es aussieht am Standort 2).
Zuerst war es nur von Standort 2 nach Standort 1 pingbar aber nicht andersrum.
Ich habe nochmals alle iptables-Einträge alle PBR-Einträge und alle routen gelöscht und anschließend alles neu eingetragen.
Jetzt scheint es zu funktionieren.
Vielen Dank alle für die Tipps.
Zuerst war es nur von Standort 2 nach Standort 1 pingbar aber nicht andersrum.
Ich habe nochmals alle iptables-Einträge alle PBR-Einträge und alle routen gelöscht und anschließend alles neu eingetragen.
Jetzt scheint es zu funktionieren.
Vielen Dank alle für die Tipps.
