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

[Aaron Kaplan]

On Jan 19, 2006, at 7:54 PM, Markus Kittenberger wrote:

> Ich fasse mal nun dieses zerplückte früheren mails zusammen
> Wenn dann so halbwegs geklärt ist werd ich daraus ne wiki Seite  
> machen, damit sich der Aufwand gelohnt hat
>
markus, das waere super!


> Welche Alternativen stellen sich bei funkinseln und auf der  
> "Hauptinsel" wenn man einen eigenen Uplink hat
> Bei Funkinseln ist der mal klarerweise incl VPN Tunnel notwendig um  
> zum Wiener funkfeuer dazuzugehören.
>
> A: Peerings (incl. VPN Tunnel)
> - es ist sowieso klar das ein peering an nem Uplink (Funkinsel oder  
> nicht) nicht sonderlich realistisch ist (wenn man an nem moden und  
> nicht an einem Internetknoten hängt)

naja, das mag ich mal ein bisschen in frage stellen. Soweit ich weiss  
hat noch niemand mal ganz frech zB bei sil angerufen und gefragt, ob  
er ein BGP4 announcement von funkfeuer ueber seine flatrate machen  
kann :) Ich mein wenn ein kunde zB sil wirklich zahlen will und eine  
flatrate hat, dann sollte es sil doch egal sein, _was_ fuer traffic  
der kunde gerne haben will. Wenn ein kurzer BGP4 weg von sil direkt  
ins funkfeuer netz da ist und ein kunde fixer bei sil deshalb ist ,  
dann ist das doch nur in deren interesse oder?

also: einfach mal anrufen und fragen. Und nicht vergessen: fuer die  
warteschleife haben wir ja unser gratis-ins festnetz anrufen per  
VOIP :) Die koennen mich durchaus lange in der warteschleife haengen  
lassen, ist mir egal :)))


> + Erhöhte Stabilität (falls der Uplink im Vivi ausfällt, betrifft  
> das die Funkinsel nicht)
>
ja! ja ! ja!

> + Kürzere Routen in das Netz mit dem man peert
>
ja.
> + Weniger Bandbreitenverluste über die Tunnel
>
eigentlich keiner.

> + Kein NAT, und somit keine diesbezüglichen Probleme
>
und: so sollte das internet ja eigentlich aufgebaut sein: lauter  
peerings zwischen ISPs

> - Neuer Tunnel-Traffic aufgrund des Peerings (Bei einem Peering mit  
> z.B.: chello könnten sommit also Request von Chello nach 0xFF über  
> diese Funkinsel laufen, wobei der grossteil dieser Request wieder  
> getunnelt werden muesste (weil ja das gesamte funkfeuer announct  
> wird und nicht nur die Insel))
>
??? wo siehst du ueberhaupt in dem BGP bespiel den tunnel?


> B: VPN-Tunnels und sonst nichts
> + einfachste Lösung
>
ja

> + kein NAT
>
ja

> - Traffic von der Funkinsel ins Internet kostet zusätzlich zu der  
> Bandbreite für die Funkinsel, 2mal Bandbreite am vivi uplink (Was  
> aber zurzeit noch kein echtes Problem ist)
>
genau

> - längere Routen ins Netz an dem die Funkinsel direkt hängt
>
jein... der extra hop count (auf dem der tunnel aufsetzt) ist relativ  
egal.

> - falls das vivi ausfällt geht gar nicht mehr
>
ja leider. Aber zumindest ist der subway jetzt redundant ausgelegt.


> C1: VPN-Tunnel + NAT für alles was nicht nach 0xFF geht
> + keine Bandbreitenverschwendung
> + immer noch halbwegs einfach
> - Einige Protokolle vertragen NAT nicht
> - falls das vivi ausfällt ist man über seine offizielle adresse  
> nicht mehr zu erreichen
> + falls das vivi ausfällt hat man immer noch internet
>
klingt ok

> C2: VPN-Tunnel + NAT nur für Protokolle die es auch vertragen und  
> nach 0xFF
> + weniger Bandbreitenverschwendung
> - schon etwas komplizierter (welche Protokoole Vertragens und  
> welche nicht, mehr konfigurationsaufwand)
> + idealerweise auch keine Probleme mit NAT
> - falls das vivi ausfällt ist man über seine offizielle adresse  
> nicht mehr zu erreichen
> + falls das vivi ausfällt hat man immer noch internet
>
> Gibts noch weitere Möglichkeiten?
> Mir persönlich gefällt C2 am besten, als Startpaket ist klarerweise  
> B das allerbeste
>
> Für ne Funkinsel kann man jede der obigen Optionen denk ich mal  
> problemlos (ausg. peering(-;) ausprobieren
> Dabei kann man dann auch in der Praxis rausfinden wieviel Probleme  
> NAT macht, wieviel Traffic ein Peering nach sich zieht, etc.
>
> Was ändert sich aber wenn man keine funkinsel (mehr) ist?
>
dann traegt olsr alle hostrouten vom funkfeuer netz bei dir in die  
routingtabelle ein.
Inklusive der default route 0/0 ueber den subway

> A: Peering
> + Kein Tunnel notwendig um den grossteil des Funkfeuer Netzes zu  
> erreichen, es macht also sinn dieses zu announcen der Uplink im  
> vivi wird wirklich entlastet
> + falls das vivi ausfäält betrifft das nun nur mehr die Funkinseln  
> die direkt am vivi hängen (Falls man zusätzlich zum Peering auch  
> Tunnel zu Funkinseln hat betrifft es diese auch nicht mehr)
>
> B: VPN Tunnel
> - Da man ja keine Funkinsel mehr ist brauchts eigentlich keinen VPN  
> Tunnel
> + Gutes Backup falls die eigene WLAN Anbindung streikt
> - Verursacht wieder Bandbreitenverschwendung, die solang WLAN (gut)  
> möglich ist echt unnötig ist
> - olsr bevorzugt den Tunnel weil er kaum packets verliert
>
> C1: VPN Tunnel + NAT
> siehe VPN tunnel
> - Protokolle die NAT nicht vertragen werden nun bei sich bzw.  
> seiner Funkinsel Probleme machen sondern potentiell bei allen Nodes  
> in meinem sich dynamisch änderneden Umfeld
> - für einige Nodes ändern sich die NAT oder nicht NAT Bedingungen  
> andauern was noch mehr Probleme machen wird
> + falls das vivi ausfällt haben nun alle (ausser den Inseln) immer  
> noch internet (evt. langsamer und natürlich genated)
>
> C2:
> + falls die Protokolle richtig gewählt wurden, ergibt das höhere  
> Bandbreite und Stabilität für alle ausser den Inseln
> - falls die Protokolle falsch gewählt wurden siege C1
>
> Auch hier gefällt mir C2 am besten, allerdings ist A natürlich die  
> Ideallösung (falls sie überhaupt möglich ist)
>
> Fehlt hier noch was?
>
> Was bleibt nun noch zu klären?
>
> - Welche Protokolle haben Probleme mit NAT und sollte deswegen  
> keinesfalls genatet werden
> In ner Funkinsel darf man sich hierbei noch Fehler erlauben,  
> ansonsten sollte man sich die umgekehrte Frage stellen
>
> - Welche Protokolle haben keine Probleme mit NAT
> Kann man diese mit rules für einzelne Ports verlässlich rausfiltern  
> (Etliche Programme verwenden ja z.B.: port 80 für ganz was anderes)
>
> - Wie kriegt man oslr dazu die Tunnels (oder einen Uplink) nur zu  
> verwenden wenn die alternativen wirklich zu schlecht oder weg sind?
> (Ich nehm an das ist eh schon gelöst)
>
> - Für etliche Protokolle gibt es NAT Erweiterungen um Probleme zu  
> vermeiden, wieviele Probleme lassen sich damit wirklich lösen?
>
> _______________________________________________
> Discuss mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/discuss