En bärbar dator som måste nå en administrationsserver från inloggningsskärmen och en bärbar dator som måste nå filresurser efter att användaren autentiserats är två olika problem. Windows löser dem med två olika tunnlar, och skillnaden är inte vilken som visas i profillistan. Enhetstunneln körs som maskinen, innan någon loggar in. Användartunneln körs som personen, efter att plattformen har en identitet att arbeta med. Valet mellan dem börjar med ögonblicket då trafiken måste flöda, inte med resurserna den måste nå.

Två identiteter, två ögonblick

Enhetstunneln upprättas i maskinkontext, och därför kan den bära den trafik som behövs för att autentisera en användare eller för att administrationsagenter ska rapportera före inloggning. Användartunneln upprättas i användarkontext, efter inloggning, med användarens autentiseringsuppgifter och den princip som gäller för det kontot.

Den tidsskillnaden är hela designen. Allt annat följer av den, inklusive vilka autentiseringsmetoder som är tillgängliga och vilka resurser som är meningsfulla.

Om kravet är en affärsapplikation som används av en inloggad person svarar användartunneln på det. Om kravet är en domänkontrollant, en certifikatutfärdare eller en administrationstjänst som nås från inloggningsskärmen är bara enhetstunneln tillräckligt tidig.

Telefonboken är inte skillnaden

Att spara en inhemsk profil i telefonboken för alla användare skapar inte en enhetstunnel. Profilen blir tillgänglig för varje användare på maskinen, vilket är en fråga om lagringsomfattning, och den ansluter fortfarande i användarkontext.

En riktig enhetstunnel konfigureras som just det, med de plattforms-, protokoll- och certifikatkrav som Microsoft dokumenterar för den. Kraven omfattar en utgåva som stöder den, en domänansluten enhet, IKEv2 och autentisering med maskincertifikat. En profil som heter device, kopierad från en användartunnel och omdöpt, uppfyller inget av detta.

Microsofts dokumentation om enhetstunneln är referensen för profilens form, och den är värd att läsa innan du antar att en fungerande användarprofil kan återanvändas.

Håll varje väg smal

Enhetstunneln bör bara nå det maskinen behöver före inloggning: katalogen, certifikatutfärdaren, administrationens slutpunkt och de DNS-poster som löser dem. Dess rutter och brandväggsregler bör spegla den korta listan och inte hela företagets område.

Användartunneln bär personens åtkomst och kan begränsas efter grupp, applikation eller destination som utrullningen kräver. Att blanda de två omfattningarna är hur en tunnel före inloggning får åtkomst till filresurser som inget maskinkonto någonsin borde ha.

Båda tunnlarna kan rullas ut tillsammans, och i de flesta Always On-designer är det fallet. Enhetstunneln kommer upp först och förblir smal. Användartunneln kommer upp vid inloggning och bär arbetstrafiken. Om du bara rullar ut en måste du bestämma vilket fel du kan leva med. En inloggningsskärm utan nätverk och en användartunnel som bär administrationstrafik är båda dåliga, men vanligtvis är bara en av dem acceptabel i din miljö.

Testa fasen, inte webbläsaren

En fungerande webbläsarförfrågan efter inloggning bevisar användartunneln och säger ingenting om enhetstunneln. Testa faserna separat: kallstart till inloggningsskärmen, själva inloggningen, användarens anslutning och återhämtning efter viloläge eller ett nätverksbyte.

På inloggningsskärmen är kontrollen om maskinen kan nå administrationens slutpunkt utan någon inloggad användare. Det är det enda ögonblicket då enhetstunneln finns för sig själv, och det är fasen folk hoppar över eftersom testet kräver omstart.

Efter inloggning, kontrollera användartunneln separat, inklusive fallet där enhetstunneln är uppe men användartunneln misslyckades. Två tunnlar med två tillstånd ger fyra kombinationer, och bara en av dem ser frisk ut.

När det misslyckas, namnge tunneln först

Förnyelse av maskincertifikat och återställning av användarkonto är olika uppgifter med olika ägare. En enhetstunnel som misslyckas efter att ett certifikat gått ut blir inte reparerad av att användarens autentiseringsuppgifter återställs, och en användartunnel som misslyckas efter ett lösenordsbyte blir inte reparerad av att maskincertifikatet utfärdas på nytt.

Anteckna vilken tunnel som var aktiv, vilken identitet den använde och vilken fas som misslyckades, och jämför det med de dokumenterade kraven för den utgåva och administrationsmiljö som används. Att kopiera en gammal generisk VPN-guide är hur utrullningar slutar med en enhetstunnel som bara fungerar för administratörer.

Arbetsordning: namnge ögonblicket då trafiken måste flöda, välj den tunnel som finns i det ögonblicket, smalna av dess rutter, testa varje fas i livscykeln separat och håll återställningsrutinerna för de två identiteterna åtskilda.

Relaterade artiklar