Hvorfor en brannmurport bundet til VPN-tilstand ikke er en regel om ping bare gjennom tunnelen

Se for deg en brannmurregel som slår på ICMP echo for serverens offentlige adresse hver gang en navngitt VPN-profil er tilkoblet. Det leses som «ping bare gjennom tunnelen», og den lesningen er feil på en måte som betyr noe. Regelen begrenser ikke hvem som kan nå verten; den endrer hva det offentlige grensesnittet svarer på mens en annen tilkobling tilfeldigvis er oppe. Det er to forskjellige policyer, og én av dem utvider eksponeringen i det stille.

Regelen du tror du skrev

Det tiltenkte kravet er vanligvis smalt: overvåkingssystemet, eller den ene administratoren på VPN-en, skal kunne bekrefte at serveren lever. Skrevet som en setning lyder det som tilgangskontroll på tunnelen. Skrevet som et brannmurobjekt blir det til en betingelse på den offentlige profilen, fordi det er der echo-forespørselen kommer inn.

Når betingelsen er en tilkoblingstilstand i stedet for en kildeadresse, er settet med tillatte avsendere ikke lenger VPN-peer-settet. Alle som kan nå den offentlige adressen, kan sende en echo-forespørsel mens porten er åpen. Tunnelen ble ikke veien; tunnelen ble bryteren.

Folkene bak ideen lyver vanligvis ikke om effekten de ønsket. De trengte en sjekk som bare svarer når lenken er sunn, og lenkens helse var lettest å observere gjennom VPN-en. Feilen er å behandle et tilgjengelighetssignal som en tilgangsbeslutning og deretter automatisere det.

Hva porten faktisk styrer

Dette designet smelter sammen to uavhengige ting, og å skille dem er det meste av rettelsen. Det første er omfang: hvilken lokal adresse, hvilke fjerne adresser, hvilken protokoll og hvilken ICMP-type. Det andre er betingelse: om regelobjektet er aktivert i dette øyeblikket. Omfang er det en brannmur vurderer per pakke; betingelse er det et skript skriver i policylageret, og de to avstemmes på helt forskjellige klokker.

Hvis kravet virkelig bare er VPN-peers, svarer omfanget på det uten noen logikk for tilkoblingstilstand: bind regelen til tunnelgrensesnittet eller til tunnelens adresseområde, begrens de fjerne adressene til klientbassenget, og angi echo-typen i stedet for «ICMP». Den regelen forblir korrekt når ingen VPN er oppe, og kan ikke åpnes av en uvedkommende profil.

Hvis kravet virkelig er en offentlig port, si det i policyteksten, fordi akseptkriteriene endres. En offentlig port må navngi den nøyaktige profilen, definere hva «tilkoblet» betyr, og erklære at offentlige avsendere er i omfanget etter design. Det meste av forvirringen forsvinner i det øyeblikket noen tvinges til å skrive ned den setningen.

Bygg objektet én gang, og skift det deretter

Klargjør én regel med en stabil identitet, deaktivert, og la kontrolleren endre bare dens aktiverte tilstand. Å opprette regler etter visningsnavn ved hver kjøring er hvordan et policylager ender opp med fem nesten identiske objekter og ingen pålitelig måte å fjerne dem på.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

Navnet er den varige identifikatoren; visningsnavnet er dokumentasjon som et menneske kan redigere. Avstem mot -Name, og skriptet slutter å produsere duplikater. Samme kommandoform dekker IPv6-tilfellet med -Protocol ICMPv6 -IcmpType 128, men det er en egen regel fordi echo-typens numre er forskjellige i de to familiene.

Hold adressefamilie og ICMP-type eksplisitte av en annen grunn: -Protocol ICMPv4 uten type tillater hver ICMPv4-melding som profilen tillater, inkludert dem du aldri mente å godta. Å navngi type 8 snevrer regelen inn til echo-forespørsel, som er det eneste en tilgjengelighetssjekk sender.

Der automatiseringen motsier hensikten

Avstemming av en klientprofil hvert par minutter kan ikke gi en umiddelbar grense. Mellom tilkoblingen som faller og neste avstemming svarer regelen fortsatt på den offentlige adressen; mellom tilkoblingen som kommer opp og neste avstemming gjør den det ikke. Å innrømme den forsinkelsen er ærlig, og å hevde at designet håndhever en streng invariant er det ikke.

Det er en omfangsfelle i selve tilstandssjekken. Get-VpnConnection rapporterer klientprofiler som er konfigurert på maskinen, som standard for gjeldende bruker og for alle brukere med -AllUserConnection. Den rapporterer ikke fjernbrukerne som for øyeblikket er innringt til en RRAS-server; det er en annen observasjon med en annen kommando. En port bygget på den gale er ikke koblet til noe.

Deretter dekker du tilstandene ingen skriptet: oppstart med regelen allerede aktivert fra en tidligere kjøring, kontrollerkrasj mens porten er åpen, og en profil slettet mens regelen fortsatt lever. Hver trenger en definert standard, og den trygge standarden for en offentlig tillatelse er deaktivert. Hvis kravet virkelig ikke tåler avstemningsvinduet, er en tilstandsstyrt regel feil verktøy, og håndhevelsen hører til tunnelen, ikke til det offentlige grensesnittet.

Til slutt, test den offentlige forespørselen to ganger, én gang med den valgte tilkoblingen oppe og én gang med den nede, fra en vert som ikke er på VPN-en. En vellykket ping innenfra tunnelen beviser ingenting om denne policyen, og det er målingen de fleste utrullinger hopper over.