[Wien] NAT "Probleme"

[Markus Kittenberger]

2011/12/15 Alex <(spam-protected)>

> Hi!
>
> Mein neuer Mast steht endlich, und um konform zu sein wollt ich dann
> gleich mal den olsrd updaten (war noch auf Firmware 1.4.5.). Irgendwas
> wollte dann aber nicht mehr so richtig mit dem Tunnel klappen. Also hab
> ich meine modifizierten Scripts und so rauskopiert und ab gings auf 1.7.5
> bzw. 1.7.4.
>
> So, jetzt verhält sich das aber etwas anders als die alte Firmware (und
> auch gleich nochmal als das Fonera Package).
>
> Meine konkreten Fragen drehen sich eigentlich alle um NAT also
> Masquerading, und das wären folgende:
>
>
> 1. Problem:
> Aufgrund der 2 Ranges sah ich keinen Grund als Netzmaske beim WLAN mit /22
> zu fahren, gerade auch da meine Nachbarn im Moment ohnehin in der anderen
> Range sind. Und die dementsprechende Route das alles aus meiner Range
> übers WLAN geht bringt ja auch nichts, also wäre /32 doch viel schöner.
>

> So, jetzt führt eine /32er Maske jedoch dazu, das Pakete die Masquerading
> brauchen zwar richtig raus gehen und daher auch zurück kommen, allerdings
> nicht mehr am LAN Interface auftauchen bzw. raus gehen.
>

da riecht etwas nach nem (konfigurations) problem beim partiellen conntrack
#1 der 1.7er firmwares,..

ist das ne original 1.7.x oder eine von meinen?


> 2. Problem:
> Wenn sich mein direkter Nachbar in der selben Range befindet gehen die
> Pakete nicht richtig mit Masquerading z.B. ins Internet raus und kommen
> somit auch nicht mehr zurück:
>
> Also mit verschiendenen Ranges der 2 sich direkt sehenden:
> 0xFF_OTHER1->INTERNETANY wird zu
> 0xFF_INETIF->INTERNETANY !aber eben nur wenn die 2 0xFF Router NICHT in
> der selben Range sind!
> INTERNETANY->OXFF_INETIF wird zu

INTERNETANY->OXFF_OTHER1
>

selbes wie oben,..

(btw. was enthält die nvram variable ff_range?)

lg Markus

#1 = extrem minimalistischer NOTRACK Ersatz für 2.4er kernel,..

und der erfahrungsgemäss/bekannterweise in der originalfirmware vom
sven-ola ziemlich buggy konfiguriert ist, und in meiner wenigstens nur mit
zusätzlichen interfaces (z.b. tunneln) probleme machen sollte,.. (weil das
zusätzliche interface bzw dessen ip eben entsprechend konfiguriert gehörte,
etc.)
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20111218/1c0b84cd/attachment.htm>