Hallo Ronny, ich denke, Du hast Dir das ja inzwischen selbst beantwortet … Ein paar Bemerkungen hätte ich trotzdem noch.
Ronny Seffner <[email protected]> (Mi 04 Apr 2012 10:44:46 CEST): > heute habe ich mal netzwerktechnisch ein Problem, welches ich mit > vorhandenem Wissen offenbar nicht lösen kann und hoffe hier kann mir > geholfen werden: > > Gegeben ist ein Linuxrechner mit iproute2 und netfilter, der zwei ppp > interfaces hat. > ppp0 unterliegt dynamischer IP-Zuweisung > ppp1 bekommt eine feste IP 1.2.3.4 und einen P-t-P 11.22.33.44 > eth0 ist die LAN-Seite mit 3.3.3.1 > die default Route ist über ppp0 gesetzt > > Erreicht werden soll nun, dass HTTPS-Anfragen an ppp1 (also 1.2.3.4) an > einen Rechner im LAN (3.3.3.33) weitergeleitet werden. Das ist ohne zu > Denken mittels iptables, PREROUTING und DNAT ganz einfach aufgesetzt, aber > so gehen die Antwortpakete ja über ppp0 raus und wir haben einen reichlich > undefinierten Zustand. Nein, undefiniert ist das nicht. Es könnte aber sein, daß Dein Linux-Rechner die Weiterleitung schon verweigert, falls das „reverse path verify“ eingeschaltet ist. Dann das verweigert die Annahme der Pakete, sobald das In-Interface nicht dem Out-Interface für die Antworten entsprechen würde. Und wenn Deiner das nicht macht, dann ist es recht wahrscheinlich, daß irgendwo da draußen jemand der Meinung ist, das wäre illegal, oder irgend eine stateful Firewall ist durcheinander, weil vielleicht ein halber State fehlt. > Sowas hatte ich schon. Gelöst wie folgt: > echo "88 https" >> /etc/iproute2/rt_tables > ip route add 1.2.3.4/32 dev ppp1 src 1.2.3.4 table https Ich meine, die obige Route ist nicht notwendig. > ip route add default via 11.22.33.44 dev ppp1 table https > ip rule add from 1.2.3.4/32 table https > ip rule add to 1.2.3.4/32 table https … ebenso wie diese ^ > ip route flush cache > Offenbar wirkt sich das aber nur sinnvoll auf alles aus, was an an/von lo > kommt/geht - bzw. funktioniert das im Zusammenhang mit dem PREROUTING und > DNAT nicht mehr, denn tcpdump zeigt mit noch immer die Antworten zur > Weiterleitung auf ppp0. > > Mit iproute und speziellen Protokollen/Ports hatte ich auch schon mal was > gemacht: > ip rule add fwmark 84 table 84 > ip route add default via 11.22.33.44 dev ppp1 table 84 > und > iptables -t mangle -A PREROUTING ... -j MARK -set-mark=84 > In meinem Verständnis werden hier Pakete durch iptables markiert und für > diese Markierung gilt eine eigene Routingtable. Jenau. > Nun glaube ich, muss ich für meinen Anwendungsfall, dass eingehendes HTTPS > an ppp1 an den Rechner im LAN geforwarded werden soll und die Antworten dazu > auch über ppp1 wieder raus müssen, sämtlicher anderer HTTPS Verkehr > (LAN2WAN, WAN2ppp0) aber weiterhin über ppp0 abgewickelt werden soll, wohl > beide Varianten "verheiraten". Nur gelingt mir das nicht. Du könntest nach CONNMARK gucken, und eingehende Verbindungen auf dem ppp1 Interface „connmarken“ (was für ein Wort). Und dann, wenn die Antworten von innen wiederkommen, haben werden sie automagisch „conngemarkt“. > Der erste Teil ist wohl eher unstrittig, weil er funktioniert. Seit ich das > eingerichtet habe, geht auch ICMP und SSH auf ppp1 ;-) > Warum sehe ich aber trotz Umsetzung des zweiten Teils immer noch ausgehende > Antworten auf ppp0, wenn ich HTTPS versuche zu erreichen? Weil wir paketvermittelt arbeiten. Ein Paket von innen nach außen hat nichts mit den Paketen in die andere Richtung zu tun, also wird in der Default-Routing-Tabelle nachgeschaut. Außer, Du hast etwas mit CONNMARK gemacht oder Du markierst die von Deinem internen Kasten kommenden (IP + Port) und verwendest dann eine entsprechende Routing-Rule. (Auch bei CONNMARK musst Du natürlich noch eine entsprechende Rule haben.) > Ich glaube hier immer noch über DNAT zu stolpern, denn: > tcpdump an ppp1 sieht: > client-ip:highport -> 1.2.3.4:443 - die eigentliche Anfrage > client-ip:highport -> 3.3.3.33:443 - das DNAT > tcpdump an eth0 sieht: > client-ip:highport -> 3.3.3.33:443 - das DNAT/FORWARD ins LAN hat > funktioniert > 3.3.3.33:443 -> client-ip:highport - die Antwort geht raus > tcpdump an ppp0 sieht leider: > 1.2.3.4:443 -> client-ip:highport - Maskierung, auf ppp0 mit der IP von > ppp1? > > Verliere ich durch DNAT das mark=84? Wie mache ich es richtig? Wie Du es ja schon rausgefunden hast, oder CONMARK. (Oder hattetst Du sogar CONNMARK?) CONNMARK hätte den Vorteil, auch für „related“ zu gelten. -- Heiko
signature.asc
Description: Digital signature
_______________________________________________ Lug-dd maillist - [email protected] https://ssl.schlittermann.de/mailman/listinfo/lug-dd
