Konfigurera Sophos Firewall Clientless SSL VPN för RDP och SSH

Med Clientless SSL VPN gör en Sophos Firewall enskilda interna RDP-, SSH-, VNC- eller filserveranslutningar tillgängliga direkt i webbläsaren. Användaren installerar ingen VPN-klient och får ingen allmän åtkomst till ett internt nätverk. I stället loggar användaren in på VPN Portal och ser endast de bookmarks som publiceras av användarens Clientless Policy.

Det liknande namnet kan lätt leda till fel konfiguration: Clientless Users kopplar internt en fast IP-adress till en identitet. Det publicerar inga bookmarks och ingår inte i denna Remote Access-procedur.

Inloggningen på VPN Portal och inloggningen på målsystemet är två separata steg. Clientless SSL VPN stöder inte Credential Passthrough: lösenordet till VPN Portal vidarebefordras inte automatiskt till Windows- eller SSH-inloggningen. Två inloggningar är därför normalt så länge inga inloggningsuppgifter för målsystemet är lagrade i bookmarken.

Huvudförloppet är kort:

Ange ett fast målsystem, port och behörig användargrupp.
Skapa en RDP- eller SSH-bookmark under Remote access VPN > Clientless SSL VPN policy > Bookmarks.
Koppla samman användargruppen och bookmarken under Policies.
Säkra VPN Portal, certifikat, autentisering, MFA och Device Access.
Testa åtkomsten externt under VPN > Clientless access connections med en behörig och en obehörig användare.

När Clientless SSL VPN passar – och när det inte gör det

Clientless Access passar särskilt bra för ett fåtal fasta mål, tillfällig åtkomst eller externa tekniker när ingen VPN-klient ska installeras på den använda enheten. RDP och SSH behöver då inte publiceras direkt på internet via DNAT. I stället är den säkrade VPN Portal offentligt tillgänglig.

Det ersätter däremot inte alla Remote Access VPN-scenarier:

Clientless SSL VPN passar för enskilda statiska RDP-, SSH-, VNC- eller filservermål som kan användas i webbläsaren.
Sophos Connect med IPsec eller SSL VPN passar bättre när en hanterad enhet behöver flera nätverk, nativa program, DNS eller olika protokoll. Beslutsguiden för Remote Access förklarar alternativen.
ZTNA är avsett för permanent programorienterad åtkomst med identitet, enhetsstatus och centrala policies. Grunderna finns i Vad är Zero Trust Network Access?.
RD Gateway, Jump Host eller PAM bör övervägas när privilegierad administration, personliga målkonton, sessionsinspelning eller godkännandeflöden är avgörande.

För RDP är det också viktigt att urklipp inte stöds i Clientless-sessioner sedan SFOS 19. Om copy-and-paste eller andra inbyggda RDP-funktioner är obligatoriska för arbetsflödet är en klientbaserad eller specialiserad åtkomstväg ett bättre val.

Clientless SSL VPN stöder inte dynamiska mål-IP-adresser. Ett värdnamn får användas som mål, men brandväggen måste kunna slå upp det stabilt och det måste peka på det avsedda systemet. Ett mål som ändras ofta bör inte planeras som ett Dynamic DNS-scenario som förväntas uppdateras tillförlitligt.

Webbläsaren är endast användargränssnittet: den upprättar HTTPS-anslutningen till VPN Portal, medan Sophos Firewall upprättar den andra anslutningen till målet. Popup-blockeraren måste tillåta det nya fönstret för portalens FQDN. SFOS 22 kan inte publicera valfria interna HTTP- eller HTTPS-program som Clientless-bookmarks; använd WAF eller ZTNA beroende på kraven.

Krav och exempelvärden

Före konfigurationen bör mål, identitet och portalåtkomst vara fastställda:

Målsystemet kan nås från brandväggen via routing och DNS, och den tjänst som behövs körs.
En användare eller helst en snävt avgränsad grupp finns på brandväggen eller den anslutna autentiseringsservern.
VPN Portal har ett offentligt eller internt åtkomligt FQDN och ett matchande betrott certifikat.
Under Authentication > Services har en lämplig metod valts under VPN portal authentication methods.
MFA och en oberoende återställningsåtkomst har förberetts.
Det har beslutats om inloggningsuppgifter för målsystemet får lagras i bookmarken.

Följande RDP-exempel använder:

VPN Portal: https://vpn.example.com
målserver: rdp-app01.intern.example
mål-IP: 10.20.30.25
RDP-port: 3389
bookmark: RDP-Fibu-Test
grupp: Clientless-RDP-Fibu
policy: Clientless-RDP-Fibu
RDP-säkerhet för det första testet: TLS
Automatic login: inaktiverat
Share session: inaktiverat

example.com är en reserverad exempeldomän och 10.20.30.25 är en privat exempeladress. FQDN, IP, grupp och namn måste ersättas med värden från den egna miljön. Port 3389 är endast korrekt om Windows-servern faktiskt använder RDP-standardporten.

Konfigurera RDP-bookmarken

Bookmark med TLS och personlig målinloggning

Under Remote access VPN > Clientless SSL VPN policy > Bookmarks skapas en ny bookmark med Add:

Ange RDP-Fibu-Test under Name.
Välj RDP som Type.
Ange rdp-app01.intern.example eller den fasta IP-adressen 10.20.30.25 under URL.
Använd tjänsteporten 3389. En annan port anges endast om den avsiktligt har konfigurerats annorlunda på målsystemet.
Låt Automatic login vara inaktiverat för det första testet.
Ange Windows-nätverksdomänen vid behov, till exempel CORP eller corp.example.com.
Välj TLS under Protocol security. Det tredje alternativet, RDP, använder RDP-protokollets egen säkerhet; Sophos rekommenderar i stället TLS eller NLA.
Låt Share session vara inaktiverat.
Spara med Save.

Utan Automatic login anger användaren sina inloggningsuppgifter i det öppnade RDP-fönstret. Inloggningen kan då göras med ett personligt Windows-konto, förutsatt att målsystemets säkerhetsmodell tillåter detta TLS-läge.

Certifikatet för VPN Portal och Protocol security: TLS har olika uppgifter. Portalcertifikatet skyddar webbläsarvägen till brandväggen. RDP-inställningen skyddar den efterföljande anslutningen från brandväggen till Windows-systemet. Ett giltigt portalcertifikat ersätter därför inte lämplig RDP-säkerhet.

När Windows-servern kräver NLA

Många Windows-system kräver Network Level Authentication (NLA). I så fall väljs NLA i bookmarken. SFOS aktiverar då Automatic login, och användarnamn och lösenord för målsystemet måste lagras i bookmarken.

Det är inte en ren bekvämlighetsfunktion. Alla behöriga användare av denna bookmark arbetar då på målsystemet med samma lagrade Windows-identitet. Endast ett dedikerat konto med minimala behörigheter som går att rotera bör användas för detta. Domain Admin-konton, personliga administratörskonton och brett behöriga tjänstekonton hör inte hemma i en Clientless Bookmark.

NLA bör inte inaktiveras på Windows-servern enbart för att TLS-exemplet ska fungera. Om lagrade inloggningsuppgifter eller en gemensam målidentitet inte är acceptabla passar Clientless RDP inte för den här servern. En vanlig VPN, RD Gateway, PAM eller en kontrollerad Jump Host bevarar den personliga spårbarheten bättre.

Share session förblir också inaktiverat. Alternativet är avsett för ett medvetet planerat samarbetsfall. I en delad session avslutar Stop session anslutningen för alla deltagare, medan Suspend session endast pausar den aktuella användaren. En session för privilegierad administration bör inte delas.

VNC-bookmark för Linux- och UNIX-system

En VNC-bookmark följer samma grundprincip men använder Type: VNC. Under URL anges målsystemets fasta IP-adress eller ett stabilt namn som kan lösas upp. En annan VNC-port anges endast om tjänsten faktiskt lyssnar på en port som avviker från standardporten.

Med Automatic login lagrar SFOS mållösenordet i VNC-bookmarken. Om alternativet förblir inaktiverat anger användaren lösenordet när anslutningen öppnas. Inget användarnamn konfigureras i en VNC-bookmark. Share session förblir inaktiverat för normal individuell åtkomst och används endast när en delad session uttryckligen krävs.

ℹ️ Inloggningen i VPN Portal vidarebefordras inte heller till målsystemet för VNC. En lyckad portalinloggning bevisar därför varken att VNC-lösenordet är korrekt eller att brandväggen kan nå VNC-tjänsten.

Konfigurera Clientless Policy och VPN Portal

Koppla användare och bookmark i en policy

En befintlig bookmark gör inte i sig målet synligt för någon användare. Det är först policyn som kopplar samman identitet och resurs:

Öppna Remote access VPN > Clientless SSL VPN policy.
Klicka på Add under Policies.
Ange Clientless-RDP-Fibu som Name.
Välj endast gruppen Clientless-RDP-Fibu under Policy members.
Välj RDP-Fibu-Test under Published bookmarks.
Spara med Apply.

En Bookmark Group är först motiverad när samma användare behöver flera mål. För ett enskilt RDP-mål skapar den bara ett extra administrationslager.

Säkra VPN Portal

Användaren öppnar Clientless-anslutningar via VPN Portal. Standardporten är 443; port och certifikat finns under Administration > Admin and user settings > Admin console and end-user interaction. I exemplet måste certifikatet innehålla vpn.example.com som SAN och godtas av webbläsaren utan varning. Importera och tilldela certifikat på Sophos Firewall förklarar den allmänna certifikattilldelningen.

Under Administration > Device access måste VPN portal tillåtas för den åtkomst som faktiskt behövs. Om portalen ska vara åtkomlig från alla WAN-källor aktiveras WAN i matrisen. Vid kända källnätverk är den snävare varianten bättre: låt WAN vara inaktiverat i matrisen och skapa under Local service ACL exception rule en regel med Source zone: WAN, det konkreta Source Network / Host, den brandväggsadress som behövs som Destination host, Services: VPN portal och Action: Accept. Ett ytterligare Accept-undantag begränsar inte en WAN-matrisbehörighet som redan har aktiverats generellt. WebAdmin, User Portal, SSH eller SSL VPN aktiveras inte automatiskt samtidigt. Firewall Rules styr inte dessa lokala tjänster. Den säkra planeringen finns i Device Access och Local Service ACL.

⚠️ En VPN Portal som kan nås från WAN är en offentlig inloggningsyta. Den bör inte användas utan MFA, ett betrott certifikat, snävt policymedlemskap och övervakning av inloggningar. Om VPN Portal och SSL VPN använder samma port fungerar inte Login security settings. Om de även använder samma protokoll gör en SSL VPN-tillåtelse från en zon också VPN Portal åtkomlig, även om portalen är inaktiverad för zonen under Device access. Använd en unik kombination av port och protokoll för varje lokal tjänst och kontrollera åtkomsten igen efter varje portändring.

För lokal Sophos OTP används först Specific users and groups under Authentication > Multi-factor authentication. För självregistrering via en autentiseringsapp aktiveras Generate OTP token with next sign-in, VPN portal väljs under Require MFA for och inställningen sparas med Apply. Detta direkta QR-flöde i VPN Portal gäller SFOS 22. I SFOS 23, med Generate OTP token with next sign-in aktiverat, väljer man även Share QR code före Apply: Email skickar QR-koden via e-post vid nästa inloggning på VPN eller User Portal; Portals visar den i User Portal och VPN Portal efter nästa inloggning på VPN Portal, User Portal eller WebAdmin. Välj uttryckligen Portals för exemplet med skanning i portalen.

SFOS 22 stöder SHA1, SHA256 och SHA512, och Sophos rekommenderar SHA256 eller SHA512. Appen måste dock stödja den valda algoritmen: Intercept X for Mobile och Google Authenticator fungerar; Microsoft Authenticator kan skanna en kod med SHA256 eller SHA512, men den efterföljande inloggningen misslyckas.

Vid ett algoritmbyte raderas befintliga tokens under Issued tokens, varefter användarna skannar QR-koden igen. Kontrollera före raderingen att Generate OTP token with next sign-in är aktiverat för detta flöde. Den nya QR-koden levereras enligt samma versionsskillnad: SFOS 22 visar koden i portalen; SFOS 23 använder Email eller Portals under Share QR code, med Portals fortsatt valt för detta exempel. Pilotfasen och återställningsvägen finns i Aktivera MFA för Sophos Firewall.

VPN Portal stöder inte challenge-baserad RADIUS-MFA. En befintlig RADIUS-metod måste därför testas specifikt för denna portalinloggning. Om portalen i stället ska använda Microsoft Entra ID SSO och Conditional Access beskriver Entra ID SSO för Sophos Connect och VPN Portal hela identitetskedjan.

Under Authentication > Services kan högst 20 servrar väljas per autentiseringsmetod. De globala inställningarna Maximum session timeout och Simultaneous logins gäller inte bara VPN Portal. SFOS kontrollerar behörigheten var tredje minut, och begränsningen av samtidiga inloggningar gäller endast användare som läggs till efter att värdet har ställts in. Dessa gränser ska därför inte betraktas som omedelbara, portalspecifika åtkomstkontroller.

Testa åtkomst utifrån

Testet bör utföras från ett verkligt externt nätverk, till exempel via en mobil hotspot. Ett test från LAN bevisar inte att DNS, certifikat, Device Access och en framförliggande router fungerar korrekt från internet.

Öppna https://vpn.example.com i ett privat webbläsarfönster.
Kontrollera certifikatnamn, certifikatkedja och webbläsarstatus.
Logga in som medlem i Clientless-RDP-Fibu och slutför MFA.
Kontrollera under VPN > Clientless access connections att RDP-Fibu-Test visas.
Klicka på Connect. Sessionen måste öppnas i ett nytt webbläsarfönster.
När Automatic login är inaktiverat anger man de personliga Windows-inloggningsuppgifterna och testar RDP-inloggningen.
Logga ut korrekt från sessionen på Windows-systemet och lämna sedan VPN Portal.
Testa med en användare utanför gruppen. Bookmarken får inte visas där.
Ta tillfälligt bort testanvändaren från policygruppen och kontrollera att åtkomsten försvinner efter en ny inloggning.

Ett lyckat resultat innebär inte bara att ett skrivbord visas. Den behöriga användaren ser exakt de avsedda bookmarks, den obehöriga användaren ser inga, MFA tillämpas, certifikatet är betrott, målinloggningen fungerar och sessionen avslutas spårbart på både portalen och målsystemet.

Använd sessions- och tangentbordskontroller i webbläsaren

I RDP-, VNC-, SSH- och Telnet-sessioner flyttar man pekaren till överkanten av den fjärranslutna skärmen för att visa sessionsalternativen. Under Connection finns Stop session och Suspend session. Efter Suspend session återupptar samma användare sessionen nästa gång de klickar på Connect i VPN Portal. Andra deltagare i en delad session fortsätter att arbeta; Stop session avslutar däremot sessionen för alla.

För RDP- och VNC-anslutningar kan användare under Keyboard välja tangentbordsgenvägar och ändra tangentbordsspråk. För att använda ett språk i listan som inte är engelska kräver det dokumenterade förfarandet att målserverns språk är inställt på US English. Detta krav gäller språkvalet under Keyboard, inte urklipp.

Alternativ för SSH, VNC och filservrar

SSH-bookmark med verifierad Host Key

För SSH väljs SSH som Type under Bookmarks > Add. Ett exempel använder srv-linux01.intern.example, port 22 och användaren clientless-test.

Public host key måste tillhöra den förväntade servern. På ett Linux-mål kan den offentliga Host Key visas direkt i den betrodda serverkonsolen och dess fingerprint dokumenteras:

sudo cat /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Dessa kommandon körs på Linux-målservern, inte på Sophos Firewall. Om servern använder en annan Host Key-typ måste filnamnet anpassas. En nyckel från en overifierad webbläsarvarning eller en godtycklig nätverksskanning får inte användas utan kontroll.

Det första kommandot visar den offentliga ED25519 Host Key som ett identifieringsexempel på målsystemets betrodda konsol. Detta bekräftar inte att den installerade clientless-SSH-builden accepterar ED25519 eller den visade OpenSSH-representationen under Public host key. Bekräfta före infogning både den accepterade algoritmen och den serialiserade representationen av den offentliga nyckeln med hjälp av den officiella clientless-SSH-dokumentationen för den builden eller med Sophos Support. Linux SSH-stöd, WebAdmin SSH-inställningar, SFTP och identiska källtexter bevisar inte denna fältkompatibilitet. Det andra kommandot visar endast fingerprint för den dokumenterade jämförelsen. Fingerprint ska inte kopieras till fältet i stället för nyckeln.

Därefter skapas hela SSH-bookmarken:

Ange exempelvis SSH-Linux-Test under Name.
Välj SSH som Type.
Ange srv-linux01.intern.example under URL och port 22.
Ange clientless-test eller den avsedda målanvändaren under Username.
Låt Automatic login vara inaktiverat om användaren ska ange mållösenordet själv.
Infoga den offentliga Host Key som har verifierats direkt på målsystemet under Public host key först efter att algoritm och representation har bekräftats för den installerade clientless-SSH-builden.
Låt Share session vara inaktiverat och spara med Save.
Lägg till bookmarken i Clientless Policy under Published bookmarks och spara med Apply.
Klicka på Connect under VPN > Clientless access connections i VPN Portal, ange mållösenordet och kontrollera att förväntad Terminal Prompt visas. Avsluta sedan SSH-sessionen korrekt.

Utan Automatic login anger användaren mållösenordet när anslutningen upprättas. Användarnamnet förblir en del av bookmarken. Olika personliga SSH-användarnamn kräver därför separata bookmarks eller en annan åtkomstväg. Med Automatic login kan SFOS använda lösenord eller Private Key. Privilegierade eller brett använda Private Keys bör inte lagras i en gemensamt publicerad bookmark.

Filservrar med FTP, FTPS, SFTP eller SMB

Bookmarks för filservrar skapas också under Remote access VPN > Clientless SSL VPN policy > Bookmarks > Add. Under Type finns FTP, FTPS, SFTP och SMB. URL innehåller en fast IP-adress eller ett stabilt hostname; Clientless SSL VPN stöder inte dynamiska måladresser. Under Init remote folder kan man valfritt ange den mapp där användaren börjar efter anslutningen.

Metoderna skiljer sig främst åt genom transport och autentisering mot målet:

FTP, FTPS och SMB kan användas med eller utan Automatic login. Utan lagrade inloggningsuppgifter loggar användaren in på målsystemet efter att bookmarken har öppnats. FTP överför data okrypterat och bör inte användas för nya externa workflows.
För SMB går det också att valfritt ange den Windows-nätverksdomän som målkontot och målsystemet tillhör, till exempel CORP, corp.example eller corp.example.com. Ersätt dessa exempel med den faktiska domänen i den egna miljön.
FTPS skyddar FTP-anslutningen med TLS. Under Public host key lagras dessutom det förväntade servercertifikatet i .pem-format. Certifikatet och namnet verifieras direkt på det hanterade målsystemet och hämtas inte från en overifierad anslutning.
SFTP använder SSH. Bookmarken innehåller målanvändaren och under Authentication method antingen Password eller Private key med motsvarande inloggningsuppgift för målet. Public host key används för att verifiera serverns identitet. Användarens privata nyckel och serverns offentliga Host Key har olika uppgifter och får inte förväxlas.

⚠️ Inmatningsformatet för Public host key vid SFTP är fortfarande oklart: filserverinstruktionerna för SFOS 22 och 23 anger ett servercertifikat i .pem-format, medan de separata SSH-instruktionerna kräver en offentlig servernyckel. Detta bekräftar varken ett X.509-krav eller att OpenSSH- eller ED25519-värden accepteras i SFTP-fältet. SSH-kommandona ovan är därför ingen formatguide för SFTP. Klargör före produktionsanvändning med Sophos Support vilken SFTP-representation den installerade builden accepterar och verifiera serveridentiteten direkt på det betrodda målsystemet; konvertera inte format genom gissningar och kringgå inte identitetskontrollen.

Även för filserver-bookmarks anges en annan tjänsteport endast om motsvarande tjänst på målservern faktiskt använder en annan port än standardporten.

Med Automatic login lagras målsystemets användarnamn och lösenord i bookmarken för FTP, FTPS och SMB. Alla behöriga användare använder då denna lagrade målidentitet, så samma krav på minsta möjliga behörighet och rotation gäller som i NLA-exemplet. Detta är inte Credential Passthrough från VPN Portal.

I detta SFTP-förfarande autentiserar SFOS automatiskt med de inloggningsuppgifter för målet som lagras i bookmarken. Användaren uppmanas inte att ange mållösenordet; den valfria interaktiva inloggningen för SSH, FTP, FTPS och SMB gäller inte för SFTP.

I webbläsaren kan användare i FTP-, FTPS- och SFTP-sessioner överföra filer, skapa mappar och navigera mellan kataloger. SFOS startar hämtningar utan ytterligare fråga och sparar dem i endpointens standardmapp för hämtningar. Därför bör behörigheter, startmapp och ett test med icke-känsliga filer verifieras före produktionsanvändning. En filserver-bookmark skapar ingen vanlig Windows-nätverksenhet och ersätter inte personlig behörighetskontroll på målservern.

Knapparna uppe till höger i FTP-, FTPS- och SFTP-sessioner används för att stoppa sessionen, ladda upp en fil, skapa en mapp och gå till den överordnade mappen.

Telnet finns fortfarande som terminaltyp men saknar både transportkryptering och en verifierbar SSH-värdnyckel. Det bör inte användas för nya åtkomster. HTTP- och HTTPS-bookmarks ingår inte i de Clientless-typer som för närvarande dokumenteras för SFOS 22. För interna webbapplikationer är Web Application Firewall eller ZTNA en lämpligare arkitektur, beroende på skyddsbehovet.

Om en äldre enhet tillfälligt kräver Telnet väljer du Type: Telnet under Bookmarks > Add, anger den fasta värden under URL och ställer bara in porten om den avviker från standarden. Share session är valfritt. Begränsa denna okrypterade åtkomst till en liten grupp och ett isolerat hanteringsmål och ersätt den sedan med SSH.

När samma mål ska tilldelas flera policies skapas en grupp under Bookmark groups > Add: ange gruppnamnet under Name, välj befintliga bookmarks med Add new item och spara med Save. Policyn publicerar sedan gruppen i stället för varje mål separat. En Bookmark Group utökar inte behörigheterna på målsystemet; den förenklar endast tilldelningen i SFOS.

När en grupp skapas eller ändras via XML API heter entiteten SSLBookmarkGroup. API-dokumentationen för SFOS 23.0 tillåter UTF-8-tecken i dess Name, förbjuder kommatecken och behåller gränsen på 50 tecken. Dokumentationen för SFOS 22.0 anger redan denna gräns men inte de två ytterligare teckenreglerna; det visar inte hur äldre builds tillämpar dem. Ett giltigt exempelnamn är Clientless-München, som i <Name>Clientless-München</Name>; anpassa namnet till den egna miljön. Kontrollera efter API-anropet statuskoden och meddelandet i XML-svaret och läs tillbaka den sparade gruppen: namnet och dess bookmarks måste motsvara den avsedda tilldelningen. Denna anmärkning gäller gruppnamnet i API:et och är ingen generell regel för enskilda bookmarknamn; följ fältkraven för den installerade builden i gränssnittet som beskrivs ovan.

Enskilda bookmarks via XML API: Add/Edit-exemplet för SSLBookmark i SFOS 22.0 och 23.0 är en referens med typberoende grenar, inte en gemensam payload som kan köras för alla protokoll. Värdena HTTP och HTTPS i exemplet bevisar varken aktuellt stöd i användargränssnittet eller stöd i den installerade builden. I exemplet kräver NLA att AutoLogin är aktiverat; för SSH/SFTP beskriver kommentaren lösenord eller Private Key som alternativ när AutoLogin är aktiverat. Detta innebär inte att de ovan beskrivna begränsningarna för SSH Host Key och SFTP-format upphävs eller att interaktiv SFTP-inloggning är möjlig.

Parametertabellen markerar dock Private Key, Public Host Key och UserName som obligatoriska fält utan att ange för vilka typer detta gäller. Den begränsar URL till tecken som används i värdnamn, medan den andra raden med Domains, för en lista över vidarehänvisade domäner/URL:er, kräver att värdena börjar med HTTP:// eller HTTPS://. I exemplet ligger denna lista under den ordagranna tokenen RefferredDomains; den är inte Windows-domänen Domain för RDP/SMB, även om tabellen också innehåller en RDP-rad med namnet Domains. Byt inte namn på token genom gissningar och kombinera inte tabellens motstridiga regler till en universell payload. Klargör före en automatiserad ändring vilka fält, villkor och representationer som accepteras för typen och den installerade builden med hjälp av motsvarande officiella dokumentation eller med Sophos Support; utför inte den obekräftade ändringen innan detta är klarlagt. Spara först den faktiska bookmarken och dess tilldelningar som utgångsläge, kontrollera därefter XML-status och meddelande och läs tillbaka den sparade bookmarken, gruppmedlemskapet och publiceringen. Vid avvikelser ska endast den egna ändringen återställas till exakt detta utgångsläge och åtkomsttesterna upprepas; ta inte med lösenord eller Private Keys i granskningsutdata eller oskyddade payload-filer.

Felsöka vanliga problem

VPN Portal kan inte nås: Kontrollera den offentliga DNS-posten, porten, framförliggande NAT, Administration > Device access och en möjlig Port Sharing-effekt.
Portalens inloggning misslyckas: Kontrollera VPN Portal-autentisering under Authentication > Services samt användarstatus, MFA och access_server.log.
Clientless access connections saknas: Användaren har inte tilldelats någon Clientless Policy eller så publicerar policyn ingen bookmark.
Bookmarken visas för fel användare: Kontrollera Policy members, gruppmedlemskap och Published bookmarks. Vid flera matchande grupper kan Clientless SSL VPN kombinera behörigheterna från de tillhörande policies. Vilka bookmarks en verklig användare därmed ser ska ingå i det positiva och negativa testet.
Bookmarken öppnas men målet kan inte nås: Kontrollera DNS-upplösningen ur brandväggens perspektiv, den statiska måladressen, routing, målporten, tjänstens status och värdbrandväggen.
Inloggningen på VPN Portal fungerar men inte Windows-inloggningen: Portal- och målinloggning är separata. Kontrollera domän, målkonto, lösenord samt TLS eller NLA.
NLA aktiverar Automatic login: Detta är det dokumenterade beteendet. Inaktivera inte NLA oplanerat, utan ompröva konto- och åtkomstmodellen.
SSH visar en annan Host Key: Stoppa anslutningen och kontrollera ändringen direkt på målsystemet eller med den ansvariga operatören. En oväntad nyckel kan tyda på en ominstallation, ett felaktigt mål eller en attack.

Under Diagnostics > Tools > Troubleshooting logs hjälper olika filer i olika faser:

vpnportal.log för VPN Portal;
access_server.log för autentisering och auktorisering;
clientless_access.log för Clientless-anslutningar och anslutningen till målet;
oauth_sso_vpn.log i SFOS 22 för inloggningar på VPN Portal med SSO; i SFOS 23, oauth_sso_svc.log för VPN Portal OIDC/Entra SSO. Kontrollera även modulen Authentication i Log viewer för dessa VPN Portal-inloggningar.

Testtidpunkt, användare, bookmark och mål bör dokumenteras tillsammans. Då kan portal-, identitets- och målproblem skiljas åt i loggarna. Den allmänna loggtilldelningen och åtkomst via Advanced Shell finns i Sophos Firewall-tjänsteloggar.

Drift och kända RDP-begränsningar

Dokumentera före en produktionsändring policytilldelningen, Device Access-matrisen, ACL-undantag, portalport och certifikatval. Om det positiva testet misslyckas eller den obehöriga användaren ser en bookmark tar du bort den nya tilldelningen eller publiceringen, återställer värdena till föregående tillstånd, loggar in igen och upprepar det negativa testet. Återställ endast målkonton eller Host Keys om de faktiskt ändrades.

Clientless Policies bör granskas regelbundet på samma sätt som andra Remote Access-behörigheter. Användare, bookmarks och målkonton som inte längre behövs tas bort. Lagrade lösenord eller Private Keys ska ha en owner, ett utgångsdatum och en rotationsprocess. Automatic login och Share session ska ingå i varje behörighetsgranskning.

Att dra tillbaka publiceringen är inte att radera: Klargör före borttagningen om det gäller en enskild bookmark eller en Bookmark Group och dokumentera det exakta namnet, aktuellt gruppmedlemskap och publiceringen i alla berörda policies. Dra först endast tillbaka den publicering eller tilldelning som inte längre önskas; detta raderar inte objektet. Radera det exakta objektet först när det faktiskt är oanvänt och dess beroenden har klarlagts. Stoppa vid befintliga relationer och radera inte grupper eller policies i produktion genom kaskadradering enbart för att tvinga fram borttagningen.

Delete-referenserna för SFOS 22.0 och 23.0 kräver båda Name med högst 50 tecken och listar XML-statusvärdena 200, 500 och 504. För 504 hänvisar de till BookMarkDeleteRelationExists för bookmarks och till BookMarkGroupDeleteRelationExists för grupper: dessa är meddelandeidentifierare i dokumentationen som inte har omvandlats till meddelandetext, inte bekräftade meddelandetexter vid körning och inte en HTTP-status. Referenserna innehåller varken en exempelpayload för Delete eller något löfte om kaskadradering; härled därför ingen raderingssyntax från dem. Läs efter ändringen faktiskt tillbaka återstående bookmarks, grupper och avsedda publiceringar och upprepa både positiva och negativa tester. Vid oväntad åtkomst ska de egna tilldelningsändringarna återställas till det dokumenterade utgångsläget; undvik därför onödiga objektraderingar när avsikten endast är att dra tillbaka en publicering.

Öppna Current activities > Remote users i administratörskonsolen för att se inloggade fjärranvändare i realtid. Anslutningar kan filtreras efter anslutningsdatum, användarnamn, käll-IP-adress och tilldelad IP-adress (leased IP). Administratören kan klicka på Disconnect för att koppla från den valda fjärranvändaren. Kontrollera först användaren och anslutningen eftersom åtgärden avbryter åtkomsten. Den ersätter inte att ta bort användaren från Clientless Policy eller att logga ut korrekt på målsystemet och garanterar inte att alla efterföljande sessioner på målsystemen avslutas.

Dokumentationen för kolumnen Mode skiljer mellan följande fall:

SSL VPN (remote access): användaren är ansluten via SSL VPN för fjärråtkomst.
User portal (clientless access): enligt denna indelning är användaren inloggad på User Portal och medlem i en Clientless SSL VPN Policy.
User portal: enligt denna indelning är användaren inloggad på User Portal men inte medlem i en Clientless SSL VPN Policy.

Dessa etiketter kommer från Remote users-instruktionerna för SFOS 22 och 23. Clientless-instruktionerna anger däremot VPN portal som åtkomstväg. Terminologin är alltså inkonsekvent; listan bekräftar varken de aktuella Mode-etiketterna för den installerade builden eller en förändring från SFOS 22 till 23. För konfigurationen gäller fortfarande VPN Portal-förfarandet ovan. Kontrollera portalinloggning, policymedlemskap och faktiskt synliga bookmarks separat i stället för att härleda behörighet enbart från en Mode-etikett.

Använd före ett firmwarebyte Avanets runbook för firmwarebeslut för att identifiera ändringar som påverkar installerad build och målversion. Ta med Clientless Access, VPN portal, RDP och den autentiseringsmetod som används i granskningen. Upprepa det fullständiga positiva och negativa testet efter uppgraderingen.

RDP har två aktuella begränsningar som inte bör behandlas som konfigurationsfel:

Urklipp stöds inte i Clientless RDP-bookmarks sedan SFOS 19. Copy-and-paste mellan den lokala enheten och RDP-sessionen är därför inte en tillförlitlig arbetsmetod.
Muspekaren kan visas som ett kryss eller X i HTML5-RDP-sessionen i stället för som en normal pil. Sophos anger för närvarande ingen lösning.

Om urklipp, inbyggda RDP-funktioner, bredare nätverksåtkomst eller personliga målkonton på en server som kräver NLA utan lagrade Credentials är obligatoriska är Clientless SSL VPN inte rätt genväg. Då bör åtkomsten avsiktligt flyttas till Sophos Connect, RD Gateway, PAM, en Jump Host eller ZTNA.