Hallo Heiko, On Tue, Mar 19, 2019 at 21:46:21 +0100, Heiko Schlittermann wrote:
> > Ich sehe das aber auch eher als Fehlkonfiguration an, weil es wie gesagt > > eine Grundfunktion von IP (Path-MTU-Discovery) kaputtmacht. > > Ich meine, es muss nicht grundsätzlich am bösen Willen oder der Dummheit > der Transfer-Admins liegen. Es kann z.B. auch am Eingreifen des > Reverse-Path-Verify liegen. > > HOME ----------- ROUTER ------------ R1 ---------------- R2 ---- > 192.168.0.0/24 öff. Netz Transfernetz öff. Netz > 192.168.0.0/24 > > Wenn R2 jetzt ein Problem (Frag. needed, TTL excceeded) feststellt, wird > er dieses an die für ihn sichtbare Absender-IP (ext. Interface des > Homerouters) senden. Der Absender dieser ICMP-Nachricht ist vermutlich > das transfernetzseitige Bein von R2, oder? Ja. Lokal erzeugter Traffic, fuer den die Route keine explizite Absender-Adresse vorgibt, erhaelt als Absender-Adresse die des Interfaces, ueber das er versendet wird. Kann auch schoen mit ip route get DEST_IP pruefen. > Dann … selbst wenn es dieses Paket bis zum Homerouter schafft, besteht > die Möglichkeit, daß der es wegen rp_filter (reverse path filter/verify) > verwirft, weil der meint, daß solche Absender nur auf seinem inneren > Interface auftauchen dürfen. Okay, sowas ist denkbar, aber eher unwahrscheinlich. Und es zeigt, dass rp_filter mir Vorsicht zu geniessen ist. Spaetestens wenn man mit Tunneling-Szenarien zu tun hat, will man rp_filter eher nicht anschalten. Gruesse, Christian -- Christian Perle chris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing
