Das Leben eines Netzwerktechnikers war glücklich und unbeschwert, bis ein zertifiziertes Krypto-Gateway erschien. Der Umgang mit Lösungen zur Verschlüsselung von Datenübertragungskanälen gemäß GOST ist keine leichte Aufgabe. Es ist gut, wenn dies bekannte und verständliche Produkte sind. Lassen Sie uns die gleiche „S-Terra“ erinnern (wir haben bereits geschrieben über ihre „S-Terra Gateway“ ). Aber was tun mit exotischeren Lösungen, die auf eigenen Verschlüsselungsprotokollen basieren, z. B. "Continent" (aus "Security Code") oder ViPNet Coordinator HW (aus "Infotex")? In diesem Artikel werde ich versuchen, das Eintauchen in die Welt von ViPNet zu erleichtern (wir werden eines Tages auch über den Kontinent sprechen) und Ihnen sagen, mit welchen Problemen ich selbst konfrontiert war und wie ich sie gelöst habe.
Ich werde sofort reservieren, dass wir über die vom FSB und FSTEC zertifizierte Version 4.2.1 für heute sprechen werden. In den aktuellen Versionen 4.3.x sind viele interessante Dinge aufgetaucht, zum Beispiel DGD (Dead Gateway Detection) und ein modifizierter Clustering-Mechanismus, der eine nahezu nahtlose Umschaltung ermöglicht. Derzeit ist dies jedoch die Zukunft. Ich werde nicht tief in die Tiefen der Konfigurationsbefehle und -dateien eintauchen und mich auf die Schlüsselbefehle und -variablen konzentrieren. Eine ausführliche Beschreibung dieser "Schlüssel" finden Sie in der Dokumentation.
Lassen Sie uns zunächst herausfinden, wie alles funktioniert. Ein ViPNet-Koordinator führt also mehrere Funktionen aus. Erstens handelt es sich um ein Crypto Gateway (CG), das sowohl Site-to-Site- als auch RA-VPN ermöglicht. Zweitens handelt es sich um einen Server-Router für Umschläge, die verschlüsselte Servicedaten (Verzeichnisse und Schlüssel) oder Daten von Clientanwendungen (Dateiaustausch, Geschäftspost) enthalten. Übrigens werden in den Verzeichnissen Dateien gespeichert, die Informationen zu Objekten des ViPNet-Netzwerks enthalten, einschließlich ihrer Namen, Bezeichner, Adressen und Verbindungen. Der Koordinator ist auch eine Quelle für Serviceinformationen für seine Kunden.
Darüber hinaus kann der Datenverkehr von Netzwerkcomputern getunnelt werden, auf denen keine ViPNet-Software installiert ist. Experten, die mit dieser Lösung arbeiten, bezeichnen offene Hosts übrigens häufig nicht als "getunnelte Knoten", sondern einfach als "Tunnel". Dies kann für Ingenieure verwirrend sein, die an andere VPN-Lösungen gewöhnt sind, bei denen ein Tunnel eine PtP-Verbindung zwischen KSH bedeutet.
IPlir, ebenfalls von Infotex entwickelt, wird in ViPNet als Verschlüsselungsprotokoll verwendet. Zur Kapselung des Datenverkehrs werden die Transportprotokolle IP / 241 (wenn der Datenverkehr die Broadcast-Domäne nicht verlässt), UDP / 55777 und TCP / 80 (wenn UDP nicht verfügbar ist) verwendet.
Das Konzept des Aufbaus sicherer Verbindungen basiert auf den sogenannten "Verbindungen", die von zwei Arten sind. Ersteres (auf Knotenebene) wird benötigt, um eine sichere Verbindung zwischen Knoten herzustellen, letzteres (auf Benutzerebene) wird für den Betrieb von Clientanwendungen benötigt. Es gibt jedoch eine Ausnahme: ViPNet-Administratorknoten erfordern beide Kommunikationsarten.
Was kann in diesem Schema schief gehen? Wie die Praxis zeigt, gibt es wirklich viele Besonderheiten der Arbeit, und nicht alle Probleme können ohne „die Hilfe des Publikums“ intuitiv gelöst werden, sondern es muss etwas als selbstverständlich angesehen werden.
Koordinator nicht verfügbar
„Wir haben keinen Koordinator / Kunden / Tunnel zur Verfügung. Was zu tun ist?" - Die häufigste Frage, die sich Neulinge beim Einrichten von ViPNet stellen. Die einzig richtige Aktion in einer solchen Situation besteht darin, die Registrierung des gesamten Datenverkehrs auf den Koordinatoren zu aktivieren und das IP-Paketprotokoll zu überprüfen, das das wichtigste Tool zur Fehlerbehebung bei allen Arten von Netzwerkproblemen ist. Diese Methode spart in 80% der Fälle. Die Arbeit mit dem IP-Paketprotokoll hilft auch dabei, die Funktionsmechanismen der ViPNet-Netzwerkknoten besser zu verstehen.
Umschlag nicht geliefert
Aber das IP-Paketprotokoll ist leider unbrauchbar, wenn es um Umschläge geht. Sie werden mit einem Transportmodul (mftp) geliefert, das über ein eigenes Journal und eine eigene Warteschlange verfügt. Standardmäßig werden Umschläge an den "eigenen" Koordinator des Clients (dh den, auf dem der Knoten registriert ist) und dann über die zwischen den Koordinatoren konfigurierten Inter-Server-Kanäle gesendet (dh nicht direkt über einen sicheren Kanal). Das heißt, wenn Sie einen Brief per Geschäftspost senden möchten, packt der Kunde ihn in einen Umschlag und sendet ihn zuerst an seinen Koordinator. Weiter auf dem Weg kann es mehrere weitere Koordinatoren geben, und erst danach erreicht der Umschlag den Knoten des Adressaten.
Daraus ergeben sich zwei Schlussfolgerungen. Erstens muss die Kommunikation zwischen Clients nicht überprüft werden (durch Drücken von F5 und des entsprechenden Symbols im Menü), um Umschläge zu liefern. Zweitens, wenn die Verbindung zwischen ihnen immer noch überprüft wird, garantiert dies keine Zustellung, da das Problem möglicherweise in einem der Server-Kanäle liegt.
In nicht offensichtlichen Fällen ist es möglich, den Durchgang von Umschlägen durch Interserverkanäle oder zwischen einem Client und einem Koordinator mithilfe der Journal- und Umschlagwarteschlange sowie der Protokolle auf dem Koordinator zu diagnostizieren. Das ViPNet-Client-Transportmodul kann auch für die direkte Zustellung von Umschlägen, die Zustellung über einen freigegebenen Ordner oder SMTP / POP3 konfiguriert werden (dies ist jedoch eine vollständig exotische Option). Wir werden nicht auf diese Einstellungen eingehen.
Folgen des Blinkens
Es kann problematisch sein, auf die aktuelle Version alter Hardwareteile zu aktualisieren, die lange Zeit verwendet wurden, beispielsweise als Ersatzteile. Dabei kann ein Fehler "Nicht unterstützte Hardware" auftreten, der entweder darauf hinweist, dass Sie eine wirklich nicht unterstützte Hardwareplattform der veralteten G1-Leitung (dies sind HW100 E1 / E2 und HW1000 Q1) haben, oder auf Probleme bei der BIOS-Einrichtung oder falsche Informationen DMI. Ob DMI selbst verwaltet werden soll, entscheidet jeder für sich selbst, da die Gefahr besteht, dass die Geräte zu einem nutzlosen "Baustein" werden. Mit dem BIOS ist es etwas einfacher: Falsche Systemeinstellungen sind in deaktiviertem HT (Hyper Threading) oder deaktiviertem ACHI (Advanced Host Controller Interface) für die Festplatte. Um nicht genau zu erraten, wo genau das Problem liegt, können Sie sich auf das USB-Flash-Laufwerk beziehen, von dem aus die Firmware erstellt wird.Darauf werden Dateien mit Diagnoseinformationen erstellt. Insbesondere werden alle unterstützten Plattformen in der Datei verbose.txt aufgelistet, und das Ergebnis der Überprüfung mit Ihrer. Zum Beispiel zeigt der Fehler cpu :: Vendor (# 3) == 'GenuineIntel' 24 Mal => [Fehlgeschlagen] höchstwahrscheinlich an, dass HT deaktiviert ist. Übrigens wird das Flashen oft mit dem Aktualisieren verwechselt, aber dies sind unterschiedliche Prozesse. Während des Updates werden alle Einstellungen gespeichert und die oben beschriebenen Parameter werden nicht überprüft. Und wenn Sie erneut flashen, kehren Sie zu den Werkseinstellungen zurück.Beim Aktualisieren werden alle Einstellungen gespeichert und die oben beschriebenen Parameter werden nicht überprüft. Und wenn Sie erneut flashen, kehren Sie zu den Werkseinstellungen zurück.Während des Updates werden alle Einstellungen gespeichert und die oben beschriebenen Parameter werden nicht überprüft. Und wenn Sie erneut flashen, kehren Sie zu den Werkseinstellungen zurück.
Nicht informative Konfigurationen
Die Hauptkonfigurationsdatei für HW lautet "iplir.conf", spiegelt jedoch nicht immer die aktuellen Einstellungen wider. Tatsache ist, dass zum Zeitpunkt des Ladens des IPlir-Treibers diese Konfiguration gemäß der festgelegten Logik interpretiert wird und nicht alle Informationen in den Treiber geladen werden können (z. B. wenn IP-Adresskonflikte vorliegen). Ingenieure, die mit dem Linux-Softwarekoordinator gearbeitet haben, kennen wahrscheinlich den Befehl "iplirdiag", der die aktuellen Knoteneinstellungen anzeigt, die in den Treiber geladen wurden. In HW ist dieser Befehl auch im Modus "Admin-Escape" vorhanden.
Die beliebtesten Ausgaben sind:
iplirdiag -s ipsettings --node-info <Knoten-ID>
## Informationen zu einem Knoten anzeigen iplirdiag -s ipsettings --v-tun-table ## zeigt alle in den Treiber geladenen Tunnel an
Lassen Sie uns ein wenig auf den "Admin Escape" -Modus eingehen. Tatsächlich ist dies ein Ausstieg aus der ViPNet-Shell, um zu schlagen. Hier stimme ich dem Anbieter zu, der empfiehlt, diesen Modus nur zur Diagnose zu verwenden und Änderungen nur unter Aufsicht des technischen Supports des Anbieters vorzunehmen. Dies ist nicht Ihr üblicher Debian, hier kann jede unachtsame Bewegung das Betriebssystem deaktivieren, dessen Schutzmechanismen Ihre "Initiative" als potenzielle Bedrohung wahrnehmen. In Verbindung mit dem standardmäßig gesperrten BIOS werden Sie zu Reparaturen ohne Garantie (lesen Sie "teuer") verurteilt.
(Un) Split-Tunneling
Eine weitere Tatsache, die nicht jeder kennt: Standardmäßig arbeitet der ViPNet-Client im Split-Tunnel-Modus (wenn Sie angeben können, welcher Datenverkehr in den Tunnel eingebunden werden soll und welcher nicht). ViPNet verfügt über die "Open Internet" -Technologie (später in "Protected Internet Gateway" umbenannt). Viele Leute schreiben diese Funktionalität fälschlicherweise eher dem Koordinator als dem Kunden zu. Auf einem Client, der bei einem Koordinator mit dieser Funktion registriert ist, werden zwei Sätze voreingestellter Filter erstellt. Der erste erlaubt nur die Interaktion mit dem Koordinator selbst und seinen Tunneln, der zweite - mit anderen Objekten, verweigert jedoch den Zugriff auf den OI-Koordinator und seine Tunnel. Darüber hinaus muss der Koordinator gemäß dem Konzept des Anbieters im ersten Fall entweder den Proxyserver tunneln oder selbst ein Proxyserver sein. Serviceverkehr sowie Empfang und Übertragung von Umschlägen (sowohl Service,und Anwendungen) funktionieren in jeder Konfiguration.
TCP-
Einmal stieß ich auf eine Anwendung, die über den Koordinator in keiner Weise arbeiten wollte. Auf diese Weise habe ich erfahren, dass der Koordinator über Service-Ports verfügt, über die unverschlüsselter Datenverkehr ohne die Möglichkeit einer Konfiguration blockiert wird. Dazu gehören UDP / 2046,2048,2050 (grundlegende ViPNet-Dienste), TCP / 2047,5100,10092 (für ViPNet Statewatcher) und TCP / 5000-5003 (MFTP). Hier habe ich die TCP-Tunnelfunktionen zusammengefasst. Es ist kein Geheimnis, dass ISPs gerne hohe UDP-Ports filtern. Daher aktivieren Administratoren die TCP-Tunnelfunktion, um die Verfügbarkeit ihrer CNs zu verbessern. In diesem Fall sind Ressourcen in der DMZ (über den TCP-Tunnelport) nicht mehr verfügbar. Dies liegt an der Tatsache, dass der TCP-Tunnel-Port auch ein Service-Port wird und keine Firewall-Regeln und NAT-Regeln (Network Address Translation) mehr vorhanden sind. Es ist schwierig, die Tatsache zu diagnostizieren, dassdass dieser Datenverkehr nicht im IP-Paketprotokoll protokolliert wird, als ob er überhaupt nicht vorhanden wäre.
Koordinator ersetzen
Früher oder später stellt sich die Frage, ob der Koordinator durch eine produktivere oder vorübergehendere Option ersetzt werden soll. Ersetzen Sie beispielsweise HW1000 durch HW2000 oder Software-Koordinator durch PAK und umgekehrt. Die Schwierigkeit liegt in der Tatsache, dass jede Aufführung ihre eigene "Rolle" im NCC (Network Control Center) hat. Wie kann man die Rolle richtig ändern, ohne den Zusammenhalt zu verlieren? Erstens ändern wir im NCC die Rolle in eine neue, bilden Verzeichnisse, senden sie aber nicht (!). Dann veröffentlichen wir eine neue DST-Datei im UCC und initialisieren den neuen Koordinator. Danach machen wir einen Ersatz und nachdem wir sichergestellt haben, dass alle Interaktionen funktionsfähig sind, senden wir die Nachschlagewerke.
Clustering und Knotenabsturz
Eine Hot Reserve ist ein Muss für jeden großen Standort, daher wurde immer ein Cluster älterer Modelle (HW1000, HW2000, HW5000) von diesen gekauft. Die Erstellung eines Clusters aus kompakteren Krypto-Gateways (HW50 und HW100) war jedoch aufgrund der Lizenzierungsrichtlinie des Anbieters nicht möglich. Infolgedessen mussten die Eigentümer kleiner Websites HW1000 ernsthaft überbezahlen und kaufen (gut oder keine Fehlertoleranz). In diesem Jahr hat der Anbieter endlich zusätzliche Lizenzen für Junior-Koordinatormodelle vergeben. Mit der Veröffentlichung der Versionen 4.2.x wurde es möglich, diese in einem Cluster zu sammeln.
Wenn Sie zum ersten Mal einen Cluster einrichten, können Sie viel Zeit sparen, indem Sie die Schnittstellen nicht im Assistentenmodus konfigurieren oder CLI-Befehle verwenden. Sie können die erforderlichen Adressen sofort in die Cluster-Konfigurationsdatei eingeben (Failover-Konfigurationsbearbeitung). Vergessen Sie jedoch nicht, die Masken anzugeben. Wenn der Failover-Daemon im Cluster-Modus gestartet wird, weist er den entsprechenden Schnittstellen selbst Adressen zu. Gleichzeitig haben viele Angst, den Dämon zu stoppen, vorausgesetzt, die Adressen werden in passive oder Single-Mode-Adressen geändert. Keine Sorge: Die Schnittstellen behalten die Adressen bei, die zum Zeitpunkt des Stopps des Dämons vorhanden waren.
In der Cluster-Version gibt es zwei häufige Probleme: den zyklischen Neustart des passiven Knotens und das Versagen, in den aktiven Modus zu wechseln. Um die Essenz dieser Phänomene zu verstehen, wollen wir den Mechanismus der Clusteroperation verstehen. Der aktive Knoten zählt also Pakete auf der Schnittstelle und sendet einen Ping an testip, wenn in der zugewiesenen Zeit keine Pakete vorhanden sind. Wenn der Ping erfolgreich ist, wird der Zähler neu gestartet. Wenn er nicht erfolgreich ist, wird der Schnittstellenfehler registriert und der aktive Knoten wird neu gestartet. Gleichzeitig sendet der passive Knoten regelmäßige ARP-Anforderungen an alle in failover.ini beschriebenen Schnittstellen (die Cluster-Konfigurationsdatei, die die Adressen enthält, die der aktive und der passive Knoten erhalten). Wenn der ARP-Datensatz mit mindestens einer Adresse verschwindet, wechselt der passive Knoten in den aktiven Modus.
Kehren wir zu den Clusterproblemen zurück. Ich beginne mit einem einfachen - nicht in den aktiven Modus wechseln. Wenn kein aktiver Knoten vorhanden ist, seine Mac-Adresse jedoch noch auf der passiven in der ARP-Tabelle vorhanden ist (inet show mac-address-table), müssen Sie sich an die Switch-Administratoren wenden (entweder ist der ARP-Cache auf diese Weise konfiguriert oder es handelt sich um einen Fehler ). Das zyklische Nachladen des passiven Knotens ist etwas komplizierter. Dies geschieht aufgrund der Tatsache, dass der Passive den ARP-Datensatz nicht aktiv sieht, in den aktiven Modus wechselt und (Aufmerksamkeit!) Den Nachbarn über die HB-Verbindung abfragt. Aber unser Nachbar ist im aktiven Modus und hat mehr Betriebszeit. In diesem Moment erkennt der passive Knoten, dass etwas nicht stimmt, da ein Statuskonflikt aufgetreten ist, und führt einen Neustart durch. Dies geht auf unbestimmte Zeit weiter. Wenn dieses Problem auftritt, müssen Sie die IP-Adresseinstellungen in der Datei failover.ini und die Umschaltung überprüfen.Wenn alle Einstellungen am Koordinator korrekt sind, ist es Zeit, Netzwerktechniker mit der Frage zu verbinden.
Adressen kreuzen
In unserer Praxis stoßen wir häufig auf den Schnittpunkt von Tunneladressen hinter verschiedenen Koordinatoren.
In solchen Fällen werden Adressen in ViPNet-Produkten virtualisiert. Virtualisierung ist eine Art NAT, ohne den Status einer Eins-zu-Eins-Verbindung oder von Bereich zu Bereich zu überwachen. Standardmäßig ist diese Funktion für Koordinatoren deaktiviert, obwohl Sie potenzielle virtuelle Adressen in iplir.conf in der Zeile "tunnel" nach "to" in den Abschnitten benachbarter Koordinatoren finden. Um die Virtualisierung global für die gesamte Liste zu aktivieren, ändern Sie im Abschnitt [Sichtbarkeit] den Parameter "tunneldefault" in "virtual". Wenn Sie für einen bestimmten Nachbarn aktivieren möchten, müssen Sie den Parameter "tunnelvisibility = virtual" zu seinem Abschnitt [id] hinzufügen. Stellen Sie außerdem sicher, dass der Parameter tunnel_local_networks auf "on" gesetzt ist. Um virtuelle Adressen zu bearbeiten, muss der Parameter tunnel_virt_assignment auf den manuellen Modus gesetzt werden.Auf der anderen Seite müssen Sie ähnliche Aktionen ausführen. Die Parameter "usetunnel" und "exclude_from_tunnels" sind auch für die Tunneleinstellungen verantwortlich. Das Ergebnis der durchgeführten Arbeit kann mit dem oben erwähnten Dienstprogramm "iplirdiag" überprüft werden.
Virtuelle Adressen bringen natürlich einige Unannehmlichkeiten mit sich, sodass Infrastrukturadministratoren es vorziehen, ihre Verwendung zu minimieren. Wenn Organisationen beispielsweise eine Verbindung zu Informationssystemen (IS) einiger Regierungsbehörden herstellen, wird diesen Organisationen eine Sommerzeitdatei mit einem festen Tunnelbereich aus dem IS-Adressplan ausgestellt. Wie wir sehen können, werden die Wünsche der verbindenden Person nicht berücksichtigt. Wie man in diesen Pool passt, entscheidet jeder für sich. Jemand migriert Workstations zu einer neuen Adressierung, und jemand verwendet SNAT auf dem Weg von den Hosts zum Koordinator. Es ist kein Geheimnis, dass einige Administratoren SNAT verwenden, um die Lizenzbeschränkungen niedrigerer Plattformen zu umgehen. Wir verpflichten uns nicht, die Ethik eines solchen "Life Hack" zu bewerten, vergessen aber nicht, dass die Leistung der Plattformen selbst immer noch begrenzt ist.und wenn es überlastet ist, beginnt sich die Qualität des Kommunikationskanals zu verschlechtern.
Arbeitsunfähigkeit GRE
Natürlich hat jede IT-Lösung ihre eigenen Einschränkungen für die unterstützten Anwendungsfälle, und ViPNet Coordinator ist keine Ausnahme. Ein ziemlich ärgerliches Problem ist die Unfähigkeit, GRE (und die Protokolle, die es verwenden) über SNAT von mehreren Quellen zu einem einzelnen Ziel zu verarbeiten. Nehmen wir zum Beispiel ein Bank-Client-System, das einen PPTP-Tunnel zur öffentlichen Adresse einer Bank einrichtet. Das Problem ist, dass das GRE-Protokoll keine Ports verwendet. Nachdem der Datenverkehr über NAT geleitet wurde, wird das Socket-Paar dieses Datenverkehrs gleich (wir haben dieselbe Zieladresse, das Protokoll ist dasselbe und wir haben nur die Quelladresse in eine Adresse übersetzt). Der Koordinator reagiert darauf, indem er den Verkehr vor dem Hintergrund des Fehlers 104 blockiert. Die Verbindung besteht bereits. Es sieht aus wie das:
Wenn Sie mehrere GRE-Verbindungen verwenden, sollten Sie daher vermeiden, NAT auf diese Verbindungen anzuwenden. Führen Sie als letzten Ausweg eine 1: 1-Übertragung durch (obwohl dies eine ziemlich unpraktische Lösung ist, wenn Sie öffentliche Adressen verwenden).
Vergiss die Zeit nicht
Wir setzen das Thema Blockieren mit Ereignis Nummer 4 - IP-Paket-Timeout fort. Hier ist alles banal: Dieses Ereignis tritt auf, wenn zwischen den absoluten (ohne Zeitzonen) Zeit zwischen den ViPNet-Netzwerkknoten (Koordinatoren und ViPNet-Clients) eine Diskrepanz besteht. Bei HW-Koordinatoren beträgt die maximale Differenz 7200 Sekunden und wird im Parameter "timediff" der IPlir-Konfigurationsdatei festgelegt. Ich berücksichtige die HW-KB-Koordinatoren in diesem Artikel nicht, aber es ist erwähnenswert, dass in der KB2-Version die Zeitdifferenz standardmäßig 7 Sekunden und in KB4 50 Sekunden beträgt und das Ereignis dort möglicherweise nicht 4, sondern 112 generiert wird, was verwirrend sein kann ein Ingenieur, der an "normale" HW gewöhnt ist.
Unverschlüsselter Verkehr statt verschlüsselt
Für Anfänger kann es schwierig sein, die Art des Ereignisses 22 - Nicht verschlüsseltes IP-Paket vom Netzwerkknoten - im IP-Paketprotokoll zu verstehen. Dies bedeutet, dass der Koordinator von dieser IP-Adresse verschlüsselten Verkehr erwartet hat, aber unverschlüsselter Verkehr kam. Meistens passiert es so:
- ViPNet-, , . IPlir , , , . , : ViPNet-, – . , , , . , , , ViPNet-, . , ViPNet-, ;
- . , , ( ). , , , ;
- . , . , «» . , , , 22 .
(ALG)
Viele Firewalls, einschließlich ViPNet Coordinator, haben möglicherweise Probleme mit der Übertragung von SIP über NAT. Da es sich bei virtuellen Adressen um internes NAT handelt, kann das Problem auch dann auftreten, wenn explizit kein NAT verwendet wird, sondern nur virtuelle Adressen. Der Koordinator verfügt über ein ALG-Modul (Application Protocol Processing), das diese Probleme lösen soll, aber nicht immer wie gewünscht funktioniert. Ich werde nicht auf den Mechanismus des ALG eingehen (ein separater Artikel kann zu diesem Thema geschrieben werden), das Prinzip ist für alle ITUs gleich, nur die Überschriften der Anwendungsebene ändern sich. Für den korrekten Betrieb des SIP-Protokolls durch den Koordinator müssen Sie Folgendes wissen:
- ALG muss aktiviert sein, wenn NAT verwendet wird.
- Bei Verwendung der virtuellen Adressierung muss ALG auf beiden an der Interaktion beteiligten Knoten (Koordinator-Koordinator, Koordinator-Client) aktiviert sein, auch wenn die virtuelle Sichtbarkeit nur auf einer Seite festgelegt ist.
- Wenn Sie echte Sichtbarkeit verwenden und kein NAT vorhanden ist, müssen Sie ALG deaktivieren, damit SIP nicht beeinträchtigt wird.
- Die ALG-Zeilen 3.x und 4.x sind nicht kompatibel (genau genommen gab es in Zeile 3.x überhaupt keine Möglichkeit, sie zu steuern). In einem solchen Szenario kann der Anbieter den korrekten Betrieb von SIP nicht garantieren.
Das Modul wird durch die Befehle der Gruppe "alg module" aus dem privilegierten Modus (enable) gesteuert.
Abschließend
Ich habe versucht, die dringendsten Probleme zu berücksichtigen, ihre Wurzeln zu identifizieren und über Lösungen zu sprechen. Natürlich sind diese Funktionen bei weitem nicht alle Funktionen von ViPNet. Ich empfehle daher, nicht schüchtern zu sein. Wenden Sie sich an den Support und fragen Sie in der Community nach Rat (im Forum des Anbieters, im Telegrammkanal, in den Kommentaren unter diesem Beitrag). Und wenn Sie nicht in alle Schwierigkeiten der Arbeit mit ViPNet eintauchen möchten oder es zu mühsam ist, können Sie die Verwaltung Ihres ViPNet-Netzwerks jederzeit in die Hände von Fachleuten legen.
Autor: Igor Vinokhodov, Ingenieur der 2. Verwaltungslinie, Rostelecom-Solar