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

[Markus Kittenberger]

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?

>  
>
>>Oder anderes Beispiel
>>
>>Und bei den Uplinks der (Halb-)Funkinseln trifft ungefähr folgendes
>>zu 
>>10% der oxFF Adressen sind von ihnen direkt zu erreichen 90% meist nur
>>(gut) über Tunnel
>>
>>Wenn so eine Insel nun aber 0xFF announct und folgedessen dann 30% der
>>Requests/Responses nach 0xFF bekommt wird ziemlich viel davon erst
>>recht wieder durch den Tunnel müssen
>>    
>>
>
>Ja, kann auch passieren.
>Wie die Rounting-Policies tatsächlich ausschauen und wie das im
>wirklichen Leben wirklich funktioniert, müssen andere erzählen - ich
>kenn' nur die Theorie.
>
>[...]
>  
>
>>Oder seh ich da jetzt schwarz und auch ausserhalb 0xFF wird dynamisch
>>genug gerouted so das sich intelligente Routen (zu einzelnen Hosts
>>innerhalb des 0xFF subnets) von selber laufend ergeben ???
>>    
>>
>
>Nein. Zwischen AS (ist BTW d. Abk. f. "Autonomous System") wird idR
>nichts automatisch geroutet. Ein AS ist eine administrative Einheit
>(z.B. ein ISP oder eine Uni oder ...) und die macht Verträge mit anderen
>ASes über "welcher Verkehr geht, rein, welcher geht raus und welcher
>geht durch und mit welchen Bandbreiten über welche Leitungen".
>Und das wird idR händisch/semi-automatisch in Konfig-files geschrieben,
>weil ja idR Geld dranhängt. Und ein anderes AS kann (und will) nicht die
>Border-Routing-Policy dynamisch vom inneren Zustand der/des Target-AS
>ändern (zum einen gibt es mWn keine Protokolle für diesen Zweck und
>Fehler suchen wird noch lustiger, wenn noch mehr dynamisch geht).
>
>  
>
>>>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 
nicht das gesamte AS oxFF announcen da sie es ja autonom nicht erreichen 
können
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.

>  
>
>>Alternativ könnte man http und andere unhagliche Protokolle/ports
>>naten und ssh, ftp, und weitere Problemfälle via VPN abwickeln, es sei
>>denn der VPN Tunnel reisst ab, dann sollte man idealerweise sofort
>>auch diesen Traffic naten.
>>    
>>
>
>"Diesen Traffic" gibt es dann so nicht mehr. Wenn du ein Kabel abziehst
>verschwinden die Verbindungen (nach den entsprechenden Timeouts). Viele
>Services/Daemons machen automatisch ein reconnect und probieren noch mal
>- aber dann ist es neuer/anderer Traffic, weil es ganz neue
>TCP-Verbindungen sind.
>  
>
Klar, aber wenn am Uplink ausnahmen für naten gelten, muessten diese 
dann inaktiv werden falls der Tunnel weg ist.

>  
>
>>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?
Ich meinte folgendes 2 Szenarien
A: Wenn ein Browser auf port 80 ne tcp verbindung nach draussen aufbauen 
will soll er genated werden
B: Wenn von draussen eine Verbindung zu nem WEbserver aufgebaut wird 
kommt diese durch den Tunnel herein aber die Antworten (innerhalb der 
gleichen TCP Connection) sollten mbMn auch wieder über den Tunnel 
zurück, ansonsten könnt das verwirrung stiften

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

>  
>
>>Allerdings wird das Routing dieser VPN+NAT Hybridlösung an den
>>(Halbinsel-)Uplinks dann schon etwas sofisticated, während die VPN
>>ueberall lösung überzeugend simpel ist
>>    
>>
>
>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

>  
>
>>Interressant wäre jetzt wieviel Traffic die einzelnen Protokolle/Ports
>>zurzeit verbrauchen
>>    
>>
>
>Wer? Ich bei mir oder ein Klischee-Sauger?
>
Am jetzigen Uplink wär ein guter Punkt, denn wenn nur 1% gefahrlos 
genated werden kann, dann kann man sich getrost sparen weiter darüber 
nachzudenken

>Und warum sollten mich Probleme von Protkoll X interessieren, daß ich
>gar nicht brauch?
>  
>

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

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)

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 sondern 
eine Halbinsel oder innerhalb der Kernzone Bandbreite sponsern will, 
denn bei ner Funkinsel können nur die an mich angeschlossenen Nodes 
Probleme haben, in anderen Fällen kann ich anderen Nodes Features 
wegnehmen die sie bis jetzt hatten und auch nutzten!!!

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

Darum sollte das ne Lösung sein die auch wirklich funktinoiert und nur 
weil ich nur im web surf sollt ich halt nicht einfach alles naten, oder 
meinen Provider Fragen ob er BGP4 zulässt obwohl ich damit im worst case 
alles nur schlechter machen würd.

>
>	Bernd
>  
>

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20060119/6c4229b6/attachment.htm>