Onze kantoor netwerken hebben interne DNS ingesteld. Wanneer een gebruiker verbindt met een van deze netwerken, en probeert een interne URL te bezoeken zoals bob.internal.net (We hebben split brain DNS, intern en extern die hetzelfde domein gebruiken), wordt het interne IP-adres opgelost, wat voorkomt dat ze de pagina succesvol bereiken omdat we geen IP’s in het app-segment toestaan.
Een van de aanpakken die we hebben genomen om dit op te lossen, is door een volledig nieuw draadloos netwerk te creëren en alleen externe DNS erop in te stellen. Deze methode werkt, maar het vereist dat gebruikers verbinding maken met dit wifi-netwerk, en soms doen ze dat niet en wordt hun toegang geblokkeerd.
We kunnen deze DNS-wijziging niet maken op de bestaande LAN/WIFI-netwerken omdat dit bepaalde dingen zou breken. Weet iemand of er een oplossing is voor het bovenstaande waarbij het een naadloze migratie zou zijn voor onze gebruikers?
Ik ben terug gegaan naar AnyConnect. Een andere optie is het gebruik van de dig CLI op infoblox. Ik doe vaak nslookup voor firewall beveiligingsbeleid. Bedankt
We zitten in hetzelfde schuitje rond ZPA die het DNS-verkeer onderschept en de carrier grade NAT van 100.64.x.x teruggeeft. We moeten blijven overschakelen op onze legacy VPN-oplossing voor nauwkeurige zoekopdrachten.
Misschien onrustig, maar kunnen we alle DNS-verzoeken die worden onderschept vermijden waardoor de juiste lookup wordt geproduceerd?
Ik weet dat dit tegen zero trust ingaat. Maar het is ook een bezwaar voor een grootschalige implementatie omdat technische mensen dat vereisen.
Nog meer ideeën hoe dit ZPA vs nslookup gedoe te omzeilen. Zscaler heeft geen workaround geboden. De andere optie die ik heb, is ZPA uit te schakelen en Cisco VPN te gebruiken.
Ik weet niet zeker of ik de bovenstaande vraag volg. Als ZPA is ingeschakeld in het kantoor en de URL bob.internal.net is voor de gebruiker gedefinieerd, lijkt het alsof het gewoon zoals voorheen wordt verzonden en door de App-connector wordt opgelost. Ik weet niet waarom definiëren op IP nodig zou zijn omdat het door de App-connector wordt geproxied. Ik neem aan dat dit een ZPA-vraag is op basis van de genoemde app-segmentatie. Ik weet dat sommigen ZPA uitschakelen in het kantoor of slechts bepaalde applicaties doorsturen die niet native bereikbaar zijn, terwijl ze in het kantoor zijn, zoals geïsoleerde cloudomgevingen die alleen via een App-connector in de Cloud VNET/VPC kunnen worden bereikt.
We hebben een infoblox DNS-server die alle records ophaalt van onze Active Directory-server, wat ons helpt nslookups op te lossen door “nslookup serverip infobloxdnsserverIp” uit te voeren, en dat lijkt voor ons te werken.
Weet niet of je hier ooit een oplossing voor hebt gevonden, maar je kunt een gerichte nslookup uitvoeren door de server te specificeren waar je op zoekt. (nslookup hostnaam.xyz dnsserver) dit toont je het juiste record zolang je ZPA port 53-verkeer onderschept.
We hebben dit probleem inmiddels opgelost. Een manier om dit te omzeilen was door een aparte DNS-server te creëren, eentje die geen deel uitmaakt van de DHCP DNS-servers.
ZCC onderschept de DNS-lookups. Het manipuleren van DNS-resultaten is een methode die Zscaler-gebruikers gebruiken om clients correct te leiden naar de juiste service/doel.
Door het domein in je eigen DNS-bypasslijst te plaatsen en te manipuleren via split-brain DNS, zal de ZCC-client nooit DNS-resultaten voor dat domein onderscheppen en manipuleren.
Werkt het met ZPA? Het hangt ervan af. Als dit domein onderdeel is van de services die je hebt gedefinieerd in een App-segment in ZPA, dan kun je het niet toevoegen aan DNS-bypass, omdat ZPA afhankelijke is van het onderscheppen van de DNS-aanroep voor die domeinen om een DNAT-adres te bieden om het pad van het clientverkeer te manipuleren. Als dit domein niet onderdeel is van je gedefinieerde apps in ZPA, dan werkt het wel met ZPA.