Add babel filters to prevent announcing client ips used for NAT #196

New Issue

fbl · 2021-12-30T23:08:47+01:00

fbl commented

2021-12-30 23:08:47 +01:00

With the current implementation of the fff-layer3-snat package, client ips used in conjunction with snat are not explicitly filtered from being announced. It is required to use ip ranges, which are excluded from being announced anyways.

Add extra filters to prevent nat'ed client ips from being announced.

With the current implementation of the fff-layer3-snat package, client ips used in conjunction with snat are not explicitly filtered from being announced. It is required to use ip ranges, which are excluded from being announced anyways. Add extra filters to prevent nat'ed client ips from being announced.

fbl added the

layer3

label 2021-12-30 23:08:47 +01:00

ChristianD commented

2022-03-03 00:05:14 +01:00

Ich hab hier mal bisschen drüber nachgedacht.

Will man es richtig machen, müsste man eigentlich als Peering IP (oder routerip oder wie auch immer) was aus 100.64/10 nehmen für cgnat. Das kann man dann auch fest als Filter definieren (bzw. andersherum 10/8 192.168/16 und dieses 172.irgendwas was ich mir nie merken kann verbieten), natürlich nur, wenn SNAT auch an ist.

Vorteil:

Es ist technisch in meinen Augen einfach korrekt da wir nichts anderes als cgnat machen und genau dafür dieses Netz da ist.
Das hier genannte Problem ist u.U. in der Firmware recht leicht dann umzusetzen
Wenn man sich entscheidet das bei allen Peering IPs zu verwenden, bekommt man 10.50.252 und 10.83.252 mittelfristig aufgelöst und frei für normale Verwendung.

Nachteil:

Wir müssen das 100.64/10 Netz einführen und festlegen wo man es verwendet
U.U. Umbauzeug an div. Gateways (je nachdem wo man das 100.64/10 dann überall verwendet), z.b. auch bei den v2 Gateways auf den Peeringinterfaces (also überall wo aktuell einfach 10.50.252.x und 10.83.252.x verwendet wird)

Einerseits finde ich, wäre das schon schön und richtig, anderseits ist das halt v4 und da jetzt wieder alles über den Haufen werfen... ach mei ich weiß auch nicht.

Meinungen?

Ich hab hier mal bisschen drüber nachgedacht. Will man es richtig machen, müsste man eigentlich als Peering IP (oder routerip oder wie auch immer) was aus 100.64/10 nehmen für cgnat. Das kann man dann auch fest als Filter definieren (bzw. andersherum 10/8 192.168/16 und dieses 172.irgendwas was ich mir nie merken kann verbieten), natürlich nur, wenn SNAT auch an ist. Vorteil: * Es ist technisch in meinen Augen einfach korrekt da wir nichts anderes als cgnat machen und genau dafür dieses Netz da ist. * Das hier genannte Problem ist u.U. in der Firmware recht leicht dann umzusetzen * Wenn man sich entscheidet das bei allen Peering IPs zu verwenden, bekommt man 10.50.252 und 10.83.252 mittelfristig aufgelöst und frei für normale Verwendung. Nachteil: * Wir müssen das 100.64/10 Netz einführen und festlegen wo man es verwendet * U.U. Umbauzeug an div. Gateways (je nachdem wo man das 100.64/10 dann überall verwendet), z.b. auch bei den v2 Gateways auf den Peeringinterfaces (also überall wo aktuell einfach 10.50.252.x und 10.83.252.x verwendet wird) Einerseits finde ich, wäre das schon schön und richtig, anderseits ist das halt v4 und da jetzt wieder alles über den Haufen werfen... ach mei ich weiß auch nicht. Meinungen?

fbl commented

2022-03-03 01:42:08 +01:00

Meinungen?

NAK.

Wenn an irgendeiner Stelle im Freifunk so etwas ähnliches wie CGN passiert, dann sind das die Gateways zum Internet, welche die Default-Route announcen. Wenn man hier technisch "richtig" arbeiten will, dann müsste man hier für grundsätzliches alles 100.64.0.0/10 verwenden. Dafür müsste man einmal alles renumbern. Das ist quatsch.

Ohne alles zu renumbern bekommt man das Problem nicht mit statischen Regeln gelöst, denn es soll auch Router ohne NAT geben.

Außerdem bricht dann das ICVPN und weiß der Teufel was noch alles. Es gibt hier imho keinen Anlass für IPv4 noch irgendwelche Arbeit zu machen, weil es "sauberer" wäre.

Ist aber alles auch kein Thema, denn eigentlich muss layer3-config nur eine passende Regel (analog zu den von dir vorgeschlagenen statischen Regeln) für jedes Prefix erzeugen, welches auf einem Client-Interface mit fff-nat '1' hängt. Fertig. :-)

> Meinungen? NAK. Wenn an irgendeiner Stelle im Freifunk so etwas ähnliches wie CGN passiert, dann sind das die Gateways zum Internet, welche die Default-Route announcen. Wenn man hier technisch "richtig" arbeiten will, dann müsste man hier für grundsätzliches alles 100.64.0.0/10 verwenden. Dafür müsste man einmal alles renumbern. Das ist quatsch. Ohne alles zu renumbern bekommt man das Problem nicht mit statischen Regeln gelöst, denn es soll auch Router ohne NAT geben. Außerdem bricht dann das ICVPN und weiß der Teufel was noch alles. Es gibt hier imho keinen Anlass für IPv4 noch irgendwelche Arbeit zu machen, weil es "sauberer" wäre. Ist aber alles auch kein Thema, denn eigentlich muss layer3-config nur eine passende Regel (analog zu den von dir vorgeschlagenen statischen Regeln) für jedes Prefix erzeugen, welches auf einem Client-Interface mit `fff-nat '1'` hängt. Fertig. :-)

ChristianD commented

2022-03-03 09:36:09 +01:00

Meinungen?

NAK.

Wenn an irgendeiner Stelle im Freifunk so etwas ähnliches wie CGN passiert, dann sind das die Gateways zum Internet, welche die Default-Route announcen. Wenn man hier technisch "richtig" arbeiten will, dann müsste man hier für grundsätzliches alles 100.64.0.0/10 verwenden. Dafür müsste man einmal alles renumbern. Das ist quatsch.

Wenn ich dich richtig verstehe, war genau das meine Idee. Die ganzen Peering IPs müssten 100.64/10 sein (also alles was aktuell auf 10.50.252 und 10.83.252 ist renumbern) und ja man müsste dann alles renumbern das ist genau der große Nachteil an der Idee.

Ohne alles zu renumbern bekommt man das Problem nicht mit statischen Regeln gelöst, denn es soll auch Router ohne NAT geben.

ja und nein, also ja natürlich gibts Router ohne NAT, aber man kann dann nen einfachen Fallunterschied machen:
Kein NAT: Nehm die Regeln wie bisher
NAT: Nehm die Regeln für 100.64/10

Außerdem bricht dann das ICVPN und weiß der Teufel was noch alles. Es gibt hier imho keinen Anlass für IPv4 noch irgendwelche Arbeit zu machen, weil es "sauberer" wäre.

ICVPN bricht mit NAT sowieso schon eingehend (also ICVPN => Freifunk Franken) und aus dem ICVPN den Router zu erreichen der CGNAT macht, macht jetzt auch nicht soooviel Sinn. Welcher Teufel noch bin ich mir gerade unsicher, kann natürlich sein das da noch Dinge kaputt gehen.

Und ja diese "keine Arbeit" da mehr rein stecken, sehe ich durchaus auch. Daher nur ne Idee.

> > Meinungen? > > NAK. > > Wenn an irgendeiner Stelle im Freifunk so etwas ähnliches wie CGN passiert, dann sind das die Gateways zum Internet, welche die Default-Route announcen. Wenn man hier technisch "richtig" arbeiten will, dann müsste man hier für grundsätzliches alles 100.64.0.0/10 verwenden. Dafür müsste man einmal alles renumbern. Das ist quatsch. Wenn ich dich richtig verstehe, war genau das meine Idee. Die ganzen Peering IPs müssten 100.64/10 sein (also alles was aktuell auf 10.50.252 und 10.83.252 ist renumbern) und ja man müsste dann alles renumbern das ist genau der große Nachteil an der Idee. > > Ohne alles zu renumbern bekommt man das Problem nicht mit statischen Regeln gelöst, denn es soll auch Router ohne NAT geben. ja und nein, also ja natürlich gibts Router ohne NAT, aber man kann dann nen einfachen Fallunterschied machen: Kein NAT: Nehm die Regeln wie bisher NAT: Nehm die Regeln für 100.64/10 > > Außerdem bricht dann das ICVPN und weiß der Teufel was noch alles. Es gibt hier imho keinen Anlass für IPv4 noch irgendwelche Arbeit zu machen, weil es "sauberer" wäre. ICVPN bricht mit NAT sowieso schon eingehend (also ICVPN => Freifunk Franken) und aus dem ICVPN den Router zu erreichen der CGNAT macht, macht jetzt auch nicht soooviel Sinn. Welcher Teufel noch bin ich mir gerade unsicher, kann natürlich sein das da noch Dinge kaputt gehen. Und ja diese "keine Arbeit" da mehr rein stecken, sehe ich durchaus auch. Daher nur ne Idee.

fbl commented

2022-03-03 10:29:26 +01:00

Die ganzen Peering IPs müssten 100.64/10 sein (also alles was aktuell auf 10.50.252 und 10.83.252 ist renumbern)

Eben nicht. Wenn man das so macht, dann müsste eigentlich alles innerhalb des babel-Netzes 100.64.0.0/10 sein, damit das überhaupt irgendeinen Vorteil bringt. Und das funktioniert eigentlich nur, wenn alle Router nochmal NAT machen, ansonsten ist das ja eigentlich auch kein Carrier-grade NAT. In letzterem Fall würde man dann bei nicht-NAT Routern ja auch 100.64.0.0/10 Adressen an Clients geben.

ja und nein, also ja natürlich gibts Router ohne NAT, aber man kann dann nen einfachen Fallunterschied machen:
Kein NAT: Nehm die Regeln wie bisher
NAT: Nehm die Regeln für 100.64/10

Router ohne NAT: siehe oben.
Wenn man eh immer noch ne Fallunterscheidung braucht, dann kann man auch einfach statt der allgemeinen Regeln (die dann ja eh nicht mehr statisch sind) auch gleich wie oben beschriebenen die korrekten Regeln einfügen.

Ich sehe von diesem Vorhaben jetzt ehrlich gesagt weder einen technischen Vorteil, noch warum das sauberer wäre.

> Die ganzen Peering IPs müssten 100.64/10 sein (also alles was aktuell auf 10.50.252 und 10.83.252 ist renumbern) Eben nicht. Wenn man das so macht, dann müsste eigentlich **alles** innerhalb des babel-Netzes 100.64.0.0/10 sein, damit das überhaupt irgendeinen Vorteil bringt. Und das funktioniert eigentlich nur, wenn alle Router nochmal NAT machen, ansonsten ist das ja eigentlich auch kein Carrier-grade NAT. In letzterem Fall würde man dann bei nicht-NAT Routern ja auch 100.64.0.0/10 Adressen an Clients geben. > ja und nein, also ja natürlich gibts Router ohne NAT, aber man kann dann nen einfachen Fallunterschied machen: > Kein NAT: Nehm die Regeln wie bisher > NAT: Nehm die Regeln für 100.64/10 Router ohne NAT: siehe oben. Wenn man eh immer noch ne Fallunterscheidung braucht, dann kann man auch einfach statt der allgemeinen Regeln (die dann ja eh nicht mehr statisch sind) auch gleich wie oben beschriebenen die korrekten Regeln einfügen. Ich sehe von diesem Vorhaben jetzt ehrlich gesagt weder einen technischen Vorteil, noch warum das sauberer wäre.

fbl added this to the 20220405-beta milestone 2022-03-03 15:49:48 +01:00

fbl referenced a pull request that will close this issue

2022-03-06 10:33:01 +01:00

fff-babeld: create filter for prefixes used with snat #214

fbl referenced this issue from a commit

2022-03-11 13:35:17 +01:00

fff-babeld: create filter for prefixes used with snat

fbl closed this issue

2022-03-11 13:35:17 +01:00

Sign in to join this conversation.