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