Hvorfor viser Little Snitch stadig browseren under en VPN?

Du tænder for VPN, åbner Little Snitch, og browseren står der straks med en forbindelse til et websted, du troede gik gennem tunnelen. Den post er ikke i sig selv bevis på en lækage. En lokal monitor rapporterer, hvilken proces der åbnede en sokkel på denne maskine, og browseren åbnede den; VPN-klienten er en anden proces, der samler de pakker op bagefter. Begge udsagn er sande samtidig, og visningen viser dig det første.

Hvad en lokal monitor kan og ikke kan tilskrive

Tilskrivningen sker ved soklen. Kernen ved, hvilken proces der ejer en forbindelse, så Little Snitch kan mærke en post med applikationsnavnet med høj sikkerhed. Det, den som standard ikke ser, er den ydre forbindelse, VPN'en bygger omkring den trafik, fordi den tilhører en anden proces.

Domænenavne er et svagere signal, end de ser ud. Ved en HTTPS-forbindelse kan navnet komme fra et DNS-opslag, fra det servernavn, der tilbydes under håndtrykket, eller fra et omvendt opslag af adressen, afhængigt af hvad systemet har observeret. Intet af det kræver dekryptering af siden, og intet af det beviser, hvor byte'erne derefter gik hen.

Browserposten svarer altså på hvem, ikke hvor. Behandl den som tilskrivningsdata, og hent hvor i en anden visning.

Trin et: begynd med et tomt vindue i stedet for at rulle gennem historikken

Gamle poster kan ikke fortælle dig, hvad den aktuelle konfiguration gør. Skift tidsfilteret til Fra nu, eller tryk Command-K, så vinduet kun viser forbindelser, der dukker op efter det øjeblik.

Gør derefter præcis én uskyldig ting i det program, du undersøger, for eksempel indlæs en side, du har lov til at indlæse. Én handling, ét øjeblik, så de poster, der dukker op, kan knyttes til den uden gætværk. Vent et sekund eller to, når den er færdig, fordi en sideindlæsning giver en byge af forbindelser frem for én enkelt. At læse listen, mens den stadig fyldes, garanterer, at du vurderer rækkefølgen forkert.

Før du læser resultatet, skal du kontrollere, om et søgefelt eller et statusfilter indsnævrer listen. Et filter tilbage fra en tidligere session er den mest almindelige grund til, at en forbindelse ser ud til at mangle, når den blot er skjult, og det er også grunden til, at to personer, der kigger på samme maskine, er uenige om, hvad der sker.

Trin to: medtag udvidelsesforbindelser for at se selve tunnelen

VPN-klienten på en aktuel macOS-version er normalt en netværksudvidelse frem for en almindelig app. Slå Vis netværksudvidelser til i Monitoren, og de forbindelser, udvidelsen opretter, bliver synlige sammen med alt andet.

Nu kan de to lag læses sammen. Browseren er kilden til anmodningen, og udvidelsen er den transport, der bærer den. At se begge er normalt og forventet; at se kun udvidelsen betyder normalt, at visningen er filtreret, mens at se kun programmet normalt betyder, at udvidelsesvisningen er slået fra.

Ingen visning alene kortlægger hele vejen. Routingregler, DNS-adfærd og eventuelle undtagelser pr. app ligger uden for forbindelseslisten, så et fuldstændigt svar kræver, at de kontrolleres særskilt.

Trin tre: skelne en ægte direkte forbindelse fra en visningseffekt

Hvis du har mistanke om, at en bestemt destination går direkte ud, navngiv den destination og undersøg den for sig selv. Se på VPN-klientens egen routing- og blokeringskonfiguration for den vært eller app, og bekræft, om den skal være udelukket.

Det, du ikke bør gøre, er at blokere enhver synlig browserpost som reaktion. Browseren skal stadig oprette sine forbindelser, og at blokere dem i monitoren omdirigerer dem ikke ind i tunnelen; det stopper dem bare. Det gør et diagnostisk spørgsmål til et afbrud. Hvis en regel virker nødvendig, så begræns den til den ene destination, du kan begrunde, med en note om, hvorfor den findes.

Samme forsigtighed gælder for domænekolonnen. Et navn, der overrasker dig, kan være et delt værtsnavn, et indholdsserveringsendepunkt eller et opslag, der skete, før tunnelen kom op, og at behandle det som bevis på en lækage fører til regler, der ødelægger fungerende trafik.

Trin fire: hold visningen og reglen adskilt

Enhver ændring i denne øvelse ændrer, hvad monitoren viser. Ingen af dem ændrer, hvad firewallen tillader, og ingen af dem flytter trafik ind i eller ud af tunnelen.

Når du er færdig, sæt filtrene tilbage til en tilstand, du kan forklare, så den næste person, der åbner vinduet, ikke læser en visning, du efterlod. Hvis spørgsmålet var, om en destination går gennem tunnelen, så besvar det ud fra routing- og udeladelsesindstillingerne, og brug derefter monitoren til at bekræfte resultatet i stedet for at gætte på det.