mpd5 & PPPoE als Internet Gateway

Also man braucht eigentlich immer nen defaultrouter Eintrag.
Mit Ausnahme von ppp soweit ich weiss und irgendwie scheint die fw bei dir
in der rc.conf auskommentiert zu sein.
 
Danke soweit ;) ... sind schon nahe am Ziel .. an dem Auskommentierten in der rc.conf hats gelegen. Ich dachte das würde sich erübrigen, wenn man das schon über die OPTIONS fest im Kernel hat fix im Kernel drin hat .. also zumindest das mit IPFW?!

Wenn ich mich nun per PPPoE auf den Server verbinde und google.de / oder eine andere IP die hinter der rl0 Netzwerkkarte am PPPoE Server pinge funktioniert das auch soweit, bis auf das, dass ich leider nur EINE Antwort bekomme.

Code:
MacBook-Pro:~ Leander$ ping google.de
PING google.de (216.239.59.104): 56 data bytes
64 bytes from 216.239.59.104: icmp_seq=0 ttl=243 time=93.929 ms
^C
--- google.de ping statistics ---
6 packets transmitted, 1 packets received, 83% packet loss
round-trip min/avg/max/stddev = 93.929/93.929/93.929/0.000 ms
MacBook-Pro:~ Leander$

und dann bleibt er stecken .. muss das ganze also mit STRG und C beenden ... bei wiederholung passiert dasselbe ...

Irgendwo fehlt mir also noch ne Kleinigkeit - hast du noch ne Idee?

LG,

Leander
 
Zuletzt bearbeitet:
Mein Fehler ..glaube ich:


case ${firewall_type} in
[Oo][Pp][Ee][Nn])
${fwcmd} add 100 divert natd ip from any to any in via rl0
${fwcmd} add 110 divert natd ip from any to any out via rl0
${fwcmd} add 65000 pass all from any to any
;;

Sollte ja besser in beide Richtungen funzen.
 
ja-woll daran scheints gelegen zu haben! ;)

Vielen Dank für deine Mühen!


LG,

Leander
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

ein kleines Problem scheine ich aber dennoch zu haben ...

Clients sind nun in der Lage beispielsweiße Google zu öffnen bla bla .. aber z.B. unixboard.de geht schon nicht mehr . auch andere Seiten ... ein paar gehen ein paar nciht ...
Mein erster Gedanke war evtl eine fehlerhafte Namensauflösung durch nen schlechten DNS Server den ich in mpd angeben musste ... aber das kann nciht sein, denn pingen kann ich sämtliche Adressen .. nur beim http scheints manchmal etwas zu stocken bis gar nciht zu gehen ?!

Woran könnte das liegen?

LG,

Leander
 
Zuletzt bearbeitet:
Für mich hört sich das aber schon nach nem dns-Prob an.
Pingen kann man schliesslich immer auch ohne dns. (zumindest die ips)

http://www.techarsenal.com/content/tutorials/router_from_scratch.htm#sec4
Guck mal da.

ich benutz eigentlich immer den dns von dyndns.org:
213.155.150.205 Deutschland
63.208.196.90 USA

Mit denen hatte ich noch nie Probleme.



Edit: vergiss es hatte überlesen das du die adressen pingen kannst.

Edit2: Ich kann mir eigentlich nur noch vorstellen das die Bandlim im mpd ins Kraut schiesst.
Dummerweise hab ich vom mpd absolut keinen Plan.

Nur so aus Neugier warum nicht pppoed?


Edit3: wirf mal nen Blick darauf:
http://www.gsp.com/cgi-bin/man.cgi?section=4&topic=dummynet
oder auch:
http://cs.ecs.baylor.edu/~donahoo/tools/dummy/tutorial.htm

So mach ich das jedenfalls.
 
Zuletzt bearbeitet:
1. Weil ich für PPPoEd nichts gefunden habe, dass ich gleich in einem Rutsch wie bei mpd RADIUS Attribute zur Bandlim für IPFW mitgeben kann. das müsste ich dann also immer extra machen, oder mir was anderes einfallen lassen wie z.B. über die Netzmaske .... das gefällt mir aber ncht ganz so deshalb hat mir mpd da eigentlich schon sehr zugesagt.

2. Dann habe ich Erfahrungsberichten zufolge einfach beinahe ausschließlich nur besseres von mpd gehört was den ISP Berreich angeht ... bessere Performance unter sehr hoher Last, ... etc. ...

3. sehr stabil ... sehr vielseitig einsetzbar ... mpd wird ständig weiterentwickelt, flexibilität, bla bla ;)

Falls dir bei PPPoEd da was zu der Bandwidthlimitierung über den RADIUS einfällt bin ich gerne offen den uch mal genauer unter di Lupe zu nehmen ...


Edit2: Ich kann mir eigentlich nur noch vorstellen das die Bandlim im mpd ins Kraut schiesst.
Dummerweise hab ich vom mpd absolut keinen Plan.

... Das mit der Bandwidthlimitierung hat ja in erster Linie (soweit ich das weiß) nichts mit mpd zu tun ... mpd übergibt die Attribute auch nur direkt weiter an IPFW ... wenn dan wäre es also was mit IPFW bzw. Dummynet ... ?!

LG
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

Btw. ... hinter die beiden Optionen bin ich ncoh nciht gestiegen .. ?

NMBCLUSTERS - set the amount of network packet buffers
HZ - sets the timer granularity



LG
 
Zuletzt bearbeitet:
Jo wie du schon gesagt hast, die Bandlim bzw. Pipes finden
nur in der fw statt. Aber ich habe leider keinen blassen Dunst
warum du nur auf jede 2te Seite kommst. Sowas ist mir
noch nie passert. Ich denk aber weiter drüber nach.:D
Bin bloss leider im Moment am wühlen.
 
das ist TOTAL strange ;) ich komme NUR auf Google.de ... kann von dort aus auch suchen ... die Suchergebnisse aber NICHT öffnen ... nur aus dem Google-Cache heraus ;) ... also kein Browser Cache Problem ...

Kann beispielsweiße heise.de pingen ... die Seite aber nicht aufrufen ;) also auch kein DNS Problem ... Er fordert die Seite mit dem Browser zwar an ... er wartet dann aber auf eine Rückantwort der entsprechenden Seite die er aber leider nicht bekommt ...
Ist wie mit dem Pingen - er bekommt nämlich scheinbar ein bestätigungs Paket, es geht dann eben nur nicht weiter ... ;)

Krieg ich da evtl. mehr über die Firwall ogs heraus?! Ich habe das Gefühl, dass da was gewaltig misskonfiguriert ist ;) irgendwas wird da geblockt ...

Strange ;) ist mir auch noch nie so ergangen ;) ...




[EDIT]

Ok .. ich meine das Problem gefunden zu haben .... es ist der RADIUS Server, der die Attribute nicht korrekt an den mpd weitergibt ...
das passiert aber nur, wenn ich deren "DialupAdmin" Webinterface zum Benutzer erstellen verwende ...was es dann wiederum weiter an meine PostgreSQL RADIUS Datenbank übergibt ... wenn ich die Attribute aber von Hand in die RADIUS users.conf eintrage, dann haut alles so hin - und BW Limiting + Internet sharing funktioniert wie geplant ...

Ich muss mir also deren Webinterface und meine Einträge in Postgre nochmals genauer unter die Lupe nehmen ... da läuft irgendwas schief ... sodass IPFW die Regeln in einer falschen Reihenfolge erhält und deshalb auch mist macht ... von den Regeln der FW sollte ansonsten alles so passen wie du mir das gesagt hast.

... finds aber trotzdem noch immer verdammt strange, dass in dem Fall nur Google geht ... magic ;)
 
Zuletzt bearbeitet:
Ein Schuss ins blaue
versuch mal
natd_flags="-m" in der rc.conf
 
Hi Dirrch,

danke für deine Mühen ;) , aber ich habe wie schon im Forum erwähnt festgestellt woran es gelegen hat.

Folgendes Problem war:

Ich benutze doch mpd, daran FreeRADIUS, und FreeRADIUS mit PostgreSQL. Um nich ständig übers Terminal Benutzer anlegen zu müssen benutze ich DialupAdmin (http://www.freeradius.org/dialupadmin.html) was sogesehen ganz cool, aber fucking buggy und unfertig ist.

Was das mit IPFW zu tun hat?
... naja, wenn ich nun hergehe und einen Benutzer wie konservativ üblich einfach von Hand über das Terminal mit vi folgendermaßen in die /usr/local/etc/raddb/user eintrage:

Code:
[root@wisp ~]# cat /usr/local/etc/raddb/users
test    User-Password == "schaefer"
        Service-Type = Framed-User,
        Framed-Protocol = PPP,
        Framed-IP-Address = 1.2.3.4,
        Framed-IP-Netmask = 255.255.255.255,
        Framed-Routing = Broadcast-Listen,
        Framed-Filter-Id = "std.ppp",
        Framed-MTU = 1492,
        Framed-Compression = Van-Jacobsen-TCP-IP,
    mpd-table += "1=11.1.11.1",
    mpd-table += "1=1.2.3.4",
    mpd-pipe += "1=bw 10Kbyte/s",
    mpd-pipe += "5=bw 20Kbyte/s",
    mpd-rule += "1=pipe %p1 all from any to table\\(%t1\\) in", 
    mpd-rule += "2=pipe %p5 all from table\\(%t1\\) to any out",
    mpd-rule += "100=allow all from any to any",

^^ dann übergibt der RADIUS die IPFW Regeln genau so wie erwünscht an den mpd.

WENN ich jetzt ABER, das ganze über Dialup Admin mache - was ja mein Ziel ist, damit jeder Dummie später Benutzer über das Webinterface anlegen kann ;), habe ich das Problem, dass das Dialup Admin (FreeRADIUS-)Webinterface diese Attribute schon a) nicht ganz korrekt in die Postgres Datenbank einträgt und b) es dann auch nicht erfolgreich an den mpd weiter übergeben werden kann.
In unserem Google Problem fall hat er beispielsweiße nur folgende Regeln an den mpd übergeben:

(ganz problematisch sind diese Backslashes mit denen der Dialup Admin mal keinen Meter umgehen kann, die ich aber dringend benötige, da es ja später Shell Befehle sind ...)

(Auszug aus der mpd Log mit dem von Dialup Admin fehlerhaft angelegten Benutzer:)

Code:
[rl0-3] RADIUS: rec'd RAD_ACCESS_ACCEPT for user leander
[rl0-3] RADIUS: RadiusGetParams: RAD_FRAMED_IP_ADDRESS: 255.255.255.254
 we should choose an address
[rl0-3] RADIUS: RadiusGetParams: RAD_FRAMED_MTU: 576
[rl0-3] RADIUS: RadiusGetParams: (RAD_SERVICE_TYPE: 2)
[rl0-3] RADIUS: RadiusGetParams: (RAD_FRAMED_PROTOCOL: 1)
[rl0-3] RADIUS: RadiusGetParams: (RAD_FRAMED_COMPRESSION: 1)
[rl0-3] RADIUS: RadiusGetParams: RAD_FRAMED_IP_NETMASK: 255.255.255.255 (/32)
[rl0-3] RADIUS: RadiusGetParams: RAD_SESSION_TIMEOUT: 86400
[rl0-3] RADIUS: RadiusGetParams: RAD_IDLE_TIMEOUT: 300
[rl0-3] RADIUS: RadiusGetParams: RAD_MPD_TABLE: 1=11.1.11.1
[rl0-3] RADIUS: RadiusGetParams: RAD_MPD_PIPE: 1=bw 128Kbyte/s
[rl0-3] RADIUS: RadiusGetParams: RAD_MPD_RULE: 1=pipe %p1 all from any to table\(%t1\) in
[rl0-3] AUTH: RADIUS returned authenticated
[rl0-3] AUTH: Auth-Thread finished normally
[rl0-3] CHAP: ChapInputFinish: status authenticated
 Reply message: Welcome

Hier noch ein Auszug einer Erfolgreichen Benutzeranmeldung von dem Benutzer den ich von Hand in /usr/local/etc/raddb/user eingetragen habe:

Code:
[rl0-3] RADIUS: rec'd RAD_ACCESS_ACCEPT for user test
[rl0-3] RADIUS: RadiusGetParams: (RAD_SERVICE_TYPE: 2)
[rl0-3] RADIUS: RadiusGetParams: (RAD_FRAMED_PROTOCOL: 1)
[rl0-3] RADIUS: RadiusGetParams: RAD_FRAMED_IP_ADDRESS: 1.2.3.4
[rl0-3] RADIUS: RadiusGetParams: RAD_FRAMED_IP_NETMASK: 255.255.255.255 (/32)
[rl0-3] RADIUS: RadiusGetParams: (RAD_FRAMED_ROUTING: 3)
[rl0-3] RADIUS: RadiusGetParams: (RAD_FILTER_ID: std.ppp)
[rl0-3] RADIUS: RadiusGetParams: RAD_FRAMED_MTU: 1492
[rl0-3] RADIUS: RadiusGetParams: (RAD_FRAMED_COMPRESSION: 1)
[rl0-3] RADIUS: RadiusGetParams: RAD_MPD_TABLE: 1=11.1.11.1
[rl0-3] RADIUS: RadiusGetParams: RAD_MPD_TABLE: 1=1.2.3.4
[rl0-3] RADIUS: RadiusGetParams: RAD_MPD_PIPE: 1=bw 10Kbyte/s
[rl0-3] RADIUS: RadiusGetParams: RAD_MPD_PIPE: 5=bw 20Kbyte/s
[rl0-3] RADIUS: RadiusGetParams: RAD_MPD_RULE: 1=pipe %p1 all from any to table\(%t1\) in
[rl0-3] RADIUS: RadiusGetParams: RAD_MPD_RULE: 2=pipe %p5 all from table\(%t1\) to any out
[rl0-3] RADIUS: RadiusGetParams: RAD_MPD_RULE: 100=allow all from any to any
[rl0-3] AUTH: RADIUS returned authenticated
[rl0-3] AUTH: Auth-Thread finished normally
[rl0-3] CHAP: ChapInputFinish: status authenticated
 Reply message: Welcome

Also, mein Erstes, aber momentan eher kleinstes Problem wird sein, dass ich den Dialup Admin etwas umschreiben muss (PHP4) ... das kann ich jedoch vorerstmal vernachlässigen, denn dafür habe ich einen Freund mit dem ich das zusammen lösen kann - kann selbst nämlich _noch_ kein PHP ;).


Soweit sogut ... nun habe ich nach gestrigen weiteren Tests aber noch etwas doofes feststellen müssen ;) (*mist*)

Erst mal die positive Nachricht:
Die Bandbreitenlimitierung mit Dummynet ist doch nicht so ungenau wie zuerst angenommen ... ;-)

Schlechte Nachricht:
Die Bandbreite wird Limitiert, aber nur für den Traffic der direkt zwischen PPPoE Client an PPPoE Server stattfindet. Internet-Traffic der hingegen noch über natd geht wird einfach volle Speed durchgelassen ... Das ist in meinem Falle natürlich ein Griff ins Klo ;) , denn ich möchte den PPPoE Clients den Internet-Hahn ja drosseln ;)


Folgendes gibt mir ipfw list aus, wenn ich mit einem PPPoE Client verbunden bin der auch erfolgreich die IPFW Regeln bekommen hat:

Code:
[root@wisp ~]# ipfw list
00050 divert 8668 ip4 from any to any via rl0
00100 allow ip from any to any via lo0
00100 divert 8668 ip from any to any in via rl0
00110 divert 8668 ip from any to any out via rl0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
10000 pipe 10000 ip from any to table(32) in via ng0
10001 pipe 10001 ip from table(32) to any out via ng0
10002 allow ip from any to any via ng0
65000 allow ip from any to any
65535 allow ip from any to any
[root@wisp ~]#

und so siehts dann wieder aus wenn er wieder disconected ist:

Code:
[root@wisp ~]# ipfw list
00050 divert 8668 ip4 from any to any via rl0
00100 allow ip from any to any via lo0
00100 divert 8668 ip from any to any in via rl0
00110 divert 8668 ip from any to any out via rl0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
65000 allow ip from any to any
65535 allow ip from any to any
[root@wisp ~]#

du siehst also:

Code:
10000 pipe 10000 ip from any to table(32) in via ng0
10001 pipe 10001 ip from table(32) to any out via ng0
10002 allow ip from any to any via ng0


die drei Regeln sind erfolgreich vorhanden und arbeiten auch, ABER eben nich für Traffic über natd ... ;/

Meine Frage jetzt also an dich als IPFW & DUMMYNET Speziallisten ;): Was fehlen dem für Regelsätze um _sämtlichen_ Traffic zu drosseln?


Vielen Dank, Diirc, ich weiß deine Hilfen wirklich sehr zu schätzen!

Liebe Grüße,

Leander
 
Moin

So wie sich mir das jetzt offenbart benutzen die Regeln aus dem mpd
nicht die divert sockets somit nicht das nat. Es fällt mir etwas schwer
ohne direkten Maschienenkontakt darüber zu philosophieren.
Auf jeden Fall hast du 2 Regelsätze:
1) in der rc.firewall
normale gatewayconfig über nat

2) im mpd
haben pipes für bandlim aber sind nicht an divert sockets angebunden.
die mpd-* kommandos werden wohl weiter oben im scrip definiert.
Ich gehe mal davon aus das da nur ein standard-ipfw Kommando drin
steht. (ipfw -q add oder so).

Zu Deutsch die mpd Regeln benutzen das nat nicht und treffen nur auf Verbindungen zu die den Server direkt ansprechen. (oder so ähnlich):D

Aber wie gesagt das gehört zu den Problemen die man eher mit direkten Hostkontakt gelöst kriegt. Du wirst wohl nicht umhin kommen dir die
ipfw mal etwas genauer an zu sehen.

Gruss Diirch

Edit: Bevor ich es vergesse :) in der rc.firewall solltest du dann nur:

case ${firewall_type} in
[Oo][Pp][Ee][Nn])
${fwcmd} add 65000 pass all from any to any
;;

stehen haben.

weil sonst die mpd einträge umgangen werden.
 
Zuletzt bearbeitet:
Hast du meine eMail bekommen?

P.S. kann ich das mit dem natd nicht global in der rc.firewall klären?
 
Zuletzt bearbeitet:
Ja hab ich hab bloss nicht geschnallt das du auch hier geschrieben hast. ;)

How ever der mpd regelt das nachdem was ich so sehe, alles so zu sagen
per user. Da du aber alle User individuell handhaben willst, wird es dafür
wohl keine wirklich gute Regel geben. Der natd wird in diesem Fall in die FW
eingebunden . Alternativ kannst du alles in
der rc.firewall oder in einem eigenen script regeln. Das hiesse z.B.
Die benutzer geschwindigkeiten in Subnetze aufteilen und den Subnetzen
eintsprechende fw-regeln zuordnen. Dafür musst du dann aber die Regeln+Pipes
in das firewallscript schreiben und (nichts für ungut ;) )
noch einiges über Firewalling lernen.

Es ist jedenfalls schwierig für mich genauer zu werden da ich den mpd
nicht kenne.
Wenn ich aber alles richtig deute würde ich einfach versuchen
das mpd-rule Kommando so zu modifizieren, das es wie
vorher in der rc.firewall, die divert sockets und natd benutzt.
 
;) ... nein ich meinte meinen SSH Login, dann könntest du dir die Sache live anschauen ;)

Hab dir die Zugangsdaten per Mail zukommen lassen.

Gruß,

Leander

P.S. Nein ich denke ich möchte das schon per User anstelle per Subnetz regeln.
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

der Entwickler "amotin" schreibt in seinem Forum:

erstmal auf meine Frage wie ich dem mpd folgende Optionen mitteile:
> ... may I have to form them to something like that?
>
> # mpd-rule += "100 divert natd ip from any to any in via rl0",
> # mpd-rule += "110 divert natd ip from any to any out via rl0",

There are several problems:
- mpd numerates ipfw rules automatically, so you can't specify rules number.
- mpd binds RADIUS-given rules strictly to the clients interface by adding " via ngX" to the end of rule, so yo can't use "via rl0" there.

One of ways to make RADIUS to use some global ipfw rules (if really neded) is to make that rules use some ipfw table and define them in some system startup script. Then mpd will be able to add user's IP into that ipfw table specified by RADIUS attributes.

[...]

You do not need any tables to create per-user shapes. All you need is:
mpd-pipe += "1=bw 10Kbyte/s",
mpd-pipe += "5=bw 20Kbyte/s",
mpd-rule += "1=pipe %p1 all from any to any in",
mpd-rule += "2=pipe %p5 all from any to any out",
mpd-rule += "100=allow all from any to any",

There will be no conflict with natd as soon as shapes work on downstream ngX interfaces and natd works on upstream rl0.

[...]

worin ich soviel verstehen konnte wie, dass die beiden:

Code:
mpd-table += "1=11.1.11.1", 
mpd-table += "1=1.2.3.4",

Regeln gar nicht benötigt werden?! Wenn ich diese aber nicht mit angebe dan funktioniert gar kein Bandwidthlimiting mehr?!


Gruß,

Leander
 
Zuletzt bearbeitet:
Ich verstehe das so das du eigentlich nur Probleme hast, wenn
die FW eine statische Nummerierung braucht.
Aber braucht sie doch eigentlich nicht oder?
Das via rl0 brauchst du nach meinem Verständnis auch nicht wirklich.
Ich kann mir vorstellen das das läuft.

Wie auch immer amotin schlägt ein globales FW-Skript vor wobei mir nicht ganz klar ist wie das dann noch per User gehen soll.

Versuch macht kluch :D
 
du meinst ich soll ma sowas wie:

mpd-rule += "divert natd ip from any to any in",
mpd-rule += "divert natd ip from any to any out",

in meine RADIUS users conf reinschreiben ?!
 
Ich bin mir ziemlich sicher das das geht. Kann es bloss im Augenblick nicht
ausprobieren weil alle Computer was machen.

> Du hast Mail :)

Halt Stop !
Was steht denn in der mpd-rule ?
ist nicht irgendwo im Skript sowas wie

mpd-rule="ipfw -q add" ?
 
Zuletzt bearbeitet:
Da Leander vom Schulstress gegeißelt wird hau ich mal einen aktuellen Stand raus.
In der etc/raddb/users hatten wir mit den mpd-eigenen ipfw-Regeln
versucht, allen Benutzern individuell die Bandbreite zu bestimmen.
Leander und ich haben stundenlang "geforscht":D aber es hat schlicht
nicht funktioniert. Zum Glück haben wir dann aber rausgefunden das
der mpd dies auch ohne ipfw zustande bringt.

Statt: (ipfw)
Code:
mpd-table += "1=10.0.0.1",
mpd-table += "1=10.0.0.15",
mpd-pipe += "1=bw 10Kbyte/s",
mpd-pipe += "5=bw 20Kbyte/s",
mpd-rule += "1=pipe %p1 all from any to table\\(%t1\\) in",
mpd-rule += "2=pipe %p5 all from table\\(%t1\\) to any out",
mpd-rule += "100=allow all from any to any",

Das:
Code:
mpd-filter += "1#1=nomatch src net 10.0.0.0/24",
mpd-filter += "1#2=match src net 10.0.0.0/10",
mpd-filter += "2#1=match dst net 10.0.0.0/16",
mpd-filter += "2#2=match dst net 11.0.0.0/8",
mpd-limit += "in#1=flt1 pass",
mpd-limit += "in#2=flt2 shape 64000 4000 pass",
mpd-limit += "in#3=all deny",
mpd-limit += "out#1=flt2 pass",
mpd-limit += "out#2=all rate-limit 1024000 150000 300000",
mpd-limit += "out#3=all pass",

Das sind nur Beispiele von der mpd Webpage. Die echte Konfig kommt noch.
Am WE wollen wir weiterfummeln wenn leander mit seinen Schulsachen fertig ist. Im Augenblck kann der mpd schon per user die Bandbreite limitieren was auch relativ simpel ist. Da soll aber noch etwas mehr rein
was dann schon schwieriger wird.
Verglichen mit ipfw ist das ein Syntax, der unserer Meinung nach in ein
Buch für Giftpilze gehört. :D :D

Aber die Lösung kommt an Wochenende ...hoffe ich.

Gruss Diirch
 
Zuletzt bearbeitet:

Ähnliche Themen

OpenVPN Ports für Anwendungen weiterleiten?

iptables - default policy - Server macht dicht

PPPOE Einwahl und Server als Gateway

Routing Problematik

Samba als PDC

Zurück
Oben