Tack för din feedback.
Proxystöd för hybriddatasäkerhet och videonät
Har du feedback?I det här avsnittet beskrivs proxystödfunktionen för hybriddatasäkerhet. Den är avsedd att komplettera implementeringsguiden för Cisco Webex hybriddatasäker het, tillgänglig på https://www.cisco.com/go/hybrid-data-security. I en ny distribution konfigurerar du proxyinställningen på varje nod efter att du har laddat upp och monterat HDS-konfigurationens ISO på noden, och innan du registrerar noden i Cisco Webex molnet.
Hybrid datasäkerhet stöder uttryckliga, transparenta inspekterings- och icke-inspekterande proxyer. Du kan knyta dessa proxyer till din distribution så att du kan säkra och övervaka trafiken från företaget ut till molnet. Du kan använda ett plattformsadministratörsgränssnitt på noderna för certifikathantering och för att kontrollera den övergripande anslutningsstatusen när du har ställt in proxyn på noderna.
Noderna för hybriddatasäkerhet stöder följande proxyalternativ:
-
Ingen proxy — Standard om du inte använder HDS-nodkonfigurationen Trust Store & Proxy för att integrera en proxy. Ingen certifikatuppdatering krävs.
-
Transparent proxy utan inspektion — Noderna är inte konfigurerade för att använda en specifik proxyserveradress och bör inte kräva några ändringar för att fungera med en proxy som inte inspekterar. Ingen certifikatuppdatering krävs.
-
Genomskinlig tunnling eller inspektionsproxy — Noderna är inte konfigurerade för att använda en specifik proxyserveradress. Inga HTTP- eller HTTPS-konfigurationsändringar är nödvändiga på noderna. Noderna behöver dock ett rotcertifikat så att de litar på proxyn. Inspektiva proxyer används vanligtvis av IT för att upprätthålla policyer för vilka webbplatser som kan besökas och vilka typer av innehåll som inte är tillåtna. Denna typ av proxy dekrypterar all din trafik (även HTTPS).
-
Explicit proxy — Med explicit proxy berättar du för HDS-noderna vilken proxyserver och autentiseringsschema som ska användas. Om du vill konfigurera en explicit proxy måste du ange följande information för varje nod:
-
Proxy IP/FQDN —Adress som kan användas för att nå proxydatorn.
-
Proxyport — Ett portnummer som proxyn använder för att lyssna efter proxy-trafik.
-
Proxyprotokoll — Beroende på vad din proxyserver stöder väljer du mellan följande protokoll:
-
HTTP — visar och kontrollerar alla förfrågningar som klienten skickar.
-
https — tillhandahåller en kanal till servern. Klienten tar emot och validerar serverns certifikat.
-
-
Autentiseringstyp — Välj bland följande autentiseringstyper:
-
Ingen — Ingen ytterligare autentisering krävs.
Tillgänglig om du väljer antingen HTTP eller HTTPS som proxyprotokoll.
-
Grundläggande — Används för en HTTP-användaragent för att ange ett användarnamn och lösenord när du gör en begäran. Använder Base64-kodning.
Tillgänglig om du väljer antingen HTTP eller HTTPS som proxyprotokoll.
Kräver att du anger användarnamn och lösenord för varje nod.
-
Sammanfattning —Används för att bekräfta kontot innan du skickar känslig information. Tillämpar en hashfunktion på användarnamnet och lösenordet innan du skickar över nätverket.
Endast tillgängligt om du väljer HTTPS som proxyprotokoll.
Kräver att du anger användarnamn och lösenord för varje nod.
-
-
Exempel på hybriddatasäkerhetsnoder och proxy
Detta diagram visar ett exempel på anslutning mellan Hybrid Data Security, nätverk och en proxy. För proxyalternativen transparent inspektion och HTTPS-explicit inspektion måste samma rotcertifikat installeras på proxyservern och på noderna för hybriddatasäkerhet.
Blockerat externt DNS-upplösningsläge (explicita proxykonfigurationer)
När du registrerar en nod eller kontrollerar nodens proxykonfiguration testar processen DNS-sökning och anslutning till Cisco Webex molnet. I distributioner med uttryckliga proxykonfigurationer som inte tillåter extern DNS-upplösning för interna klienter, om noden inte kan fråga DNS-servrarna, går den automatiskt till läget Blockerad extern DNS-upplösning. I det här läget kan nodregistrering och andra proxyanslutningstester fortsätta.
-
Vi stöder officiellt följande proxylösningar som kan integreras med dina Hybrid Data Security-noder.
-
Transparent proxy — Cisco Web Security Appliance (WSA).
-
Explicit proxy - bläckfisk.
Squid-proxyer som inspekterar HTTPS-trafik kan störa upprättandet av websocket (wss:) -anslutningar. Information om hur du kringgår problemet finns i Konfigurera Squid-proxyer för hybriddatasäkerhet.
-
-
Vi stöder följande kombinationer av autentiseringstyper för uttryckliga proxyservrar:
-
Ingen autentisering med HTTP eller HTTPS
-
Grundläggande autentisering med HTTP eller HTTPS
-
Sammanfattningsautentisering endast med HTTPS
-
-
För en transparent inspekterande proxy eller en HTTPS-explicit proxy måste du ha en kopia av proxyns rotcertifikat. Installationsinstruktionerna i den här guiden berättar hur du laddar upp kopian till Hybrid Data Security-nodernas förtroendelager.
-
Nätverket som är värd för HDS-noderna måste konfigureras för att tvinga utgående TCP-trafik på port 443 att dirigera genom proxyservern.
-
Proxyer som inspekterar webbtrafik kan störa webbsocketanslutningar. Om detta problem uppstår, kringgå (inte inspektera) trafik till
wbx2.comochciscospark.comkommer att lösa problemet.
Om nätverksmiljön kräver en proxy använder du den här proceduren för att ange vilken typ av proxy som du vill integrera med Hybrid Data Security. Om du väljer en transparent inspektionsproxy eller en HTTPS-explicit proxy kan du använda nodens gränssnitt för att ladda upp och installera rotcertifikatet. Du kan också kontrollera proxyanslutningen från gränssnittet och felsöka eventuella problem.
Innan du börjar
-
Se Proxy Support för en översikt över de proxyalternativ som stöds.
| 1 |
Ange webbadressen för HDS-nodkonfigurationen |
| 2 |
Gå till Trust Store & Proxy och välj sedan ett alternativ:
Följ nästa steg för en transparent inspektionsproxy, en uttrycklig HTTP-proxy med grundläggande autentisering eller en HTTPS-explicit proxy. |
| 3 |
Klicka på Ladda upp ett rotcertifikat eller slutentitet scertifikat och navigera sedan till ett välj rotcertifikat för proxyn. Certifikatet har laddats upp men ännu inte installerat eftersom du måste starta om noden för att installera certifikatet. Klicka på pilen vid certifikatutfärdarens namn för att få mer information eller klicka på Ta bort om du gjorde ett misstag och vill ladda upp filen igen. |
| 4 |
Klicka på Kontrollera proxyanslutning för att testa nätverksanslutningen mellan noden och proxyn. Om anslutningstestet misslyckas visas ett felmeddelande som visar orsaken och hur du kan åtgärda problemet. Om du ser ett meddelande om att extern DNS-upplösning inte lyckades kunde noden inte nå DNS-servern. Detta villkor förväntas i många explicita proxykonfigurationer. Du kan fortsätta med installationen, och noden kommer att fungera i läget Blockerad extern DNS-upplösning. Om du tror att det här är ett fel, utför du de här stegen och läser sedan In aktivera blockerat externt DNS-upplösningsläge. |
| 5 |
När anslutningstestet har passerat, för explicit proxy inställd på endast https, slå på växeln för att dirigera alla port 443/444 https-förfrågningar från den här noden via den explic ita proxyn. Den här inställningen tar 15 sekunder för att träda i kraft. |
| 6 |
Klicka på Installera alla certifikat i Trust Store (visas för en HTTPS-explicit proxy eller en genomskinlig inspektionsproxy) eller Starta om (visas för en explicit HTTP-proxy), läs prompten och klicka sedan på Installera om du är redo. Noden startar om inom några minuter. |
| 7 |
När noden har startat om loggar du in igen om det behövs och öppnar sedan sidan Översikt för att kontrollera anslutningskontrollerna för att se till att alla har grön status. Proxyanslutningskontrollen testar endast en underdomän till webex.com. Om det finns anslutningsproblem är ett vanligt problem att vissa av molndomänerna som anges i installationsinstruktionerna blockeras vid proxyn. |
När du registrerar en nod eller kontrollerar nodens proxykonfiguration testar processen DNS-sökning och anslutning till Cisco Webex molnet. Om nodens DNS-server inte kan lösa offentliga DNS-namn går noden automatiskt till läget Bloc kerad extern DNS-upplösning.
Om dina noder kan lösa offentliga DNS-namn via interna DNS-servrar kan du stänga av det här läget genom att köra proxyanslutningstestet på varje nod igen.
Innan du börjar
| 1 |
I en webbläsare öppnar du gränssnittet för hybriddatasäkerhet (IP-adress/inställning, till exempel https://192.0.2.0/setup), anger de administratörsuppgifter som du har ställt in för noden och klickar sedan på Log ga in. |
| 2 |
Gå till Översikt (standardsidan). 
När funktionen är aktiverad är Blockerad extern DNS-upplösning inställd på Ja. |
| 3 |
Gå till sidan Trust Store & Proxy. |
| 4 |
Klicka på Kontrollera proxyanslutning. Om du ser ett meddelande om att extern DNS-upplösning inte lyckades kunde noden inte nå DNS-servern och kommer att förbli i det här läget. Annars, efter att du har startat om noden och gått tillbaka till sidan Översikt, bör Blockerad extern DNS-upplösning ställas in på nej. |
Vad du ska göra härnäst
I det här avsnittet beskrivs proxystödfunktionen för Webex Video Mesh. Den är avsedd att komplettera distribu tionsguiden för Cisco Webex Video Mesh, tillgänglig på https://www.cisco.com/go/video-mesh. I en ny distribution konfigurerar du proxyinställningen på varje nod efter att du har distribuerat programvaran Video Mesh på en virtuell maskinmiljö och innan du registrerar noden i Cisco Webex molnet.
Video Mesh stöder uttryckliga, transparenta inspekterings- och icke-inspekterande proxyer. Du kan knyta dessa proxyer till din Video Mesh-distribution så att du kan säkra och övervaka trafiken från företaget ut till molnet. Den här funktionen skickar signalering och hantering https-baserad trafik till proxyn. För transparenta proxyer vidarebefordras nätverksförfrågningar från Video Mesh-noder till en specifik proxy via företagets nätverksroutningsregler. Du kan använda administratörsgränssnittet Video Mesh för certifikathantering och den övergripande anslutningsstatusen efter att du har implementerat proxyn med noderna.
Media reser inte genom proxyn. Du måste fortfarande öppna de portar som krävs för att mediaströmmar ska nå molnet direkt. Se Portar och protokoll för hantering.
Följande proxytyper stöds av Video Mesh:
-
Explicit proxy (inspekterar eller inte inspekterar) — Med explicit proxy talar du om för klienten (Video Mesh-noder) vilken proxyserver som ska användas. Det här alternativet stöder någon av följande autentiseringstyper:
-
Ingen — Ingen ytterligare autentisering krävs. (För HTTP- eller HTTPS-explicit proxy.)
-
Grundläggande — Används för en HTTP-användaragent för att ange ett användarnamn och lösenord när du gör en begäran, och använder Base64-kodning. (För HTTP- eller HTTPS-explicit proxy.)
-
Digest — Används för att bekräfta kontots identitet innan känslig information skickas, och tillämpar en hashfunktion på användarnamnet och lösenordet innan det skickas över nätverket. (För HTTPS-explicit proxy.)
-
NTLM — Liksom Digest används NTLM för att bekräfta kontots identitet innan känslig information skickas. Använder Windows-autentiseringsuppgifter istället för användarnamn och lösenord. Detta autentiseringsschema kräver flera utbyten för att slutföra. (För HTTP-explicit proxy.)
-
-
Transparent proxy (icke-inspekterande) —Video Mesh-noder är inte konfigurerade för att använda en specifik proxyserveradress och bör inte kräva några ändringar för att fungera med en icke-inspekterande proxy.
-
Transparent proxy (inspektion) —Video Mesh-noder är inte konfigurerade för att använda en specifik proxyserveradress. Inga http-konfigurationsändringar krävs på Video Mesh, men Video Mesh-noderna behöver ett rotcertifikat så att de litar på proxyn. Inspekterande proxyer används vanligtvis av IT för att upprätthålla policyer för vilka webbplatser som kan besökas och typer av innehåll som inte är tillåtna. Denna typ av proxy dekrypterar all din trafik (även https).
-
Vi stöder officiellt följande proxylösningar som kan integreras med dina Video Mesh-noder.
-
Cisco Web Security Appliance (WSA) för transparent proxy
-
Squid för explicit proxy
-
-
För en explicit proxy eller transparent inspekterande proxy som inspekterar (dekrypterar trafik) måste du ha en kopia av proxyns rotcertifikat som du måste ladda upp till Video Mesh-nodens förtroendelager i webbgränssnittet.
-
Vi stöder följande uttryckliga kombinationer av proxy och autentiseringstyp:
-
Ingen autentisering med http och https
-
Grundläggande autentisering med http och https
-
Sammanfattningsautentisering endast med https
-
NTLM-autentisering endast med http
-
-
För transparenta proxyer måste du använda router/switch för att tvinga HTTPS/443-trafik att gå till proxyn. Du kan också tvinga Web Socket att gå till proxy. (Web Socket använder https.)
Video Mesh kräver webbuttagsanslutningar till molntjänster, så att noderna fungerar korrekt. Vid uttrycklig inspektion och transparenta inspektionsproxyer krävs http-rubriker för en korrekt websocket-anslutning. Om de ändras kommer websocket-anslutningen att misslyckas.
När anslutningsfelet till websocket inträffar på port 443 (med transparent inspektionsproxy aktiverad) leder det till en varning efter registrering i Control Hub: ”Webex Video Mesh SIP-samtal fungerar inte korrekt.” Samma larm kan uppstå av andra skäl när proxy inte är aktiverat. När websocket-huvuden blockeras på port 443 flyter media inte mellan appar och SIP-klienter.
Om media inte flyter inträffar detta ofta när https-trafiken från noden över port 443 misslyckas:
-
Port 443-trafik tillåts av proxyn, men det är en inspekterande proxy och bryter websocketen.
För att rätta till dessa problem kan du behöva ”kringgå” eller ”skarva” (inaktivera inspektion) på port 443 till: *.wbx2.com och*.ciscospark.com.
-
Använd den här proceduren för att ange vilken typ av proxy som du vill integrera med ett videonät. Om du väljer en transparent inspektionsproxy eller en explicit proxy kan du använda nodens gränssnitt för att ladda upp och installera rotcertifikatet, kontrollera proxyanslutningen och felsöka eventuella problem.
Innan du börjar
-
Se Proxystöd för Video Mesh för en översikt över de proxyalternativ som stöds.
| 1 |
Ange inställningsadressen för videomätet | ||||||||||
| 2 |
Gå till Trust Store & Proxy och välj sedan ett alternativ:
Följ nästa steg för en transparent inspektion eller explicit proxy. | ||||||||||
| 3 |
Klicka på Ladda upp ett rotcertifikat eller slutentitetscertifikat och leta upp och välj rotcertifikatet för den uttryckliga eller transparenta inspektionsproxyn. Certifikatet har laddats upp men ännu inte installerat eftersom noden måste startas om för att installera certifikatet. Klicka på pilen vid certifikatutfärdarens namn för att få mer information eller klicka på Ta bort om du gjorde ett misstag och vill ladda upp filen igen. | ||||||||||
| 4 |
För genomskinlig inspektion eller uttryckliga proxyservrar klickar du på Kontrollera proxyanslutning för att testa nätverksanslutningen mellan Video Mesh-noden och proxyn. Om anslutningstestet misslyckas visas ett felmeddelande som visar orsaken och hur du kan åtgärda problemet. | ||||||||||
| 5 |
När anslutningstestet har passerat, för explicit proxy, slå på växeln för att dirigera alla port 443 https-förfrågningar från den här noden via den uttryckliga proxyn. Den här inställningen tar 15 sekunder för att träda i kraft. | ||||||||||
| 6 |
Klicka på Installera alla certifikat i Trust Store (visas när ett rotcertifikat läggs till under proxyinstallationen) eller Star ta om (visas om inget rotcertifikat har lagts till), läs prompten och klicka sedan på Installera om du är redo. Noden startar om inom några minuter. | ||||||||||
| 7 |
När noden har startat om loggar du in igen om det behövs och öppnar sedan sidan Översikt för att kontrollera anslutningskontrollerna för att se till att alla har grön status. Proxyanslutningskontrollen testar endast en underdomän till webex.com. Om det finns anslutningsproblem är ett vanligt problem att vissa av molndomänerna som anges i installationsinstruktionerna blockeras vid proxyn. |
Vilken trafik går via proxy
För Video Mesh korsar media inte proxyn. Den här funktionen skickar signalering och hantering https-baserad trafik till proxyn. Du måste fortfarande öppna de portar som krävs för att mediaströmmar ska nå molnet direkt.
TCP-port 444 är inte aktiverad på proxy
Den här porten är ett krav för Video Mesh, eftersom Video Mesh använder den här porten för att komma åt molnbaserade tjänster som den måste använda för att fungera korrekt. Ett proxy-undantag måste göras för den här porten och ALLA som dokumenterats i Video Mesh-distributionsguiden och N ätverkskrav för Webex Teams Services.
Filtrering av signaltrafik efter IP-adress stöds inte eftersom IP-adresserna som används av våra lösningar är dynamiska och kan ändras när som helst.
Inget rotcertifikat installerat
När dina noder pratar med en explicit proxy måste du installera rotcertifikatet och ange ett undantag för den webbadressen i brandväggen.
Anslutningskontrollen misslyckas
Om proxyanslutningskontrollen godkändes och proxyinstallationen slutfördes kan anslutningskontrollerna på översiktssidan fortfarande misslyckas av följande skäl:
-
Proxyservern inspekterar trafik som inte går till webex.com.
-
Proxyservern blockerar andra domäner än webex.com.
Autentiseringsuppgifterna är felaktiga
För proxyservrar som använder en autentiseringsmekanism, se till att du lägger till rätt autentiseringsinformation i noden.
Trängsel på proxy
Trängsel på din proxy kan orsaka förseningar och droppar med trafik till molnet. Kontrollera din proxymiljö för att se om trafikbegränsning krävs.
Websocket kan inte ansluta via Squid Proxy
Squid-proxyer som inspekterar HTTPS-trafik kan störa upprättandet av websocket (wss:) -anslutningar som Hybrid Data Security kräver. Dessa avsnitt ger vägledning om hur du konfigurerar olika versioner av Squid för att ignorera wss:trafik för korrekt drift av tjänsterna.
Bläckfisk 4 och 5
Lägg till on_unsupported_protocoldirektivet squid.confi
on_unsupported_protocol tunnel allBläckfisk 3.5.27
Vi testade framgångsrikt Hybrid Data Security med följande regler tillagda squid.conf. Dessa regler kan komma att ändras när vi utvecklar funktioner och uppdaterar Webex-molnet.
acl wssMercuryConnection ssl::server_name_regex mercury-connection
ssl_bump splice wssMercuryConnection
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1 all
ssl_bump stare step2 all
ssl_bump bump step3 all
