<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ich fasse mal nun dieses zerplückte früheren mails zusammen<br>
Wenn dann so halbwegs geklärt ist werd ich daraus ne wiki Seite machen,
damit sich der Aufwand gelohnt hat<br>
<br>
<b><u>Welche Alternativen stellen sich bei funkinseln und auf der
"Hauptinsel" wenn man einen eigenen Uplink hat<br>
</u></b>Bei Funkinseln ist der mal klarerweise incl VPN Tunnel
notwendig um zum Wiener funkfeuer dazuzugehören.<br>
<br>
<b>A: Peerings (incl. VPN Tunnel)<br>
</b>- 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)<br>
+ Erhöhte Stabilität (falls der Uplink im Vivi ausfällt, betrifft das
die Funkinsel nicht)<br>
+ Kürzere Routen in das Netz mit dem man peert<br>
+ Weniger Bandbreitenverluste über die Tunnel<br>
+ Kein NAT, und somit keine diesbezüglichen Probleme<br>
- 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))<br>
<br>
<b>B: VPN-Tunnels und sonst nichts<br>
</b>+ einfachste Lösung<br>
+ kein NAT<br>
- 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)<br>
- längere Routen ins Netz an dem die Funkinsel direkt hängt<br>
- falls das vivi ausfällt geht gar nicht mehr<br>
<br>
<b>C1: VPN-Tunnel + NAT für alles was nicht nach 0xFF geht<br>
</b>+ keine Bandbreitenverschwendung<br>
+ immer noch halbwegs einfach<br>
- Einige Protokolle vertragen NAT nicht<br>
- falls das vivi ausfällt ist man über seine offizielle adresse nicht
mehr zu erreichen<br>
+ falls das vivi ausfällt hat man immer noch internet<br>
<br>
<b>C2: VPN-Tunnel + NAT nur für Protokolle die es auch vertragen und
nach 0xFF<br>
</b>+ weniger Bandbreitenverschwendung<br>
- schon etwas komplizierter (welche Protokoole Vertragens und welche
nicht, mehr konfigurationsaufwand)<br>
+ idealerweise auch keine Probleme mit NAT<br>
- falls das vivi ausfällt ist man über seine offizielle adresse nicht
mehr zu erreichen<br>
+ falls das vivi ausfällt hat man immer noch internet<br>
<br>
Gibts noch weitere Möglichkeiten?<br>
Mir persönlich gefällt C2 am besten, als Startpaket ist klarerweise B
das allerbeste<br>
<br>
Für ne Funkinsel kann man jede der obigen Optionen denk ich mal
problemlos (ausg. peering(-;) ausprobieren <br>
Dabei kann man dann auch in der Praxis rausfinden wieviel Probleme NAT
macht, wieviel Traffic ein Peering nach sich zieht, etc.<br>
<br>
<u><b>Was ändert sich aber wenn man keine funkinsel (mehr) ist?<br>
</b></u><br>
<b>A: Peering<br>
</b>+ 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<br>
+ 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)<br>
<br>
<b>B: VPN Tunnel<br>
</b>- Da man ja keine Funkinsel mehr ist brauchts eigentlich keinen VPN
Tunnel<br>
+ Gutes Backup falls die eigene WLAN Anbindung streikt<br>
- Verursacht wieder Bandbreitenverschwendung, die solang WLAN (gut)
möglich ist echt unnötig ist<br>
- olsr bevorzugt den Tunnel weil er kaum packets verliert<br>
<br>
<b>C1: VPN Tunnel + NAT<br>
</b>siehe VPN tunnel<br>
- 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<br>
- für einige Nodes ändern sich die NAT oder nicht NAT Bedingungen
andauern was noch mehr Probleme machen wird<br>
+ falls das vivi ausfällt haben nun alle (ausser den Inseln) immer noch
internet (evt. langsamer und natürlich genated)<br>
<br>
<b>C2:<br>
</b>+ falls die Protokolle richtig gewählt wurden, ergibt das höhere
Bandbreite und Stabilität für alle ausser den Inseln<br>
- falls die Protokolle falsch gewählt wurden siege C1<br>
<br>
Auch hier gefällt mir C2 am besten, allerdings ist A natürlich die
Ideallösung (falls sie überhaupt möglich ist)<br>
<br>
Fehlt hier noch was?<br>
<br>
<u><b>Was bleibt nun noch zu klären?<br>
</b></u><br>
- Welche Protokolle haben Probleme mit NAT und sollte deswegen
keinesfalls genatet werden<br>
In ner Funkinsel darf man sich hierbei noch Fehler erlauben, ansonsten
sollte man sich die umgekehrte Frage stellen<br>
<br>
- Welche Protokolle haben keine Probleme mit NAT<br>
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)<br>
<br>
- Wie kriegt man oslr dazu die Tunnels (oder einen Uplink) nur zu
verwenden wenn die alternativen wirklich zu schlecht oder weg sind?<br>
(Ich nehm an das ist eh schon gelöst)<br>
<br>
- Für etliche Protokolle gibt es NAT Erweiterungen um Probleme zu
vermeiden, wieviele Probleme lassen sich damit wirklich lösen?<br>
<br>
</body>
</html>