Blokker én OpenVPN-klient fra LAN uten å stoppe tunnelen
Fest klientens tunneladresse til sertifikatet, dropp LAN-trafikken i toppen av FORWARD, og verifiser deretter IPv6, sporede sesjoner og overlevelse etter omstart.
Én klient på OpenVPN-serveren din må miste LAN-tilgang mens alle andre tunneler holder seg oppe. Søker du etter dette, sier det beste svaret vanligvis at daemonen ikke kan, noe som bare er halvt sant: OpenVPN har ingen brannmur per klient, men verten som avslutter tunnelen filtrerer allerede pakker. De to beslutningene som betyr noe, er identiteten du blokkerer, og regelens plassering. Får du disse riktig, blir endringen én linje du kan teste og fjerne.
Fest klienten før du skriver regelen
OpenVPN leier ut tunneladresser fra en pool, så 10.8.0.6 er et sete, ikke en person. Når sesjonen avsluttes, går leien tilbake og kan gis til neste tilkobling, noe som betyr at en regel skrevet mot den adressen følger setet, ikke brukeren. Bestem derfor først hva du faktisk blokkerer: en adresse for et kort eksperiment, eller et sertifikat for noen du vil holde ute.
For å binde adressen til sertifikatet, opprett en fil i katalogen som client-config-dir peker på, og gi filen nøyaktig sertifikatets common name. Legg inn én direktiv, ifconfig-push 10.8.0.6 255.255.255.0, og den klienten beholder samme tunneladresse ved gjentilkoblinger. To innstillinger må finnes for at dette skal virke: client-config-dir må være deklarert i serverkonfigurasjonen, og adressen som sendes må ligge i et subnett serveren kan rute. Mangler én, ignoreres filen uten feil, noe som gjør neste brannmurtest misvisende.
En midlertidig blokkering kan bruke en pooladresse, så lenge billetten registrerer hvilken sesjon som hadde den da.
Rekkefølgen avgjør om droppet kjører
På en Linux-gateway som videresender mellom tunnelen og LAN, passerer pakker kjeden FORWARD. Les kommandoen nedenfor som en setning: sett inn i toppen av FORWARD, match trafikk som kommer inn fra tun0, fra den ene verten, adressert til LAN-subnettet, og dropp den.
iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROPDet er -I som får regelen til å kjøre. Lagt til med -A, lander den under enhver bred aksept for tunnelsubnettet og ser aldri en pakke. Verifiser plasseringen med iptables -vnL FORWARD --line-numbers, og les også tellerne: et dropp i toppen som ikke teller noe, betyr at trafikken kommer inn en annen vei.
Gatewayens egen LAN-adresse er en annen vei. Pakker sendt til selve boksen går til INPUT, ikke FORWARD, så en klient kan miste en LAN-vert og likevel åpne admin-siden til ruteren. Legg til den matchende INPUT-regelen når det betyr noe.
Hva filteret ikke kan se
Filtrering skjer når en pakke vurderes, så en etablert TCP-sesjon kan fortsette til den lukkes eller tilbakestilles. Må blokkeringen bite umiddelbart, tøm de sporede strømmene for den kilden med conntrack -D -s 10.8.0.6 etter at regelen er satt inn. Er noen sekunders overlapp akseptabelt, registrer det valget i stedet for å la det være implisitt. Uansett må neste person vite om regelen stopper levende trafikk eller bare nye tilkoblinger.
Peer-trafikk berører aldri vertens brannmur. Med client-to-client aktivert videresender OpenVPN disse pakkene inne i daemonen, så verken FORWARD eller INPUT ser dem. De eneste løsningene er å slå av client-to-client eller akseptere at peers kan nå hverandre; en iptables-regel vil ikke se den trafikken.
IPv6, firmware og overlevelse etter omstart
En IPv4-regel sier ingenting om IPv6. Hvis tunnelen og LAN-et bærer begge familiene, må den tilsvarende regelen finnes i ip6tables, eller i nftables-regelsettet som eier policyen på den verten. Ruter-firmware skjuler ofte netfilter bak sin egen abstraksjon, så syntaks og tabellnavn kopiert fra et forum gjelder kanskje ikke.
På OpenWrt er den dokumenterte veien en brannmurkonfigurasjonspost og ikke en håndskrevet iptables-linje, og en håndskrevet linje kan forsvinne når brannmuren lastes på nytt. Andre distribusjoner gjenoppretter regler via netfilter-persistent, en oppstartsenhet eller et leverandørlager, og disse mekanismene kan ikke byttes om. Bevis den du valgte med en omstart, fordi en omlasting trener en annen vei.
Verifiser per vei, og rull deretter rent tilbake
Test hver vei separat, fordi én vellykket sjekk skjuler de andre. En blokkert klient skal fortsatt nå internett gjennom tunnelen, men feile mot en LAN-vert, en andre klient skal nå samme vert, og gateway-adressen og peer-veien trenger hver sin observasjon. Skriv resultatene ved siden av regelen, slik at neste endring har en baseline. Tabellen nedenfor er settet som er verdt å beholde i billetten.
| Vei | Forventet med regelen | Når den feiler |
|---|---|---|
| Blokkert klient til en LAN-vert | Ingen svar | Regelen ligger under en aksept, eller kilden matcher ikke |
| Blokkert klient til internett | Virker gjennom tun0 | Regelen er for bred, uten destinasjonsmatch |
| Andre klient til samme LAN-vert | Virker | Regelen matchet mer enn den tiltenkte verten |
| Blokkert klient til gatewayens LAN-adresse | Blokkert bare med den matchende INPUT-regelen | INPUT-regel mangler |
| Blokkert klient til en peer-tunneladresse | Virker fortsatt | client-to-client er aktivert og utenfor brannmurens rekkevidde |
Tilbakerulling er en sletting etter spesifikasjon, ikke en flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP fjerner nøyaktig den posten og lar resten av kjeden være intakt. Fjern samme linje fra filen som gjenoppretter reglene ved oppstart, last den på nytt, og bekreft at klienten igjen når LAN-verten. En flush av FORWARD ville også oppheve regler du ikke skrev, noe som gjør en tilbakerulling til en ny hendelse.
Før du lukker billetten, bekreft tre ting: den fastlåste adressen matcher sertifikatet, regelen ligger over akseptene med en teller som ikke er null, og persistensfilen inneholder samme regel som du testet. Mangler noe av dette, er blokkeringen en illusjon i en shell-sesjon.