[Berlin-wireless] iptables Regeln

[MichaelN8]

OK,
danke hab ich mir fast schon gedacht.

Die Routen sehen an beiden Nodes wie folgt aus:
Node A:
    104.0.0.0/8 dev eth1  proto kernel  scope link  src 104.130.4.163
    104.130.4.164 via 104.130.4.164 dev eth1  metric 2 onlink
    192.168.0.0/24 via 104.130.4.164 dev eth1  metric 2 onlink


Node B:
    default via 192.168.0.2 dev eth0  proto static
    default via 104.130.4.163 dev wlan0  metric 2 onlink
    104.0.0.0/8 dev wlan0  proto kernel  scope link  src 104.130.4.164
    104.130.4.163 via 104.130.4.163 dev wlan0  metric 2 onlink
    169.254.0.0/16 dev eth0  scope link  metric 1000
    192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.201


Ich glaube Node B hat noch nicht die richtige Route.

Schöner Gruß

Am 14.09.2014 um 21:42 schrieb Bastian:
> Hallo,
>
> --source 192.168.0.0 <- da fehlt eine Netzmaske. Zum Beispiel /24.
> --source 192.168.0.0/24 <- richtig
>
> Zum Anzeigen der Regel "iptables -t nat -L" oder "iptables -t nat -S"
>
> Siehst du auf beiden OLSR Nodes die entsprechenden Routen? Also hat das
> HNA funktioniert?
>
> Gruß
> Bastian
>
>
> On 09/14/2014 08:05 PM, MichaelN8 wrote:
>> Hallo zurück,
>>
>> leider funktionierts noch nicht so richtig.
>> Node A hängt ihrerseits nochmal an einen Router. (aber das sollte doch
>> erstmal egal sein oder?)
>>
>> Habe
>>
>> iptables -t nat -A POSTROUTING --source 192.168.0.0 --out-interface
eth0 -j MASQUERADE
>>
>> entsprechend deiner Anleitung reingehackt (als root).
>> Wenn ich
>>
>> iptables -L
>>
>> mir ausgeben lasse, dann taucht die Regel nicht auf.
>> Any Ideas?
>>
>> Schöne Grüße
>>
>> Am 14.09.2014 um 12:45 schrieb Bastian:
>>> Hallo,
>>>
>>> für das Forwarding vom Internet von Node A über Node B zu Clients im LAN
>>> brauchst du eigentlich keine iptables. Höchstens eine NAT-Regel, falls
>>> Node A direkt mit public-IP im Internet sitzt.
>>>
>>> iptables -t nat -A POSTROUTING --source <LAN-subnet> --out-interface
>>> <inet-NIC> -j MASQUERADE
>>>
>>> Um die richtigen Hin- und Rückrouten bekannt zu machen, müssen folgende
>>> Hna4 definiert werden.
>>> Node A:  0.0.0.0 0.0.0.0
>>> Node B:  <LAN-subnet> <netmask>
>>>
>>> Clients in LAN verwenden als Default-Gateway Node B. Node B erfährt die
>>> Route ins Internet über OLSR-HNA von Node A. Node A kennt das LAN-Netz
>>> über das OLSR-HNA von Node B.
>>> Vor Anfragen aus dem Internet sind die Clients durch das NAT
'geschützt'.
>>>
>>> IPv6 funktioniert genauso, nur eben ohne die NAT-rule. Sofern Clients im
>>> LAN die richtige Absender-Adresse verwenden, sollte durch die passenden
>>> Hna6 automatisch end-to-end connectivity bestehen.
>>>
>>> Gruß
>>> Bastian
>>>
>>> On 09/14/2014 12:28 PM, MichaelN8 wrote:
>>>> Hallo zusammen,
>>>> ich bastle grad mit olsrd ein wenig rum. Ich konnte in einem Testaufbau
>>>> auch schon eine Verbindung zwischen 2 Nodes herstellen und auch
anpingen.
>>>> Nun will ich gerne mal mal "das Internet" von Node A für Node B
>>>> freigeben - bin aber noch nicht so fit mit iptables.
>>>> Hat einer von euch Plan, wie die Regel aussehen müsste (am Besten so,
>>>> dass das Böse iNet nicht ohne weiteres ins LAN von Node B
"telefonieren"
>>>> kann?)
>>>>
>>>> Hier mal ein kurzes Schema dazu:
>>>>
>>>> LAN <-----> Node B <--------------------------> Node A ------------>
>>>> Böses Internet
>>>>
>>>>
>>>>
>>>> Schöne Grüße
>>>> MichaelN8
>>>
>
>
>
>
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin

-- 
Schöne Grüße
MichaelN8



-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140914/78ecefd4/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 876 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140914/78ecefd4/attachment.pgp>