Blockera en OpenVPN-klient från LAN utan att stoppa tunneln
Fäst klientens tunneladress vid dess certifikat, släpp dess LAN-trafik i toppen av FORWARD och verifiera sedan IPv6, spårade sessioner och överlevnad efter omstart.
En klient på din OpenVPN-server måste tappa LAN-åtkomsten medan alla andra tunnlar fortsätter. Söker du efter detta säger det bästa svaret oftast att daemonen inte kan, vilket bara är halvt sant: OpenVPN har ingen brandvägg per klient, men värden som avslutar tunneln filtrerar redan paket. De två beslut som spelar roll är identiteten du blockerar och regelns placering. Få dem rätt och ändringen blir en rad du kan testa och ta bort.
Fäst klienten innan du skriver regeln
OpenVPN hyr ut tunneladresser från en pool, så 10.8.0.6 är en plats, inte en person. När sessionen slutar går hyran tillbaka och kan ges till nästa anslutning, vilket betyder att en regel skriven mot den adressen följer platsen, inte användaren. Bestäm därför först vad du faktiskt blockerar: en adress för ett kort experiment, eller ett certifikat för någon du vill hålla utanför.
För att binda adressen till certifikatet skapar du en fil i katalogen som client-config-dir anger och ger filen exakt certifikatets common name. Lägg in en direktiv, ifconfig-push 10.8.0.6 255.255.255.0, och den klienten behåller samma tunneladress vid återanslutningar. Två inställningar måste finnas för att detta ska gälla: client-config-dir måste vara deklarerad i serverkonfigurationen, och den pushade adressen måste ligga i ett subnät som servern kan routa. Saknas en av dem ignoreras filen utan fel, vilket gör nästa brandväggstest missvisande.
En tillfällig blockering kan använda en pooladress, så länge biljetten registrerar vilken session som hade den då.
Ordningen avgör om släppet körs
På en Linux-gateway som vidarebefordrar mellan tunneln och LAN passerar paket kedjan FORWARD. Läs kommandot nedan som en mening: infoga i toppen av FORWARD, matcha trafik som kommer in från tun0, från den enda värden, adresserad till LAN-subnätet, och släpp den.
iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROPDet är -I som får regeln att köra. Tillagd med -A landar den under varje bred acceptans för tunnelsubnätet och ser aldrig ett paket. Verifiera placeringen med iptables -vnL FORWARD --line-numbers och läs även räknarna: ett släpp i toppen som inte räknar något betyder att trafiken kommer in en annan väg.
Gatewayens egen LAN-adress är en annan väg. Paket till själva lådan går till INPUT, inte FORWARD, så en klient kan tappa en LAN-värd och ändå öppna routerns admin-sida. Lägg till motsvarande INPUT-regel när det spelar roll.
Vad filtret inte kan se
Filtrering sker när ett paket utvärderas, så en etablerad TCP-session kan fortsätta tills den stängs eller återställs. Om blockeringen måste bita direkt, rensa de spårade flödena för den källan med conntrack -D -s 10.8.0.6 efter att regeln satts in. Om några sekunders överlappning är acceptabelt, registrera det valet i stället för att lämna det implicit. Hur som helst måste nästa person veta om regeln stoppar levande trafik eller bara nya anslutningar.
Trafik mellan parter rör aldrig värdens brandvägg. Med client-to-client aktiverat vidarebefordrar OpenVPN dessa paket inne i daemonen, så varken FORWARD eller INPUT ser dem. De enda lösningarna är att stänga av client-to-client eller acceptera att parter kan nå varandra; en iptables-regel ser inte den trafiken.
IPv6, firmware och överlevnad efter omstart
En IPv4-regel säger inget om IPv6. Om tunneln och LAN bär båda familjerna måste motsvarande regel finnas i ip6tables, eller i den nftables-regeluppsättning som äger policyn på den värden. Router-firmware gömmer ofta netfilter bakom sin egen abstraktion, så syntax och tabellnamn kopierade från ett forum gäller kanske inte.
På OpenWrt är den dokumenterade vägen en brandväggskonfigurationspost och inte en handskriven iptables-rad, och en handskriven rad kan försvinna när brandväggen laddas om. Andra distributioner återställer regler via netfilter-persistent, en startenhet eller en leverantörslagring, och dessa mekanismer är inte utbytbara. Bevisa den du valde med en omstart, eftersom en omladdning övar en annan väg.
Verifiera per väg och rulla sedan tillbaka rent
Testa varje väg separat, eftersom en lyckad kontroll döljer de andra. En blockerad klient ska fortfarande nå internet via tunneln men misslyckas mot en LAN-värd, en andra klient ska nå samma värd, och gateway-adressen och partnervägen behöver var sin observation. Skriv resultaten bredvid regeln så att nästa ändring har en baslinje. Tabellen nedan är uppsättningen som är värd att behålla i biljetten.
| Väg | Förväntat med regeln | När det misslyckas |
|---|---|---|
| Blockerad klient till en LAN-värd | Inget svar | Regeln ligger under en acceptans, eller källan matchar inte |
| Blockerad klient till internet | Fungerar via tun0 | Regeln är för bred, utan destinationsmatchning |
| Andra klienten till samma LAN-värd | Fungerar | Regeln matchade mer än den avsedda värden |
| Blockerad klient till gatewayens LAN-adress | Blockerad endast med motsvarande INPUT-regel | INPUT-regel saknas |
| Blockerad klient till en partners tunneladress | Fungerar fortfarande | client-to-client är aktiverat och utanför brandväggens räckvidd |
Tillbakarullning är en borttagning enligt specifikation, inte en flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP tar bort exakt den posten och lämnar resten av kedjan intakt. Ta bort samma rad från filen som återställer reglerna vid start, ladda om den och bekräfta att klienten når LAN-värden igen. En flush av FORWARD skulle också ångra regler du inte skrev, vilket gör en tillbakarullning till en andra incident.
Innan du stänger biljetten, bekräfta tre saker: den fästa adressen matchar certifikatet, regeln ligger över acceptanserna med en räknare som inte är noll, och beständighetsfilen innehåller samma regel som du testade. Saknas något av detta är blockeringen en illusion i en shell-session.