[Discuss] vpn tunnel vs. BPG4 vs. NAT vs. Hybrid vs. ???

[Bernd Petrovitsch]

On Thu, 2006-01-19 at 14:29 +0100, Markus Kittenberger wrote:
> Bernd Petrovitsch schrieb: 
> > 
> > > Was passiert aber dann in der Praxis?
> > > Wenn A,B, und C 0xFF announcen (es gibt auch VPN Tunnels AC und AB)
> > > Wenn jetzt User 1 über B rausgeht, kommt dan der Traffic zu ihm auch
> > > immer über A zurück oder gleichmässig verteilt (A,B,C)?
> > >     
> > 
> > Das hängt von den Routern ab (angefangen beim Sender), wo die Pakete
> > vorbeikommen.
> > Es kann also durchaus sein, daß User 1 (d.h. die IP Pakete von ihm) über
> > B rausgehen und die Antworten alle über C zurückkommen, weil auf der
> > anderen Seite ein Router entscheidet, daß über C zu schicken (weil es am
> > billigsten, unbelastesten, etc. ist).
> >   
> > > Ist das zweite der Fall dann könnte diese Lösung den VPN Traffic sogar
> > > trastisch erhöhen falls User 1 nur selten/schlecht/langsam über WLAN
> > > zu erreichen ist, dann muss der Response im worst Case durch 2 Tunnel
> > > zu B und von dort dann zu User 1
> > 
> > Dafür bleibt aber alles (logisch und IP-Routning technisch) im
> > 0xFF-AS/Netz.
> > Kein Vorteil ohne Nachteil;-)
> >   
> Somit ist aber das Argument des sparsameren Umgangs mit der Bandbreite
> der Uplinks eigentlich recht vage bis falsch?

Für die VPN-Lösung: Ja, logisch, weil ja der VPN-Verkehr einmal "normal"
auf den 0xFF-Border-Router rein muß und dann sofort über den VPN Tunnel
wieder rausgeht (+ VPN Overhead).


> > > > Ja, aber mbMn sollte man das so gut wie selten bis nie merken. Mit SIP
> > > > o.ä. komplexen Prokollen wird es zwar mehr Probleme geben können wie mit
> > > > http, aber man kann nicht alles haben.
> > > >   
> > > >       
> > > Für mich selber hab ich keine Bedenken, nur für die Nodes in der mitte
> > > zweier uplinks, deren IP kann sich dank des dynamischen routings
> > > schnell mal ändern (je nachdem welchen Uplink sie verwenden)
> > >     
> > 
> > Yup, das ist ja Sinn und Zweck von dynamischen Rotuing (daß idR
> > innerhalb eines AS geschieht und das vollautomatisch mit
> > Routingprotkollen wie RIP/OSPF/OLSR/... passiert. Und das geht "relativ"
> > einfach, weil da nur technische Fakten ausschlaggebend sind und keine
> > administrativen).
> >   
> Die Funkinselen sind aber eigentlich eigene AS, und darum sollten sie

Im Prinzip ja (allerdings ist die Bezeichnung AS irreführend, weil AS in
der Netzwerkwelt eben ein "richtiges AS mit eigener Nummer meint).
Allerdings muß dann jede Funkinsel seinen exklusiven IP-Range bekommen
(so quasi "mini-AS innerhalb von 0xFF"). Und die größeren Provider
werden mich wahrscheinlich nicht mal auslachen, wenn ich sie frage, ob
sie nicht ein /29 per BGP4 announcen wollen.

>  nicht das gesamte AS oxFF announcen da sie es ja autonom nicht
> erreichen können

Über den VPN-Tunnel können Sie das ja.

> Meine Schlussfolgerung ist also das funkinselen bestenfalls naten
> dürfen, aber das oxFF AS keinesfalls announcen ansonsten wird die
> Qulaität/Bandenbreiteneffizienz eher schlechter als besser, aber auf
> jeden Fall wirds komplizierter.

Yup, schaut so aus.
  
[...]
> > > Das würde dann auch obiges Problem nicht aufkommen lassen, weil die
> > > Responses zu den genaten request ihren Weg schön sauber zurückfinden
> > > Auch ein "abbrennen" des jetzigen Uplinks würde zumindest Teile des
> > > 0xFF Netzes nur teilweise treffen (internet ist noch da, über seine
> > > offizielle IP ist man nicht aber mehr erreichbar)
> > > 
> > > Ob teilweises naten bei den Reponses von Servern innerhalb 0xFF auch
> > > immer hinhaut ist eine anderes Problem, evt. wärs besser http
> > > responses nicht zu naten sondern nur die requests.
> > 
> > Das geht nicht - entweder du NATest eine Verbindung/Port/IP-Adresse oder
> > nicht.
> > Tatsächlich wird eine TCP-Verbindung über <protcol, src-ip, src-port,
> > dst-ip, dst-port> eindeutig identifiziert. Wenn du NATtest, dann steht
> > in obigem am Internet die IP-Adresse der Firewall drin (und der Rest des
> > Internets muß im Prinzip raten, ob du überhaupt NATtest oder nicht - die
> > Verbindung könnte ja auch der Webproxy *auf* der Firewall sein).
> >   
> Was geht nicht?

;-) Obiges. Vielleicht hab ich nur deine Frage flasch verstanden.

> Ich meinte folgendes 2 Szenarien
> A: Wenn ein Browser auf port 80 ne tcp verbindung nach draussen
> aufbauen will soll er genated werden
"Draußen" meint da "nicht durch den Tunnel", nehmn ich mal an.
> B: Wenn von draussen eine Verbindung zu nem WEbserver aufgebaut wird
> kommt diese durch den Tunnel herein aber die Antworten (innerhalb der

Ja, wenn der Webserver auf einer öffentlichen 0xFF Adresse horcht.

>  gleichen TCP Connection) sollten mbMn auch wieder über den Tunnel
> zurück, ansonsten könnt das verwirrung stiften

Es würde gar nicht anders funktionieren, weil nach dem NATten die
IP-Adresse im Paket anders ist. Der (IP-Stack untern dem) Browser würde
die gar nicht als für ihn zugehörig erkennen können.

> Kann man NAT so konfigurieren das es B TRaffic in Ruhe lässt, oder
> gibts das problem dank der bestehenden TCP Verbindung sowieso nicht

Du mußt dem Kernel schon explizit sagen, welche IP-Netze er NATten soll.
Und alles andere wird geroutet (wenn eingeschaltet) oder blockiert oder
oder sontwas damit gemacht.
Also obige Szenarien gehen eh.

[...]
> > So ist es. Deshalb muß da mbMn jeder Interessierte selber lernen und
> > machen - weil er muß es auch reparieren und dazu muß man wissen, wie es
> > geht.
> >   
> rigtig, aber oxFF-globale vorgaben wären nicht schlecht denn sonst
> macht wer was und stört damit einige andere die dann erst langwierig
> rausfinden müssen was /wer eigntlich schuld ist 

Ja. Das alleine im stillen Kämmerlein zu machen, hab ich nicht gemeint.
Wenn Du mich fragst: Der Tunnel ist notwendig, damit die FunkInsel
überhaupt von "außen" erreichbar ist.
Aber Traffic, der von der FunkInsel Richtung Internet (das nicht 0xFF
ist) geht, würde ich auch gleich bei mir NATten und auf meinem Uplink
direkt abwerfen (und nur 0xFF Traffic geht ohne NAT über den Tunnel).
Mit Chello/Inode/TA/... peeren zu wollen (hehe, hinter einem
Kanel/ADSL-Modem), wird wohl dort nicht mal einen Rückruf verursachen.

[...]
> Wenn ich oder andere nen Uplink zur Verfügung stellen will sollt man
> drüber nachdenken.

Yup.

> Wenn ich nicht nachdenken will mach ich ein VPN und es ist klip und
> klar das dies KEINE Bandbreitenspende ist. (aber natürlich trotzdem
> eine nützliche Funkinsel)

Naja, du spendest halt die Bandbreite von deiner FunkInsel zum 0xFF
Border Router. Im Großen wird damit natürlich Verkehr generiert und
nicht reduziert (aber das haben wir eh schon weiter oben festgestellt).

> Wenn ich aber auch Bandbreite spenden will dann sollt ich eine Lösung
> finden/haben die auch wirklich einen Bandbreitengewinn darstellt ohne
> dabei allzuviele Nutzungen einzuschränken!!
> 
> Noch genauer nachdenken sollt ich wenn ich keine funkinsel bin

ACK.

>  sondern eine Halbinsel oder innerhalb der Kernzone Bandbreite
> sponsern will, denn bei ner Funkinsel können nur die an mich

Was noch dazu kommt (maW eine neue Dimension): OLSR gewichtet natürlich
die Links nach Packet Loss u.ä.. Tunnel über Kabel haben das Feature,
daß sie keinen Packet Loss haben und werden dadurch vom OLSR naturgemäß
sowieso schon bevorzugt.

>  angeschlossenen Nodes Probleme haben, in anderen Fällen kann ich
> anderen Nodes Features wegnehmen die sie bis jetzt hatten und auch
> nutzten!!!

Yup. Deshalb tu ich mir da leicht, weil an mir niemand dran hängt, der
außerhalb meiner Wohnung wohnt.

> Und da inzwischen einige Uplinks vorhanden bzw. im Gespräch sind wäre
> nun ein guter Zeitpunkt darüber nachzudenken was am sinnvollsten ist.

Ja (wobei natürlich verschiedene Uplink-Leute verschiene Meinungen haben
können, was "am sinnvollsten" ist).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services