Cisco 7960 SIP voip 1und1 konfiguration nat port forward

Ich betreibe mein Cisco 7960 Telefon mit den voip-Zugangsdaten von 1und1, hinter einem 1und1 DSL-Anschluss. Da im Internet eine unfassbar große Anzahl von falschen Anleitungen bestehen, hier mein Versuch, das Thema etwas zu durchleuchten: Im Telefon werden lediglich unter dem Punkt Settings->Sip-Configuration->Line1 Name: 4986219887851 AuthenticationName: 4986219887851 AuthenticationPassword: geheim ProxyAddress: sip.1und1.de ProxyPort: 5060 hinterlegt. Dem Telefon sollte eine feste IP-Adresse spendiert werden. Der Default-Gateway sowie ein passender DNS-Server sind für Telefonate erforderlich. Netzwerkanmerkungen: Lediglich Port 5060 (SIP) sollte vom eigenen Router auf die IP-Adresse des Telefones weitergeleitet werden, da sonst keine Möglichkeit besteht, dass das Telefon von eingehenden Anrufen etwas mitbekommt. Für ausgehende Telefonate sollte die Firewall dem Telefon erlauben, nach aussen hin, Port 5060 (zum Proxy von 1und1) sowie einige weitere zufällige Ports für die eigentliche Verbindung zu öffnen. Häufig ist dies das Standardverhalten.

ip helper-address & broadcasts – cisco – allied telesis

Was macht die Option ip helper-address auf Cisco und Allied Telesis switches und ist sie notwendig? In gerouteten Netzen werden Ethernet-Frames an die Broadcast-Adresse FF:FF:FF…. nicht über Netzgrenzen weitergeleitet. In Fällen von nur einem DHCP-Server jedoch mehreren verschiedenen IP-Subnetzen mit Routern als Verbindung muss eine Möglichkeit geschaffen werden, die Broadcast-Pakete, welche von DHCP genutzt werden, weiterzuleiten. ip helper-address 192.168.10.29 Der Client ist im Netz 192.168.12.0

acl und security-level – cisco

Notiz an mich: Standardmäßig dürfen Interfaces mit höherem Security-Level ohne Einschränkgung Interface mit niedrigeren Security-Level passieren. Andersrum eben nicht. Sobald jedoch auf einem Interface mit hohem Security-Level eine acl angelegt wird, ist alles denied bis auf die eine Regel.

UDP Fragmentierung Problem & Lösung

Das Problem mit Fragmentierung von UDP Datagrammen Die gebotenen Funktionen von UDP im Vergleich zu TCP sind sehr limitiert. Eine Einschränkung tritt in Verbindung mit Fragmentierung auf. Die eigentliche Fragmentierung ist Aufgabe von der IP-Schicht (L3). Die UDP-Datagramme werden in mehrere IP-Pakete aufgeteilt und beim Empfänger wieder zusammengesetzt. Leider ergeben sich jetzt beim Zusammensetzen von UDP-Paketen folgende Probleme: – Die maximale Paketgröße von UDP-Datagrammen ist häufig auf 8192 beschränkt. – Zusammensetzung klappt nur, wenn keinerlei UDP-Datagramm verloren gegangen ist oder zu spät ankommt, sonst wird das komplette UDP-Datagramm verworfen Die Lösung ist also, darauf zu achten, dass UDP-Datagramme immer kleiner als 1500 bytes sind. Am Beispiel von OpenVPN kann man also die MTU vom TAP/TUN-Adapter auf eine MTU von 1400 setzen.

multicast howto 2013 linux

Multicast heißt, es gibt eine Gruppe von Empfängern. Die Gruppe wird definiert durch einen Netzbereich. Jeder Client ist Mitglied der Multicast-Gruppe, sobald er einer Multicast-Gruppe beitritt. Das dafür zuständige Protokoll ist igmp. Unter Linux reicht es, eine Route für das Multicast-Netz zu besitzen. Standardmäßig tritt jeder multicast-fähige Client der all-hosts-Gruppe bei. Ein Ping auf 224.0.0.1 sollte auch alle Geräte mit aktiviertem Multicast antworten lassen. Um explizit einer Multicast-Gruppe zu joinen, reicht das setzen der nötigen Route route add 224.0.0.0 netmask 240.0.0.0 dev eth0 Kontrolliert werden kann dies mit cat /proc/net/igmp

linux cloning – ssh keys – Schlüssel generieren

Man cloned mehrere Maschinen mit einem vorhandenen Image und hat das Problem, dass alle Host-Keys gleich sind unter Debian. Lösung: Im Image die /etc/ssh/ssh_host* Files löschen und neu generieren lassen im Init-Skript ala:   check_keys_avail() { if [ ! -e /etc/ssh/ssh_host_key_dsa ]; then dpkg-reconfigure openssh-server fi } case „$1“ in start) check_privsep_dir check_keys_avail