IPv6-integritetsadresser eller en RDP-tillåtelselista: välj avvägningen

Fjärrskrivbordsåtkomst fungerade i en månad, och sedan slutade tillåtelselistan att matcha utan någon synlig anledning. Värden hade inte flyttats och ingenting i brandväggen hade redigerats. Windows fortsätter att bilda tillfälliga IPv6-adresser med slumpmässiga gränssnittsidentifierare och dra tillbaka dem, så källadressen som servern ser en given dag kan vara en som ingen har skrivit in i regeln. Att stänga av det beteendet rättar matchningen och gör samtidigt värden till en långlivad identifierare. Väg alternativen innan du accepterar den andra halvan.

Varför regeln slutade matcha

RFC 4941 beskriver tillfälliga adresser: värden skapar ytterligare adresser med slumpmässiga identifierare och drar tillbaka dem, vilket hindrar en observatör från att korrelera en värd mellan besök. Windows implementerar det beteendet, så gårdagens källadress är inte nödvändigtvis dagens. Den förutsägbara adressen finns fortfarande på gränssnittet; den är bara inte den som en utgående anslutning föredrar.

Därför ser felet intermittent ut i stället för totalt. Regeln matchar ett tag efter att adressen skapats, slutar matcha när den dras tillbaka och börjar matcha igen efter att någon har redigerat den. Övervakning grupperad efter källadress och licenskontroller knutna till en värdadress bryts enligt samma schema. En regel som fungerar direkt efter redigering och misslyckas tre veckor senare är vanligtvis detta och inte en omladdning av brandväggen.

Alternativ ett: en stabil adress, mindre integritet

Den vanliga reparationen stänger av båda rotationsmekanismerna på värden: netsh interface ipv6 set privacy state=disabled store=persistent och netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Lägg till store=active om du vill att ändringen ska gälla utan att vänta på en omstart, och acceptera att du nu har gjort identifieraren förutsägbar mellan nätverk.

Just den förutsägbarheten var det som utökningarna byggdes för att förhindra. En adress som följer värden från kafé till kontor och hem är en bekväm filternyckel och en lika bekväm spårningsnyckel, och den andra egenskapen överlever biljetten som bad om den första.

Alternativ två: tillåt ett prefix eller ett namn

Att tillåta /64 i stället för den fullständiga adressen håller rotationen intakt och passar med ett svagare men ofta ärligt påstående: den här maskinen finns på mitt hemnätverk. Det slutar vara tillräckligt i samma stund som prefixet innehåller värdar du inte skulle släppa in, vilket på en konsumentanslutning vanligtvis är en mindre mängd än folk antar. Ett namn som publiceras via dynamisk DNS är enklare att driva, eftersom posten följer värden och policyn läses som en identitet i stället för som ett intervall som växer varje gång en enhet läggs till.

Båda alternativen behöver en resolver som servern kan lita på och ett namn som inte är trivialt förfalskningsbart, så behandla dem som ett principbeslut om identitet och inte som en kosmetisk ändring av regeln. Skriv ned vilken resolver som svarar på det namnet, för regeln är bara så pålitlig som posten bakom den.

Alternativ tre: låt tunneln tilldela adressen

Om anslutningen går genom en VPN som du kontrollerar kan servern dela ut adressen från sin egen pool, och tillåtelselistan refererar då till ett värde som servern väljer i stället för ett som klienten föredrar. Det fungerar bra för hanterade klienter och dåligt för allt klienten kan åsidosätta, så kontrollera vilken sida som faktiskt vinner i din driftsättning.

Att flytta beslutet helt bort från adressen, till ett klientcertifikat eller en autentiserad gateway, är alternativet som skalar, eftersom det slutar bero på ett värde som operativsystemet har rätt att ändra.

Välj med spårningskostnaden i åtanke

Skriv de fyra alternativen mot det faktiska kravet, och välj ett i stället för att kombinera dem. Om du ändå stänger av integriteten, begränsa det till värden som behöver det, dokumentera skälet bredvid regeln och överväg stabil-integritetsadressering från RFC 7217 där plattformen stöder det, eftersom den behåller en identifierare per prefix utan att avslöja den hårdvaruhärledda. Slå på utökningarna igen när tillåtelselistan ersätts.

Registrera ändringen bredvid regeln den stöder. Utan den anteckningen hittar nästa administratör en värd med integritetsutökningarna avstängda och ingen förklaring, och slår på dem igen under en städning.