Hej allihop,
Jag har en kund som har problem med en specifik applikation när denne ansluter till den via SSL VPN. Problemet är intermittent.
Fortigate: 1800F, version 7.2.5
Forticlient EMS: 7.2.0
FortiClient: 7.2.0
Interna användare (kontorsanvändare) kan ansluta till applikationen perfekt, inga problem alls. Endast SSL VPN-användare har problem när de försöker ansluta, nästan varje användare (runt 15 personer) har problem att koppla upp sig mot den applikationen.
Så när SSL VPN-användare försöker ansluta till applikationen, kan de minst 2-3 gånger per dag inte komma åt den, eller så tar det ofta lång tid att koppla upp sig. På grund av restriktioner och säkerhetsåtgärder kan jag inte nämna vilken applikation det gäller.
Men min fråga är mer, vilka slags felsökningssteg kan jag följa förutom dessa länkar: https://docs.fortinet.com/document/fortigate/7.2.5/administration-guide/993282 https://docs.fortinet.com/document/fortigate/7.2.5/administration-guide/502390
I princip, det jag letar efter är att dessa länkar verkar mer handla om att användare har problem att koppla till SSL VPN, snarare än att felsöka användares åtkomst till olika program/tjänster via SSL VPN. Finns det andra felsökningsguider jag kan följa? Jag har försökt att leta efter olika dokumentationer, men det finns inga. Återigen, att koppla till SSL VPN är helt perfekt, det är när de försöker få tillgång till en specifik applikation som problemen börjar.
Tacksam för hjälp.
Först och främst, baserat på eget erfarenhet, skulle jag rekommendera att uppgradera till FortiClient 7.2.1 eller (om möjligt) 7.0.7. 7.2.0 var mycket buggig för oss i testning med alla möjliga skumma problem.
Annars, med din “mysterious application”, vad visar loggar, flödesdebugs och paketupptagningar? Börja där. Det viktigaste Fortigate-specifika du bör titta på är hur man gör en ‘debug flow’, eftersom det visar paketvägar och intern logik på Fortigate-sidan, resten är vanlig nätverksfelsökning.
Utan debug är det svårt att säga. Kanske ett UTM-objekt är tillämpat och avvisar paketet, eller en specifik port används som inte är tillåten. Vi vet inte heller om intern trafik är riktad från brandväggen eller inte.
Dela-tunnel? Vilket specifikt fel får användarna när applikationen inte kan ansluta? Är det ett DNS-problem?
Om det är en gammal skolans applikation som kommunicerar med en databas kan du underskatta hur mycket data klienten drar in från servern.
En annan sak som användare inte förstår är att du kan ha gigabit-internet hemma, men det betyder inte att du kommer att ladda ner så mycket till en specifik IP. Jag upptäckte min första lösning eftersom min gamla chef vägrade betala för något med garanterad bandbredd mellan kritiska kontor. Jag skulle inte kunna sova om jag inte visste hur lång tid vissa arbetsprodukter skulle ta att komma över.
Och som andra har sagt, latens. Till exempel, om applikationen blir mycket pratig kan den göra en databas-applikation till sin knäna. Säg till exempel att en fråga tar 2 ms att hämta från databasen men tar 60 ms att gå över, multiplicerat med frågor för 100 olika “order” i serie.
Så nog om problemet, detta gav mig min sinnesro, LAN Speed Test Lite, om du kan skriva data till en UNC-väg. Det kan skapa en fil av en viss storlek, standard är 20 megabyte, på en filshare och sedan läsa tillbaka den, vilket ger dig “hastigheten” i flera olika enheter. Det är teoretiskt inte exakt om QoS används, men ger en bra indikation.
Nyligen upptäckte jag Openspeedtest, som du lägger på en intern webbserver. Den har till och med IIS-instruktioner. Det är ett bra hastighetstest tillbaka till ditt nätverk. Och det bör vara lättare för slutanvändare. Denna är lite konstig beroende på din webbläsare, jag tror Firefox cachar testdata och ger dig en otroligt hög siffra i en okänd riktning.
Här är en till, köp ping plotter för 40 dollar, eller planera vad du vill testa och gör det på den deras tvåveckors trial. Du kan låta den pinga något av det IP-intervallet och den rapporterar din paketförlust och jitter, vilket jag inte tänker gå in på här. Sedan får du ett fint diagram. Jag använde det en gång för att visa att det var en överbelastad WAN-länk under kontorstid, då fanns jitter och paketförlust. Det som avgjorde min slutsats var att efter ett par timmars normal anslutning skulle den återigen bli dålig vid varje hel timme när backup till HQ startade…
Detta är också vad jag skulle rekommendera. Om du har olika inspektionsfilter för lokal versus VPN-trafik skulle jag titta på säkerhetsloggar för att se om din applikation blir fångad där. Att inaktivera inspektioner eller bryta SSLVPN-trafiken för applikationen i en separat policy skulle vara min startpunkt.
Okej, jag är medveten om debug-flöden och sniffere också, men jag är inte säker på varför dessa tester inte skulle vara lämpliga för detta problem… Jag tänkte på tester i liknande stil som de länkar jag postade.
Jag kommer definitivt att göra debug. Tack.