Routing
Willkommen in der Mk-Community › Foren › Software › Linux/Unix › Routing
- Dieses Thema hat 5 Antworten und 2 Teilnehmer, und wurde zuletzt aktualisiert vor 13 Jahren, 4 Monaten von fax.
-
AutorBeiträge
-
-
15. Dezember 2010 um 12:12 Uhr #498144ZoldanTeilnehmer
Ich habe zwei virtuelle Maschinen die beide etwas über https (Port 443) ins Internet bringen sollen. Ein Teil meiner domain (blubb.domain.tld) habe ich mit einem ddns Dienst auf meine Heim-IP weiterleiten lassen. Anfragen an mail.blubb.domain.tld:443 sollen an Server1:443 und alle anderen Anfragen an Server2:443 weitergeleitet werden.Wenn ich richtig gelesen habe kriege ich das mit meinem Standard Router nicht hin und ich brauche einen Router der Policy-based routing kann. Als alternative hätte ich noch eine FritzBox auf der auch ein Debian installiert ist in der Ecke stehen. Gedacht hatte ich aber eher an eine weitere VM als Router und der Standard Router fliegt auch in die Ecke.Ist pfSense hier eine gute Wahl? Mit Linux komm ich klar. Oder geht es vielleicht einfacher?
-
16. Dezember 2010 um 17:12 Uhr #872529faxTeilnehmer
Zoldan;437892 said:
Ich habe zwei virtuelle Maschinen die beide etwas über https (Port 443) ins Internet bringen sollen. Ein Teil meiner domain (blubb.domain.tld) habe ich mit einem ddns Dienst auf meine Heim-IP weiterleiten lassen. Anfragen an mail.blubb.domain.tld:443 sollen an Server1:443 und alle anderen Anfragen an Server2:443 weitergeleitet werden.Das Problem hier ist SSL. Der Router oder Webserver muss sich den Inhalt der Anfrage anschauen, um wissen zu können, an welche Domäne weitergeleitet werden soll. Das kann er aber nicht, weil die Anfrage verschlüsselt ist. Das Problem existiert natürlich nicht erst seit gestern und deshalb gibt es auch eine Methode, dem Server unverschlüsselt mitzuteilen, welche Domäne gemeint ist. Das nennt sich Server Name Indication (SNI). Hier gibt’s eine Anleitung für Apache: http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
(Der Webbrowser muss bei der Geschichte übrigens auch mitspielen. Ich weiß nicht genau, welche SNI unterstützen.)
-
16. Dezember 2010 um 18:12 Uhr #872542ZoldanTeilnehmer
Ahja, und wie werden die Paket dann durchs Internet geroutet, wenn man bei der Verschlüsselung das Ziel erst auf dem Zielrechner lesen kann?! Gehen da alle SSL verschlüsselten Pakete als Broadcast an alle Rechner Weltweit? 😡
Also irgendwie muss man nach dem Zielhost filtern können ohne sich den Inhalt angucken zu müssen. -
16. Dezember 2010 um 23:12 Uhr #872585faxTeilnehmer
Zoldan;438043 said:
Ahja, und wie werden die Paket dann durchs Internet geroutet, wenn man bei der Verschlüsselung das Ziel erst auf dem Zielrechner lesen kann?! Gehen da alle SSL verschlüsselten Pakete als Broadcast an alle Rechner Weltweit? 😡Hey, so einen frechen Smiley muss ich mir nicht gefallen lassen von jemanden, der offensichtlich keine Ahnung von dem Thema hat. Also noch mal langsam für Anfänger:
Du hast z.B. zwei Unterdomänen, 1.blub.com und 2.blub.com. Beide haben jeweils eigene interne IP Adressen. Davor sitzt ein Router. Nach außen hat der Router eine öffentliche IP Adresse. Mit DDNS verweisen sowohl 1.blub.com als auch 2.blub.com auf diese öffentliche IP Adresse.
Jetzt sitzt du irgendwo am anderen Ende des Internets und möchtest mit z.B. einem Browser über HTTP auf Port 80 von 1.blub.com zugreifen. (Ich erkläre erst mal anhand von unverschlüsseltem HTTP.) Der Browser sucht sich im DNS die öffentliche IP Adresse von 1.blub.com und schickt seine HTTP Protokollpakete los. Über das Internet wandern jetzt IP Pakete. Im Header jedes IP Pakets steht die öffentliche IP Adresse des Empfängers und Port 80. In den IP Nutzdaten stehen die HTTP Protokolldaten.
Wenn du jetzt portbasiertes Routing machen würdest, dann muss sich der Router nur den Empfängerport im IP Header anschauen und weiß, dass er intern die Pakete an 1.blub.com weiterleiten muss. Wenn du aber auch 2.blub.com auf Port 80 erreichen können willst, kann sich der Router nicht nur den IP Header anschauen, weil da ja immer die gleiche öffentliche IP Adresse und Port 80 stehen.
Wenn du einen intelligenten Router hast, dann kann dieser jetzt die IP Nutzdaten analysieren und die HTTP Protokolldaten daraus extrahieren. HTTP Pakete bestehen immer aus einem Header und den HTTP Nutzdaten. Im HTTP Header steht immer auch der Name des Empfängerhosts, also z.B. 1.blub.com. So weiß ein intelligenter Router also, ob er die IP Pakete an 1.blub.com Port 80 oder 2.blub.com Port 80 weiterleiten soll. Diese Technik nennt man HTTP Routing oder manchmal auch Content Based Routing und wird von billigen SOHO Routern m.W. nicht unterstützt.
Auf manchen Routern kann man ja aber auch selbst Software installieren. Da könnte man z.B. Apache so aufsetzen, dass es diesen Teil des Routings übernimmt. Oder man leitet alle Anfragen immer an den gleichen internen Host weiter, der dann das HTTP Routing im internen Netz macht.
So, jetzt kommt SSL ins Spiel. Wenn man z.B. eine Anfrage an 1.blub.com Port 443 schicken will, legt SSL sofort los und schickt an die öffentliche IP Adresse von 1.blub.com eine Anfrage nach dem Serverzertifikat. Der Router hat jetzt aber ein Problem, denn in der SSL Anfrage steht im wesentlichen nur die öffentliche IP Adresse und Port 443. Der Router weiß also nicht, ob er das Zertifikat von 1.blub.com oder 2.blub.com schicken soll. Dieses Problem umgeht man mit SNI (Server Name Indication). Das ist eine Erweiterung von SSL, mit der in die Anfrage nach dem Zertifikat zusätzlich der Name des Empfängerhosts gepackt wird.
SNI wird natürlich auch von keinem Billigrouter unterstützt. Aber wie vorhin könnte man evtl. Apache auf dem Router installieren und entsprechend konfigurieren. (Oder wie vorhin schon erwähnt, man hat Apache zu Routingzwecken auf einem internen Host laufen und der Router leitet alles dorthin.) Evtl. gibt es auch besser geeignete Software als Apache, die nur HTTP Routing macht.
Eine Alternative zu SNI wäre es, eine Apache Instanz mit einem X.509 v3 Zertifikat einzurichten. X.509 v3 erlaubt es, mehrere Hostnamen in einem Zertifikat zu listen. Man kann also alle SSL Anfragen für 1.blub.com und 2.blub.com an diese Apache Instanz richten, Apache entschlüsselt die Anfrage und leitet die entschlüsselten Daten weiter an den eigentlichen Empfänger im internen Netz.
Noch Fragen? O:-)
-
17. Dezember 2010 um 21:12 Uhr #872665ZoldanTeilnehmer
Hui, das ist mal eine ausführliche Antwort. Vielen Dank. Bei genauerem Nachdenken muss hier natürlich der Content gelesen werden, weil im IP Header ja nur die IP Adresse steht und kein Domain Name. Von daher alles bisherige von mir bullshit.Ich denke die Lösung mit Apache mit mod_proxy als reverse proxy wird die für mich passende sein. Dann leite ich :443 an server1 und der leitet anfragen an server2 weiter Einen SNI fähigen Client kann ich nicht immer voraussetzen, da z.B. auch ein ActiveSync Server dahinter arbeitet. Ich glaube nicht dass mein Handy SNI kann 😉 Und einen anderen Port kann ich dort nicht nutzen und bei den anderen Diensten möchte ich diesen nicht ändern.
-
17. Dezember 2010 um 22:12 Uhr #872671faxTeilnehmer
Ja, das sollte funktionieren. Eigentlich kann es dir ja auch egal sein, ob das Serverzertifikat gültig ist, daher muss es nicht zwingend ein X.509 v3 Zertifikat sein. Alternativ könntest du dir einen Router suchen, der VPN gut kann. Das funktioniert auch mit vielen Handys heutzutage. In der c’t gab es (ich glaube vergangenen Sommer) einen guten Artikel zu dem Thema.
-
-
AutorBeiträge
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.