9
Cisco 866VAE-K9 - Zugriff über SSH
Schönen Tag allerseits,
während der letzten Tage habe ich die Grundkonfiguaration unseres neuen Cisco 866VAE-k9 durchgeführt und ihn inzwischen nicht zuletzt auch dank aquis vorzüglicher Anleitung "Konfiguration Cisco 886va mit ADSL oder VDSL Anschluss, VPN und IP-TV" (Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV) bzw. der veröffentlichten Beispielkonfiguration ans Internet gebracht. Im Prinzip bin ich recht zufrieden, doch einige wenige Dinge bleiben zu tun. Eines dieser Dinge finde ich verwirrend, doch vielleicht kann mir da ja jemand weiterhelfen.
Hier kurz das Szenario:
866vae-K9 SSH mit fester IP von der Telekom
Nach innen Vlan1 (192.168.0.0) und Vlan2 (192.168.2.0).
Wie es scheint, habe ich den SSH-Port an meinen 866VAE-K9 für Zugriffe aus dem Internet erfolgreich dichtgemacht, denn mein Versuch, mich heute morgen von zu Hause über unsere feste IP aus einzuloggen, ist erwartungsgemäß und erfreulicherweise fehlgeschlagen. Einloggen kann ich weiter mich im Büro über via Terminal und auch über eine mit Putty durchgeführte SSH-Verbindung sowohl aus Vlan1 als auch aus Vlan2.
Da ich über den Port 22 eine einzige Verbindung von außen auf einen unserer Rechner im Vlan1 zulassen möchte, habe ich folgende Zeile in der Config ergänzt, wobei aaa.bbb.ccc.ddd für unsere fest IP steht:
ip nat inside source static tcp 192.168.0.xyz 22 aaa.bbb.ccc.ddd 22 extendable
Ein gerade eben durchgeführter Test, bei dem ich versucht habe, über einen Rechner im Vlan1 mit Putty über unsere feste IP auf den Rechner 192.168.0.xxx zuzugreifen, endete mit der Eingabeaufforderung des Usernamens am Cisco-Router. Das finde ich als absoluter Cisco-Anfänger verwirrend, denn ich hätte erwartet, entweder tatsächlich zum gewünschten Rechner durchzukommen oder eben komplett zu scheitern.
Ich vermute, der Router ist schlau genug, um Zugriffe auf seine nach außen wirkende IP zu erkennen und gleich auf den "richtigen" Weg zu leiten, doch falls diese Vermutung richtig ist, dann stimmt wohl mein Weg nicht. Jetzt stelle ich mir die Frage, was ich falsch gemacht habe. Momentan habe ich da leider keine Idee, wäre aber umso dankbarer, wenn mir jemand auf die Sprünge helfen könnte.
Vielen Dank schon mal vorab.
Viele Grüße
Franz
P.S: Derzeit können Vlan1 und 2 auf das Internet (beispielsweise HTTP) zugreifen. Später sollen Internet-Zugriffe auf Vlan2, nicht aber auf Vlan1 (mit einer einzigen Ausnahme - siehe nachfolgend) möglich sein. Außerdem sollen Zugriffe aus Vlan1 auf Vlan2, nicht aber umgekehrt möglich sein.
während der letzten Tage habe ich die Grundkonfiguaration unseres neuen Cisco 866VAE-k9 durchgeführt und ihn inzwischen nicht zuletzt auch dank aquis vorzüglicher Anleitung "Konfiguration Cisco 886va mit ADSL oder VDSL Anschluss, VPN und IP-TV" (Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV) bzw. der veröffentlichten Beispielkonfiguration ans Internet gebracht. Im Prinzip bin ich recht zufrieden, doch einige wenige Dinge bleiben zu tun. Eines dieser Dinge finde ich verwirrend, doch vielleicht kann mir da ja jemand weiterhelfen.
Hier kurz das Szenario:
866vae-K9 SSH mit fester IP von der Telekom
Nach innen Vlan1 (192.168.0.0) und Vlan2 (192.168.2.0).
Wie es scheint, habe ich den SSH-Port an meinen 866VAE-K9 für Zugriffe aus dem Internet erfolgreich dichtgemacht, denn mein Versuch, mich heute morgen von zu Hause über unsere feste IP aus einzuloggen, ist erwartungsgemäß und erfreulicherweise fehlgeschlagen. Einloggen kann ich weiter mich im Büro über via Terminal und auch über eine mit Putty durchgeführte SSH-Verbindung sowohl aus Vlan1 als auch aus Vlan2.
Da ich über den Port 22 eine einzige Verbindung von außen auf einen unserer Rechner im Vlan1 zulassen möchte, habe ich folgende Zeile in der Config ergänzt, wobei aaa.bbb.ccc.ddd für unsere fest IP steht:
ip nat inside source static tcp 192.168.0.xyz 22 aaa.bbb.ccc.ddd 22 extendable
Ein gerade eben durchgeführter Test, bei dem ich versucht habe, über einen Rechner im Vlan1 mit Putty über unsere feste IP auf den Rechner 192.168.0.xxx zuzugreifen, endete mit der Eingabeaufforderung des Usernamens am Cisco-Router. Das finde ich als absoluter Cisco-Anfänger verwirrend, denn ich hätte erwartet, entweder tatsächlich zum gewünschten Rechner durchzukommen oder eben komplett zu scheitern.
Ich vermute, der Router ist schlau genug, um Zugriffe auf seine nach außen wirkende IP zu erkennen und gleich auf den "richtigen" Weg zu leiten, doch falls diese Vermutung richtig ist, dann stimmt wohl mein Weg nicht. Jetzt stelle ich mir die Frage, was ich falsch gemacht habe. Momentan habe ich da leider keine Idee, wäre aber umso dankbarer, wenn mir jemand auf die Sprünge helfen könnte.
Vielen Dank schon mal vorab.
Viele Grüße
Franz
P.S: Derzeit können Vlan1 und 2 auf das Internet (beispielsweise HTTP) zugreifen. Später sollen Internet-Zugriffe auf Vlan2, nicht aber auf Vlan1 (mit einer einzigen Ausnahme - siehe nachfolgend) möglich sein. Außerdem sollen Zugriffe aus Vlan1 auf Vlan2, nicht aber umgekehrt möglich sein.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 208723
Url: https://administrator.de/contentid/208723
Printed on: April 19, 2024 at 05:04 o'clock
9 Comments
Latest comment
Hallo Franz,
bin jetzt nicht der absolute Cisco-Freak aber müsstest du nicht noch einen passenden AccessList-Eintrag in dieser Art hinzufügen:
Grüße Uwe
bin jetzt nicht der absolute Cisco-Freak aber müsstest du nicht noch einen passenden AccessList-Eintrag in dieser Art hinzufügen:
access-list XXX permit tcp host aaa.bbb.ccc.ddd host 192.168.0.xyz eq 22Grüße Uwe
1
Hallo Uwe,
gleich mal danke, daß du mir hilfst. Ich habe mir deine Zeile angeschaut und glaube auch, daß ich sie ergänzen muß, denke aber sie müßte so lauten:
Auf das eq bin ich gekommen, weil mir die CLI ohne einen Fehler gemeldet hat. Den Rest denke ich mir, denn die Regel müßte ja nun sagen, daß jede extern IP, die auf Port 22 zugreift, durchgelassen wird. Die eigentliche Weiterleitung findet, wenn ich das bisher alles richtig verstanden habe bei "ip nat inside source static tcp xxx" statt. Ich bin zwar unsicher, aber so reime ich mir das zusammen.
Aber: Ich hab's ausprobiert und leider keine Änderung festgestellt. Also suche ich weiter...
Schönen Nachmittag
Franz
gleich mal danke, daß du mir hilfst. Ich habe mir deine Zeile angeschaut und glaube auch, daß ich sie ergänzen muß, denke aber sie müßte so lauten:
access-list xxx permit tcp any host aaa.bbb.ccc eq 22Aber: Ich hab's ausprobiert und leider keine Änderung festgestellt. Also suche ich weiter...
Schönen Nachmittag
Franz
stimmt das eq hatte ich unterschlagen sorry.
hmm, meld dich am besten direkt bei @aqui ... der kennt die Kisten besser
Grüße Uwe
Die eigentliche Weiterleitung findet, wenn ich das bisher alles richtig verstanden habe bei "ip nat inside source static tcp xxx" statt. Ich bin zwar unsicher, aber so reime ich mir das zusammen.
stimmt.hmm, meld dich am besten direkt bei @aqui ... der kennt die Kisten besser
Grüße Uwe
Hallo Uwe,
allem Anschein nach funktioniert die Sache von außen gesehen jetzt. Diese beiden Zeilen sind nun Bestandteil meiner Config:
und
Ein Freund hat sich gerade von seinem Rechner aus über meinen Router (aaa.bbb.ccc.ddd) auf dem Rechner 192.168.0.xyz über SSH eingeloggt. Damit scheint die Sache eben von außen zu funkionieren. Von innen kann ich's weiter nicht ausprobieren, denn nach der Eingabe von "aaa.bbb.ccc.ddd" gelange ich weiterhin zum Router, was mich zwar immer noch verwundert, aber nicht schlimm ist, weil ich den Rechner intern ja auch über seine wirkliche IP erreichen kann.
Mit dem Klick auf "Gelöst" warte ich noch, denn vielleicht weiß ja noch jemand den Grund, warum ich mit der externen IP von innen nicht nach außen gelange bzw. wie man das eventuell doch noch erreichen kann. Das würde das Testen meiner Config-Änderungen enorm erleichtern.
Viele Grüße
Franz
allem Anschein nach funktioniert die Sache von außen gesehen jetzt. Diese beiden Zeilen sind nun Bestandteil meiner Config:
ip nat inside source static tcp 192.168.0.xyz 22 aaa.bbb.ccc.ddd 22 extendableaccess-list xxx permit tcp any host aaa.bbb.ccc.ddd eq 22Ein Freund hat sich gerade von seinem Rechner aus über meinen Router (aaa.bbb.ccc.ddd) auf dem Rechner 192.168.0.xyz über SSH eingeloggt. Damit scheint die Sache eben von außen zu funkionieren. Von innen kann ich's weiter nicht ausprobieren, denn nach der Eingabe von "aaa.bbb.ccc.ddd" gelange ich weiterhin zum Router, was mich zwar immer noch verwundert, aber nicht schlimm ist, weil ich den Rechner intern ja auch über seine wirkliche IP erreichen kann.
Mit dem Klick auf "Gelöst" warte ich noch, denn vielleicht weiß ja noch jemand den Grund, warum ich mit der externen IP von innen nicht nach außen gelange bzw. wie man das eventuell doch noch erreichen kann. Das würde das Testen meiner Config-Änderungen enorm erleichtern.
Viele Grüße
Franz
Ich bin mir zwar nach wie vor nicht sicher, warum mein interner SSH-Zugriff auf die externe IP beim 688VAE-K9 landet, aber ich kann nun durch eigenen Test bestätigen, daß der externe Zugriff korrekt an 192.168.0.xyz landet. Insofern ist die Frage beantwortet bzw. das Problem gelöst.
Danke Uwe, dank deiner Anregung hab ich die Lösung gefunden.
Schönen Abend
Franz
Danke Uwe, dank deiner Anregung hab ich die Lösung gefunden.
Schönen Abend
Franz
Vielleicht noch eine Anmerkung zum Schluss:
Sicher ist so eine Lösung machbar aber eben nicht elegant.
Die Frage die sich stellt ob du die SPI Firewall auf dem Cisco aktiv hast mit ip inspect myfw out auf dem WAN/Internet Interface.
Wenn ja hast du damit CBACs aktiv (Content Based Access Control lists) das bedeutet das die ACL 111 (im Tutorial Beispiel) zentral den Zugriff auf das Internet Interface regelt.
Wie du dort im Tutoriual sehen kannst lässt diese CBAC ACL 111 von extern ohne einen bestehenden Session Eintrag von innen nur folgende Protokolle zu:
Deine Lösung ist nun kinderleicht und du ahnst sie vermutlich schon...
Einfach die ACL 111 erweitern das esterne TCP 22 (SSH) Sessions erlaubt werden !
Die ACL sähe dann so aus:
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq domain any
access-list 111 permit tcp any eq 22 any
access-list 111 permit gre any any
access-list 111 deny ip any any (log)
Das hintere "any" in der ACL 111 beim TCP 22 kannst du logischerweise gegen deine feste IP austauschen. Hier im Beispiel geht das Tutorial von einer wechselnden DSL IP Adresse aus, deshalb das "any" am Ende !
Hast du das Tutorial genau übernommen lauert noch einen 2te Hürde !
In der line vty 0 4 Definition die den remoten Zugang filtert sihst du ein access-class 23 in !
Die dazu korrekpondierende ACL lässt aber einzig nur den Zugriff aus dem lokalen LAN zu.
Um den Zugang vom Internet zu erlauben musst du also die ACL 111 anpassen wie oben beschrieben und mit no access-class 23 in zusätzlich die Sicherung für den remoten Zugang entfernen.
Mit deinem static NAT Eintrag sollte der remote Zugriff dann wunderbar klappen !
Weitere grundlegende Tips zum SSH Zugriff auf und vom Cisco findest du HIER !
Noch ein Tip:
Was du oben machst ist legitim aber du solltest nicht vergessen das du ein Loch in die Firewall damit bohrst und das System mehr angreifbar machst von außen. Falls du die ACL 111 mit dem "log" Statement bei der deny Regel konfiguriert hast kannst du im Log sehen das Angriffe im Sekundentakt kommen.
Fazit:
Es ist sicherer ein VPN Zugriff auf dem Router einzurichten !
Gerade mit deiner festen IP bietet sich das förmlich an.
Das Tutorial beschreibt den einfach Zugriff per L2TP VPN.
L2TP VPN Clients hat jedes Betriebssystem per Default mit an Bord und alle Smartphones, iPad usw. ebenfalls !
Es ist letztlich die intelligentere weil sicherere Lösung !
Denk mal drüber nach...
Sicher ist so eine Lösung machbar aber eben nicht elegant.
Die Frage die sich stellt ob du die SPI Firewall auf dem Cisco aktiv hast mit ip inspect myfw out auf dem WAN/Internet Interface.
Wenn ja hast du damit CBACs aktiv (Content Based Access Control lists) das bedeutet das die ACL 111 (im Tutorial Beispiel) zentral den Zugriff auf das Internet Interface regelt.
Wie du dort im Tutoriual sehen kannst lässt diese CBAC ACL 111 von extern ohne einen bestehenden Session Eintrag von innen nur folgende Protokolle zu:
- ICMP Replies
- DNS Replies mit UDP und TCP
- GRE Protokoll (Wenn man von intern PPTP macht)
Deine Lösung ist nun kinderleicht und du ahnst sie vermutlich schon...
Einfach die ACL 111 erweitern das esterne TCP 22 (SSH) Sessions erlaubt werden !
Die ACL sähe dann so aus:
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq domain any
access-list 111 permit tcp any eq domain any
access-list 111 permit tcp any eq 22 any
access-list 111 permit gre any any
access-list 111 deny ip any any (log)
Das hintere "any" in der ACL 111 beim TCP 22 kannst du logischerweise gegen deine feste IP austauschen. Hier im Beispiel geht das Tutorial von einer wechselnden DSL IP Adresse aus, deshalb das "any" am Ende !
Hast du das Tutorial genau übernommen lauert noch einen 2te Hürde !
In der line vty 0 4 Definition die den remoten Zugang filtert sihst du ein access-class 23 in !
Die dazu korrekpondierende ACL lässt aber einzig nur den Zugriff aus dem lokalen LAN zu.
Um den Zugang vom Internet zu erlauben musst du also die ACL 111 anpassen wie oben beschrieben und mit no access-class 23 in zusätzlich die Sicherung für den remoten Zugang entfernen.
Mit deinem static NAT Eintrag sollte der remote Zugriff dann wunderbar klappen !
Weitere grundlegende Tips zum SSH Zugriff auf und vom Cisco findest du HIER !
Noch ein Tip:
Was du oben machst ist legitim aber du solltest nicht vergessen das du ein Loch in die Firewall damit bohrst und das System mehr angreifbar machst von außen. Falls du die ACL 111 mit dem "log" Statement bei der deny Regel konfiguriert hast kannst du im Log sehen das Angriffe im Sekundentakt kommen.
Fazit:
Es ist sicherer ein VPN Zugriff auf dem Router einzurichten !
Gerade mit deiner festen IP bietet sich das förmlich an.
Das Tutorial beschreibt den einfach Zugriff per L2TP VPN.
L2TP VPN Clients hat jedes Betriebssystem per Default mit an Bord und alle Smartphones, iPad usw. ebenfalls !
Es ist letztlich die intelligentere weil sicherere Lösung !
Denk mal drüber nach...
Hallo aqui,
zunächst mal vielen Dank für deine Bemerkungen und Anregungen. Ja, die Firewall hab ich wie beschrieben und unverändert aktiviert. Inzwischen habe ich außerdem meine ACL 111 entsprechend deiner Anregung geändert. Da ich aber nicht von außen auf die Router-Kommandozeile zugreifen will, werde ich die Zeile "access-class 23 in" nicht anfassen.
Vielen Dank auch für deinen Fingerzeit auf das Loch in der Firewall. Diesbezüglich habe ich mich bisher immer auf die Einschätzungen eines Freundes, der Admin an einer Uni ist, verlassen, aber ich sehe natürlich trotzdem die Gefahr eines Eindringens. Da ich mich aber total dringend um weitere Dinge kümmern muß (ich bin bereits zwei Wochen beim Aufbau der Einrichtung einer Asterisk-Anlage zurück) werde ich den Router vorerst so belassen, wie er ist. Sobald all diese Dinge aber erledigt sind, werde ich auf die Fragen der Sicherheit zurückommen und mich mit VPNs beschäftigen.
Problematisch wird für mich dabei bleiben, daß ich die Außenwelt einerseits möglichst komplett aussperren möchte, andererseits aber Öffnungen für Asterisk, einen Translation-Memory-Server und auch ein Translation-Management-Programm zulassen muß. Ich bin sicher, das wird noch einiges an Kopfzerbrechen nach sich ziehen. Schau ma also mal...
Vielen Dank nochmals und viele Grüße
Franz
P.S. Das Log-Statement hab ich drangehängt. Es ist schon wirklich erstaunlich, in welch kurzer Zeit so ein Haufen Angriffsveruche stattfindet. Was in den Köpfen der betreffenden Menschen wohl abgehen mag? Ich glaube, ich möchte das lieber gar nich wissen.
zunächst mal vielen Dank für deine Bemerkungen und Anregungen. Ja, die Firewall hab ich wie beschrieben und unverändert aktiviert. Inzwischen habe ich außerdem meine ACL 111 entsprechend deiner Anregung geändert. Da ich aber nicht von außen auf die Router-Kommandozeile zugreifen will, werde ich die Zeile "access-class 23 in" nicht anfassen.
Vielen Dank auch für deinen Fingerzeit auf das Loch in der Firewall. Diesbezüglich habe ich mich bisher immer auf die Einschätzungen eines Freundes, der Admin an einer Uni ist, verlassen, aber ich sehe natürlich trotzdem die Gefahr eines Eindringens. Da ich mich aber total dringend um weitere Dinge kümmern muß (ich bin bereits zwei Wochen beim Aufbau der Einrichtung einer Asterisk-Anlage zurück) werde ich den Router vorerst so belassen, wie er ist. Sobald all diese Dinge aber erledigt sind, werde ich auf die Fragen der Sicherheit zurückommen und mich mit VPNs beschäftigen.
Problematisch wird für mich dabei bleiben, daß ich die Außenwelt einerseits möglichst komplett aussperren möchte, andererseits aber Öffnungen für Asterisk, einen Translation-Memory-Server und auch ein Translation-Management-Programm zulassen muß. Ich bin sicher, das wird noch einiges an Kopfzerbrechen nach sich ziehen. Schau ma also mal...
Vielen Dank nochmals und viele Grüße
Franz
P.S. Das Log-Statement hab ich drangehängt. Es ist schon wirklich erstaunlich, in welch kurzer Zeit so ein Haufen Angriffsveruche stattfindet. Was in den Köpfen der betreffenden Menschen wohl abgehen mag? Ich glaube, ich möchte das lieber gar nich wissen.
...besser ist das ! Eröffnet einem aber mal den Horizont was auch so an Otto Normalverbraucher Consumer Anschlüssen abgeht.
Generell musst du für dich überlegen ob du Löcher in die Firewall bohren willst oder besser mit einem VPN arbeiten willst.
Weder Asterisk noch dein Translation Management Programm benötigt Zugriff von außen für den Betrieb. Es sei denn du willst zwingend einen Zugriff zur Wartung aber auch das lässt sich immer besser und sicherer mit einem VPN realisieren auch wenn es ein PPTP VPN ist. Das ist allemal besser als Löcher in die Firewall zu bohren.
Wenn du dennoch nicht davon lassen kannst macht es erheblich mehr Sinn das 2te Interface des Cisco 866 als DMZ zu verwenden oder die DMZ mit einer VLAN Konfig am 866 zu realisieren um so Asterisk und diesen Translation Server vom produktivnetz zu isolieren und mit einer ACL abzusichern.
Wenn jemand in deinen Router einbricht, dann kann er wenigstens nur diese beiden Systeme kompromittieren.
Wäre einen Denkansatz wert....wenn du deinen Asterisk fertig hast ?!
Übrigens wie man einen Asterisk im Schnellverfahren zum Fliegen bringt erklärt dir dieses Tutorial hier:
Askozia VoIP Telefonanlage auf ALIX Basis
Generell musst du für dich überlegen ob du Löcher in die Firewall bohren willst oder besser mit einem VPN arbeiten willst.
Weder Asterisk noch dein Translation Management Programm benötigt Zugriff von außen für den Betrieb. Es sei denn du willst zwingend einen Zugriff zur Wartung aber auch das lässt sich immer besser und sicherer mit einem VPN realisieren auch wenn es ein PPTP VPN ist. Das ist allemal besser als Löcher in die Firewall zu bohren.
Wenn du dennoch nicht davon lassen kannst macht es erheblich mehr Sinn das 2te Interface des Cisco 866 als DMZ zu verwenden oder die DMZ mit einer VLAN Konfig am 866 zu realisieren um so Asterisk und diesen Translation Server vom produktivnetz zu isolieren und mit einer ACL abzusichern.
Wenn jemand in deinen Router einbricht, dann kann er wenigstens nur diese beiden Systeme kompromittieren.
Wäre einen Denkansatz wert....wenn du deinen Asterisk fertig hast ?!
Übrigens wie man einen Asterisk im Schnellverfahren zum Fliegen bringt erklärt dir dieses Tutorial hier:
Askozia VoIP Telefonanlage auf ALIX Basis
1
Hallo aqui,
mein Vlan2 ist derzeit quasi noch leer, aber es ist eigentlich als sowas wie eine DMZ angedacht - jedenfalls für die Zukunft, denn ich kann neben meiner normalen Arbeit nicht alles auf einmal erledigen. Momentan plane ich weiter mit diesem einen SSH-Zugriff auf diesen einen bestimmten Rechner im Vlan1 (bei Gelegenheit stelle ich das auf VPN um). Eventuell kann ich diese Verbinung aber noch ein wenig mehr absichern, denn die Zugriffe erfolgen maximal von zwei Personen von drei möglichen Ausgangspunkten aus, von denen zwei eine dynamische, der dritte eine feste IP hat. Weitere externe Zugriffsmöglichkeiten auf irgendwelche Innereien sind nicht vorgesehen.
Anonsten brauche ich, wenn ich mich nicht verzählt habe, drei weitere Ports für die Kommunikation mit Asterisk (5060), mit dem TMgm-System (HTTPS-Zugriff) sowie mit dem TM-Server (alles in Vlan2) gestatten. Die Ausgangspunkte der User, welche die Dienste auf den beiden zuletzt genannten Servern nutzen werden, werde ich nicht wirklich im Griff haben, denn bei diesen Leuten wird es sich in aller Regel auf eine variable Zahl freier Mitarbeiter bzw. Übersetzer von Firmen in gut 20 Ländern handeln. Vermutlich werde ich deswegen so etwas wie zeitlich befristete Firmenaccounts vergeben, um die Sache einigermaßen unter Kontrolle halten zu können. Aber andererseits ist das alles eh Zukunftsmusik, denn erstmal müssen meine Server zufriedenstellend laufen und uns im nächsten Schritt vor allem intern weiterhelfen.
Ja, und Asterisk ist ab sofort an der Reihe. Ich bedanke mich auch gleich für den Link. Das Tutorial hab ich vorhin mit Interesse gelesen, aber ich bin tatsächllich schon über den Anfang hinaus, denn Asterisk ist installiert, interne Gespräche (sogar über eine Nebenstelle bei mir zu Hause) sind bereits möglich. Ein letzter Schritt fehlt mir allerdings noch: Die Anbindung an unsere beiden S0-Anlagenanschlüsse. Das Gerät, das diese Lücke schließen soll ist ebenlfalls schon da: ein Sangoma Vega 50 Gateway. Dummerweise stehe ich auch hier auf dem Schlauch, denn eine Art Dokumentation war nicht dabei und Google spuckt mir zumindest bisher keinerlei Informationen darüber aus, welche Config ich wie zu bearbeiten habe. Aber ich werd's schon herausfinden. Vielleicht ja auch wieder mit deiner Hilfe und/oder der Hilfe weiterer netter Menschen hier im Forum.
Schönes Wochenende
Franz
mein Vlan2 ist derzeit quasi noch leer, aber es ist eigentlich als sowas wie eine DMZ angedacht - jedenfalls für die Zukunft, denn ich kann neben meiner normalen Arbeit nicht alles auf einmal erledigen. Momentan plane ich weiter mit diesem einen SSH-Zugriff auf diesen einen bestimmten Rechner im Vlan1 (bei Gelegenheit stelle ich das auf VPN um). Eventuell kann ich diese Verbinung aber noch ein wenig mehr absichern, denn die Zugriffe erfolgen maximal von zwei Personen von drei möglichen Ausgangspunkten aus, von denen zwei eine dynamische, der dritte eine feste IP hat. Weitere externe Zugriffsmöglichkeiten auf irgendwelche Innereien sind nicht vorgesehen.
Anonsten brauche ich, wenn ich mich nicht verzählt habe, drei weitere Ports für die Kommunikation mit Asterisk (5060), mit dem TMgm-System (HTTPS-Zugriff) sowie mit dem TM-Server (alles in Vlan2) gestatten. Die Ausgangspunkte der User, welche die Dienste auf den beiden zuletzt genannten Servern nutzen werden, werde ich nicht wirklich im Griff haben, denn bei diesen Leuten wird es sich in aller Regel auf eine variable Zahl freier Mitarbeiter bzw. Übersetzer von Firmen in gut 20 Ländern handeln. Vermutlich werde ich deswegen so etwas wie zeitlich befristete Firmenaccounts vergeben, um die Sache einigermaßen unter Kontrolle halten zu können. Aber andererseits ist das alles eh Zukunftsmusik, denn erstmal müssen meine Server zufriedenstellend laufen und uns im nächsten Schritt vor allem intern weiterhelfen.
Ja, und Asterisk ist ab sofort an der Reihe. Ich bedanke mich auch gleich für den Link. Das Tutorial hab ich vorhin mit Interesse gelesen, aber ich bin tatsächllich schon über den Anfang hinaus, denn Asterisk ist installiert, interne Gespräche (sogar über eine Nebenstelle bei mir zu Hause) sind bereits möglich. Ein letzter Schritt fehlt mir allerdings noch: Die Anbindung an unsere beiden S0-Anlagenanschlüsse. Das Gerät, das diese Lücke schließen soll ist ebenlfalls schon da: ein Sangoma Vega 50 Gateway. Dummerweise stehe ich auch hier auf dem Schlauch, denn eine Art Dokumentation war nicht dabei und Google spuckt mir zumindest bisher keinerlei Informationen darüber aus, welche Config ich wie zu bearbeiten habe. Aber ich werd's schon herausfinden. Vielleicht ja auch wieder mit deiner Hilfe und/oder der Hilfe weiterer netter Menschen hier im Forum.
Schönes Wochenende
Franz
