Blokker éin OpenVPN-klient frå LAN utan å stoppe tunnelen
Fest tunneladressa til klienten til sertifikatet, dropp LAN-trafikken i toppen av FORWARD, og verifiser deretter IPv6, spora sesjonar og overleving etter omstart.
Éin klient på OpenVPN-tenaren din må miste LAN-tilgang medan alle andre tunnelar held fram. Søkjer du etter dette, seier det beste svaret vanlegvis at daemonen ikkje kan, noko som berre er halvt sant: OpenVPN har ingen brannmur per klient, men verten som avsluttar tunnelen filtrerer allereie pakkar. Dei to avgjerdene som tel, er identiteten du blokkerer, og plasseringa av regelen. Får du desse rett, blir endringa éi linje du kan teste og fjerne.
Fest klienten før du skriv regelen
OpenVPN leigar ut tunneladresser frå ein pool, så 10.8.0.6 er eit sete, ikkje ein person. Når sesjonen sluttar, går leiga tilbake og kan givast til neste tilkopling, noko som betyr at ein regel skriven mot den adressa følgjer setet, ikkje brukaren. Avgjer derfor først kva du faktisk blokkerer: ei adresse for eit kort eksperiment, eller eit sertifikat for nokon du vil halde ute.
For å binde adressa til sertifikatet, lag ein fil i katalogen som client-config-dir peikar på, og gi fila nøyaktig common name til sertifikatet. Legg inn éin direktiv, ifconfig-push 10.8.0.6 255.255.255.0, og den klienten held same tunneladresse ved gjenoppkoplingar. To innstillingar må finnast for at dette skal verke: client-config-dir må vere deklarert i serverkonfigurasjonen, og adressa som blir send må liggje i eit subnett serveren kan rute. Manglar éin, blir fila ignorert utan feil, noko som gjer neste brannmurtest misvisande.
Ei mellombels blokkering kan bruke ei pooladresse, så lenge billetten registrerer kva sesjon som hadde ho då.
Rekkjefølgja avgjer om droppet køyrer
På ein Linux-gateway som videresender mellom tunnelen og LAN, passerer pakkar kjeda FORWARD. Les kommandoen nedanfor som ei setning: set inn i toppen av FORWARD, match trafikk som kjem inn frå tun0, frå den eine verten, adressert til LAN-subnettet, og dropp han.
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 å køyre. Lagt til med -A, landar han under kvar brei aksept for tunnelsubnettet og ser aldri ein pakke. Verifiser plasseringa med iptables -vnL FORWARD --line-numbers, og les òg teljarane: eit dropp i toppen som ikkje tel noko, betyr at trafikken kjem inn ein annan veg.
Den eigne LAN-adressa til gatewayen er ein annan veg. Pakkar sende til sjølve boksen går til INPUT, ikkje FORWARD, så ein klient kan miste ein LAN-vert og likevel opne admin-sida til ruteren. Legg til den matchende INPUT-regelen når det tel.
Kva filteret ikkje kan sjå
Filtrering skjer når ein pakke blir vurdert, så ein etablert TCP-sesjon kan halde fram til han blir lukka eller nullstilt. Må blokkeringa bite straks, tøm dei spora straumane for den kjelda med conntrack -D -s 10.8.0.6 etter at regelen er sett inn. Er nokre sekund med overlapping akseptabelt, registrer det valet i staden for å la det vere implisitt. Uansett må neste person vite om regelen stoppar levande trafikk eller berre nye tilkoplingar.
Peer-trafikk rører aldri brannmuren til verten. Med client-to-client aktivert videresender OpenVPN desse pakkane inne i daemonen, så verken FORWARD eller INPUT ser dei. Dei einaste løysingane er å slå av client-to-client eller akseptere at peerar kan nå kvarandre; ein iptables-regel vil ikkje sjå den trafikken.
IPv6, firmware og overleving etter omstart
Ein IPv4-regel seier ingenting om IPv6. Viss tunnelen og LAN-et ber begge familiane, må den tilsvarande regelen finnast i ip6tables, eller i nftables-regelsettet som eig policyen på den verten. Rutar-firmware skjuler ofte netfilter bak si eiga abstraksjon, så syntaks og tabellnamn kopierte frå eit forum gjeld kanskje ikkje.
På OpenWrt er den dokumenterte vegen ein brannmurkonfigurasjonspost og ikkje ei handskriven iptables-linje, og ei handskriven linje kan forsvinne når brannmuren blir lasta på nytt. Andre distribusjonar gjenopprettar reglar via netfilter-persistent, ein oppstartseining eller eit leverandørlager, og desse mekanismane kan ikkje bytast om. Prov den du valde med ein omstart, fordi ei omlasting trenar ein annan veg.
Verifiser per veg, og rull deretter reint tilbake
Test kvar veg separat, fordi éin vellukka sjekk skjuler dei andre. Ein blokkert klient skal framleis nå internett gjennom tunnelen, men feile mot ein LAN-vert, ein andre klient skal nå same vert, og gateway-adressa og peer-vegen treng kvar si eiga observasjon. Skriv resultata ved sida av regelen, slik at neste endring har ein baseline. Tabellen nedanfor er settet som er verdt å behalde i billetten.
| Veg | Forventa med regelen | Når han feilar |
|---|---|---|
| Blokkert klient til ein LAN-vert | Ingen svar | Regelen ligg under ein aksept, eller kjelda matchar ikkje |
| Blokkert klient til internett | Verker gjennom tun0 | Regelen er for brei, utan destinasjonsmatch |
| Andre klient til same LAN-vert | Verker | Regelen matcha meir enn den tiltenkte verten |
| Blokkert klient til LAN-adressa til gatewayen | Blokkert berre med den matchende INPUT-regelen | INPUT-regel manglar |
| Blokkert klient til ei peer-tunneladresse | Verker framleis | client-to-client er aktivert og utanfor rekkevidda til brannmuren |
Tilbakerulling er ei sletting etter spesifikasjon, ikkje ein flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP fjernar nøyaktig den posten og lèt resten av kjeda vere intakt. Fjern same linje frå fila som gjenopprettar reglane ved oppstart, last ho på nytt, og stadfest at klienten igjen når LAN-verten. Ein flush av FORWARD ville òg oppheve reglar du ikkje skreiv, noko som gjer ei tilbakerulling til ei ny hending.
Før du lukkar billetten, stadfest tre ting: den fastlåste adressa matchar sertifikatet, regelen ligg over akseptane med ein teljar som ikkje er null, og persistensfila inneheld same regel som du testa. Manglar noko av dette, er blokkeringa ein illusjon i ein shell-sesjon.