Hallo Alle,
wenn ich das richtig verstehe, muß die ISDN-Backup-Verbindung einen anderen Namen haben als die VPN-Verbindung.
Ich kann aber nicht für zwei Namen die gleiche Rufnummer in der Liste der "überprüften Nummern" angeben.
Habe ich etwas flchsa verstanden? Wie kann ich mit einer Backup-Verbindung trotzdem die ankommende Rufnummer überprüfen?
Danke und Servus,
Oliver
ISDN-Backup und Nummernliste: Konflikt
Moderator: Lancom-Systems Moderatoren
Hi obetz
Dazu mußt Du in der VPN-Namenliste den Schalter für dynamic VPN von "D-Kanal" auf "B-Kanal" umstellen - das kostet dann aber für jeden Trigger-Ruf eine Einheit...
Eine andere Möglichkeiet wäre, auf dynamic VPN ganz zu verzichten und mit DynDNS Namen zu arbeiten. Dafür muß dann aber zumindest eine Seite "always on" sein.
Gruß
Backslash
genauwenn ich das richtig verstehe, muß die ISDN-Backup-Verbindung einen anderen Namen haben als die VPN-Verbindung
das wäre ja auch ziemlich unsinnig. Woher sollte der Router auch ohne eine PPP-Verhandlung wissen, wer von den beiden anruft, wenn beide die gleiche Nummer haben.Ich kann aber nicht für zwei Namen die gleiche Rufnummer in der Liste der "überprüften Nummern" angeben
soweit ist alles korrektHabe ich etwas flchsa verstanden?
Das geht beim dynamic VPN nur dann, wenn auch der Trigger-Ruf angenommen wird. Denn wie gesagt: woher soll das LANCOM nur anhand der Nummer wissen, ob es der Trigger-Ruf ist oder die Backup-Verbindung.Wie kann ich mit einer Backup-Verbindung trotzdem die ankommende Rufnummer überprüfen?
Dazu mußt Du in der VPN-Namenliste den Schalter für dynamic VPN von "D-Kanal" auf "B-Kanal" umstellen - das kostet dann aber für jeden Trigger-Ruf eine Einheit...
Eine andere Möglichkeiet wäre, auf dynamic VPN ganz zu verzichten und mit DynDNS Namen zu arbeiten. Dafür muß dann aber zumindest eine Seite "always on" sein.
Gruß
Backslash
Hi obetz
eine kleine Korrektur zu obigem Posting:
Du brauchst doch nicht auf dynamic VPN über den D-Kanal zu verzichten, da die Backup-Verbindung ja keine Adreßinformationen überträgt. Daher nimmt das LANCOM den Ruf zwar in der Annnahme an, es sei der Trigger-Ruf, doch in der PPP-Verhandlung stellt es dann fest, daß es die Backup-Verbindung ist...
Gruß
Backslash
eine kleine Korrektur zu obigem Posting:
Du brauchst doch nicht auf dynamic VPN über den D-Kanal zu verzichten, da die Backup-Verbindung ja keine Adreßinformationen überträgt. Daher nimmt das LANCOM den Ruf zwar in der Annnahme an, es sei der Trigger-Ruf, doch in der PPP-Verhandlung stellt es dann fest, daß es die Backup-Verbindung ist...
Gruß
Backslash
Anhand der D-Kanal-Daten. Kommt keine IP-Adresse mit, ist es ein "normaler" Verbindungsversuch per ISDN. Mit IP-Adresse ist es die Aufforderung, einen neuen VPN-Tunnel aufzubauen.backslash hat geschrieben:das wäre ja auch ziemlich unsinnig. Woher sollte der Router auch ohne eine PPP-Verhandlung wissen, wer von den beiden anruft, wenn beide die gleiche Nummer haben.Ich kann aber nicht für zwei Namen die gleiche Rufnummer in der Liste der "überprüften Nummern" angeben
aber auch dann brauche ich doch zwei verschiedene Namen, und dann funktioniert die Rufnummernüberprüfung immer noch nicht?backslash hat geschrieben:Das geht beim dynamic VPN nur dann, wenn auch der Trigger-Ruf angenommen wird. Denn wie gesagt: woher soll das LANCOM nur anhand der Nummer wissen, ob es der Trigger-Ruf ist oder die Backup-Verbindung.Wie kann ich mit einer Backup-Verbindung trotzdem die ankommende Rufnummer überprüfen?
Dazu mußt Du in der VPN-Namenliste den Schalter für dynamic VPN von "D-Kanal" auf "B-Kanal" umstellen - das kostet dann aber für jeden Trigger-Ruf eine Einheit...
M.E. sollte ein Name für eine ISDN-Verbindung reichen, egal ob der für IP-Adreßübermittlung oder Backup genutzt wird.
BTW, ganz ein anderer Vorschlag: normalerweise wird zu einem bestimmten Zeitpunkt nur eine Seite zwangsgetrennt, nennen wir die mal "A". Die Gegenseite "B" behält die IP-Adresse. Eigentlich könnte A sich jetzt gleich wieder bei B melden, dann braucht man über lange Zeit gar keine ISDN-Verbindung. Für den Notfall (beide Enden gleichzeitig getrennt, z.B. nach längerem Ausfall) könnte man immer noch per ISDN-Backup oder dyndns wieder starten. Damit die beiden Enden sicher zu unterschiedlichen Zeiten getrennt werden, verwendet man cron-jobs mit einigen Stunden Abstand.
Servus,
Oliver
Hi obetz,
Der Ruf wird akzeptiert, weil die Nummer ja einer Gegenstelle zugeordnet ist. Da aber keine Adress-Information enthalten ist, wird der Ruf angenommen und eine PPP-Verhandlung durchgeführt. In dieser meldet sich die Gegenstelle mit dem Namen der Backup-Verbindung an und die Backup-Verbindung ist aufgebaut.
Wenn man all diese Möglichkeiten betrachtet, kommt man sehr schnell dazu, daß es besser ist, keine Sonderbehandlungen für "einseitige" Abbauten der VPN-Strecke aufzunehmen und jeden Verbindungsaufbau gleich zu behandeln (d.h. mit ISDN-Trigger-Ruf)
Gruß
Backslash
Siehe mein "Korrektur-Posting"...Anhand der D-Kanal-Daten. Kommt keine IP-Adresse mit, ist es ein "normaler" Verbindungsversuch per ISDN. Mit IP-Adresse ist es die Aufforderung, einen neuen VPN-Tunnel aufzubauen.
wiederum: Siehe mein "Korrektur-Posting"...aber auch dann brauche ich doch zwei verschiedene Namen, und dann funktioniert die Rufnummernüberprüfung immer noch nicht?
Der Ruf wird akzeptiert, weil die Nummer ja einer Gegenstelle zugeordnet ist. Da aber keine Adress-Information enthalten ist, wird der Ruf angenommen und eine PPP-Verhandlung durchgeführt. In dieser meldet sich die Gegenstelle mit dem Namen der Backup-Verbindung an und die Backup-Verbindung ist aufgebaut.
VPN-Verbindungen werden nicht nur durch die Zwangstrennung der Internetverbindung getrennt. Wenn über die VPN-Strecke für die Shorthold-Zeit keine Daten fließen wird sie auch getrennt. Ebenso wird sie getrennt wenn zwischen zwei Rekeyings keine Daten übertragen wurden auch wenn die Shorthold-Zeit noch nicht abgelaufen ist. Und, und, und...BTW, ganz ein anderer Vorschlag: normalerweise wird zu einem bestimmten Zeitpunkt nur eine Seite zwangsgetrennt, nennen wir die mal "A". Die Gegenseite "B" behält die IP-Adresse. Eigentlich könnte A sich jetzt gleich wieder bei B melden, dann braucht man über lange Zeit gar keine ISDN-Verbindung. Für den Notfall (beide Enden gleichzeitig getrennt, z.B. nach längerem Ausfall) könnte man immer noch per ISDN-Backup oder dyndns wieder starten. Damit die beiden Enden sicher zu unterschiedlichen Zeiten getrennt werden, verwendet man cron-jobs mit einigen Stunden Abstand
Wenn man all diese Möglichkeiten betrachtet, kommt man sehr schnell dazu, daß es besser ist, keine Sonderbehandlungen für "einseitige" Abbauten der VPN-Strecke aufzunehmen und jeden Verbindungsaufbau gleich zu behandeln (d.h. mit ISDN-Trigger-Ruf)
Gruß
Backslash