Bloker én OpenVPN-klient fra LAN uden at stoppe tunnelen
Fastgør klientens tunneladresse til dens certifikat, drop dens LAN-trafik i toppen af FORWARD, og verificér derefter IPv6, sporede sessioner og overlevelse efter genstart.
Én klient på din OpenVPN-server skal miste LAN-adgang, mens alle andre tunneler forbliver oppe. Søger man efter det, siger det bedste svar normalt, at daemonen ikke kan gøre det, hvilket kun er halvt sandt: OpenVPN har ingen firewall pr. klient, men værten, der afslutter tunnelen, filtrerer allerede pakker. De to beslutninger, der betyder noget, er den identitet, du blokerer, og reglens placering. Får du dem rigtigt, bliver ændringen én linje, du kan teste og fjerne.
Fastgør klienten, før du skriver reglen
OpenVPN udlejer tunneladresser fra en pulje, så 10.8.0.6 er en plads, ikke en person. Når sessionen slutter, returneres lejen og kan gives til næste forbindelse, hvilket betyder, at en regel skrevet mod den adresse følger pladsen, ikke brugeren. Så beslut først, hvad du egentlig blokerer: en adresse til et kort eksperiment eller et certifikat til en, du vil holde ude.
For at binde adressen til certifikatet skal du oprette en fil i den mappe, der angives af client-config-dir, og give filen præcis certifikatets common name. Læg én direktiv i den, ifconfig-push 10.8.0.6 255.255.255.0, og den klient beholder samme tunneladresse ved genforbindelser. To indstillinger skal findes, for at dette virker: client-config-dir skal være erklæret i serverkonfigurationen, og den pushede adresse skal ligge i et subnet, som serveren kan route. Mangler én, ignoreres filen uden fejl, hvilket gør den næste firewall-test misvisende.
En midlertidig blokering kan bruge en puljeadresse, så længe billetten registrerer, hvilken session der havde den på det tidspunkt.
Rækkefølgen afgør, om droppet kører
På en Linux-gateway, der videresender mellem tunnelen og LAN, passerer pakker kæden FORWARD. Læs kommandoen nedenfor som en sætning: indsæt i toppen af FORWARD, match trafik, der kommer ind fra tun0, fra den ene vært, adresseret til LAN-subnettet, og drop den.
iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROPDet er -I, der får reglen til at køre. Tilføjet med -A lander den under enhver bred accept for tunnel-subnettet og ser aldrig en pakke. Verificér placeringen med iptables -vnL FORWARD --line-numbers, og læs også tællerne: et drop i toppen, der ikke tæller noget, betyder, at trafikken ankommer ad en anden vej.
Gatewayens egen LAN-adresse er en anden vej. Pakker sendt til selve boksen går til INPUT, ikke FORWARD, så en klient kan miste en LAN-vært og stadig åbne routerens admin-side. Tilføj den matchende INPUT-regel, når det betyder noget.
Hvad filteret ikke kan se
Filtrering sker, når en pakke evalueres, så en etableret TCP-session kan fortsætte, indtil den lukkes eller nulstilles. Skal blokeringen bide med det samme, ryd de sporede flows for den kilde med conntrack -D -s 10.8.0.6, efter at reglen er sat ind. Er et par sekunders overlap acceptabelt, så registrér det valg i stedet for at lade det være implicit. Under alle omstændigheder skal den næste person vide, om reglen stopper livlig trafik eller kun nye forbindelser.
Peer-trafik rører aldrig værtens firewall. Med client-to-client aktiveret videresender OpenVPN disse pakker inde i daemonen, så hverken FORWARD eller INPUT ser dem. De eneste løsninger er at slå client-to-client fra eller acceptere, at peers kan nå hinanden; en iptables-regel vil ikke se den trafik.
IPv6, firmware og overlevelse efter genstart
En IPv4-regel siger intet om IPv6. Hvis tunnelen og LAN'et bærer begge familier, skal den tilsvarende regel findes i ip6tables eller i det nftables-regelsæt, der ejer politikken på den vært. Router-firmware skjuler ofte netfilter bag sin egen abstraktion, så syntaks og tabelnavne kopieret fra et forum gælder måske ikke.
På OpenWrt er den dokumenterede vej en firewall-konfigurationspost og ikke en håndskrevet iptables-linje, og en håndskrevet linje kan forsvinde, når firewallen genindlæses. Andre distributioner gendanner regler via netfilter-persistent, en boot-enhed eller et leverandørlager, og disse mekanismer kan ikke udskiftes. Bevis den, du valgte, med en genstart, fordi en genindlæsning bruger en anden vej.
Verificér pr. vej, og rul derefter rent tilbage
Test hver vej separat, fordi én vellykket kontrol skjuler de andre. En blokeret klient skal stadig nå internettet gennem tunnelen, mens den fejler mod en LAN-vært, en anden klient skal nå samme vært, og gateway-adressen og peer-vejen kræver hver deres observation. Skriv resultaterne ved siden af reglen, så den næste ændring har en baseline. Tabellen nedenfor er det sæt, der er værd at beholde i billetten.
| Vej | Forventet med reglen | Når den fejler |
|---|---|---|
| Blokeret klient til en LAN-vært | Intet svar | Reglen ligger under en accept, eller kilden matcher ikke |
| Blokeret klient til internettet | Virker gennem tun0 | Reglen er for bred, uden destinationsmatch |
| Anden klient til samme LAN-vært | Virker | Reglen matchede mere end den tilsigtede vært |
| Blokeret klient til gatewayens LAN-adresse | Blokeret kun med den matchende INPUT-regel | INPUT-regel mangler |
| Blokeret klient til en peer-tunneladresse | Virker stadig | client-to-client er aktiveret og uden for firewallens rækkevidde |
Tilbagerulning er en sletning efter specifikation, ikke en flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP fjerner præcis den post og lader resten af kæden være intakt. Fjern samme linje fra den fil, der gendanner reglerne ved boot, genindlæs den, og bekræft, at klienten igen når LAN-værten. En flush af FORWARD ville også fortryde regler, du ikke skrev, hvilket gør en tilbagerulning til en ny hændelse.
Før du lukker billetten, bekræft tre ting: den fastgjorte adresse matcher certifikatet, reglen ligger over acceptterne med en tæller, der ikke er nul, og persistensfilen indeholder samme regel, som du testede. Mangler noget af det, er blokeringen en illusion i en shell-session.