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

[Bernd Petrovitsch]

On Thu, 2006-01-19 at 12:32 +0100, Markus Kittenberger wrote:
> Bernd Petrovitsch schrieb: 
> > On Wed, 2006-01-18 at 18:18 +0100, Markus Kittenberger wrote:
> > [...]  
> > > Um das Netz stabiler zu machen sollten wir uns eine sowieso etwas kluges
> > > bzgl. nating etc überlegen
> > >     
> > 
> > Es ist ein Ziel "echte" IP-Adressen am Ende zu haben (wenn man das
> > will). Damit müssen die mal erhalten bleiben.
> > "Uplink Sponsoren" kann dann (IP-technisch) im einfachen Fall 2 Formen
> > annehmen - siehe andere Mail.
> > "Alles über den VPN" Tunnel hat den (mbMn gravierenden) Nachteil, daß
> > wenn ich z.B. im Inode Netz häng und der Server, von dem ich sauge auch,
> > daß der Traffic halt am jetzigen 0xFF-Uplink rein und rausgeht, obwohl
> > Source und Destination beim gleichen Provider sind.
> > Da ist "NAT lokal" raus mbMn das kleinere Übel.
> > 
> >   
> Ja, Echte IP Adressen sollten weiterhin möglich sein
> 
> Alles über VPN ist macht nichts stabiler denn wenn der uplink z.B.:
> abbrennt oder etwas harmloseres mit gleichen auswirkungen (-; dann
> "brennen" alle VPN-Uplinks mit ab, nebenbei kostet es den Uplinks in
> Summe die 3 fache Bandbreite (und höhere Latenz).
> gegen das "abbrennen" hilft BGP4 natürlich am besten
> > 3. Möglichkeit: Mit 0xFF-IP-Adressen über einen Uplink direkt
> > rauszugehen (so wie am Vivi) erfordert zwingend, daß Du (bzw. eigentlich
> > 0xFF) BGP4 mit dem Uplink-Provider bei Dir spricht (und ich es gibt mWn
> > noch keine Erfahrungsberichte, ob und wie verschiedene Provider
> > reagieren, wenn man am Helldesk mit "Ich würde gerne BGP4 mit euch
> > sprechen." deponiert). Ob der dann 0xFF-Netze auch nach außen announcet
> > (und damit Transit zuläßt oder nur rein/rausläßt) oder nicht, ist dann
> > schon das kleinere Problem.
> > 
> >   
> 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;-)

> 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).

> 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.

> 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).

> 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.

> Aber wer simple Lösungen will wo man selber nicht drüber nachdenken
> muss, ist bei chello et al eh bestens aufgehoben

Naja ...

> Interressant wäre jetzt wieviel Traffic die einzelnen Protokolle/Ports
> zurzeit verbrauchen

Wer? Ich bei mir oder ein Klischee-Sauger?
Und warum sollten mich Probleme von Protkoll X interessieren, daß ich
gar nicht brauch?

> Gibts darüber schon statistiken?

Bestimmt irgendwo für irgendwas.
Sind diese Statistiken aussagekräftig?

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