Bloki unu OpenVPN-klienton el la LAN sen haltigi la tunelon

Unu kliento sur via OpenVPN-servilo devas perdi LAN-aliron dum ĉiu alia tunelo restas aktiva. Se vi serĉas tion, la plej bona respondo kutime diras, ke la demono ne povas, kio estas nur duone vera: OpenVPN havas neniun fajroŝirmilon por kliento, sed la gastiganto, kiu finas la tunelon, jam filtradas pakaĵojn. La du decidoj, kiuj gravas, estas la identeco, kiun vi blokas, kaj la pozicio de la regulo. Faru ilin ĝuste kaj la ŝanĝo fariĝas unu linio, kiun vi povas testi kaj forigi.

Fiksu la klienton antaŭ ol skribi la regulon

OpenVPN luigas tunelajn adresojn el naĝejo, do 10.8.0.6 estas sidejo, ne persono. Kiam la sesio finiĝas, la luo revenas kaj povas esti donita al la sekva konekto, kio signifas, ke regulo skribita kontraŭ tiu adreso sekvas la sidejon, ne la uzanton. Do unue decidu, kion vi efektive blokas: adreson por mallonga eksperimento, aŭ atestilon por iu, kiun vi volas teni ekstere.

Por ligi la adreson al la atestilo, kreu dosieron en la dosierujo nomita de client-config-dir kaj donu al la dosiero precize la common name de la atestilo. Metu unu direktivon en ĝin, ifconfig-push 10.8.0.6 255.255.255.0, kaj tiu kliento konservas la saman tunelan adreson inter rekonektoj. Du agordoj devas ekzisti por ke tio efiku: client-config-dir devas esti deklarita en la servila agordo, kaj la puŝita adreso devas situi en subreto, kiun la servilo povas enkursigi. Manku unu kaj la dosiero estas ignorata sen eraro, kio igas la sekvan fajroŝirmilan teston misgvida.

Provizora bloko povas uzi naĝejan adreson, kondiĉe ke la bileto registras, kiu sesio tenis ĝin tiutempe.

La ordo decidas, ĉu la forĵeto ruliĝas

Sur Linuksa pordego, kiu plusendas inter la tunelo kaj la LAN, pakaĵoj trapasas la ĉenon FORWARD. Legu la suban komandon kiel frazon: enŝovu ĉe la kapo de FORWARD, kongruigu trafikon enirantan el tun0, de tiu sola gastiganto, adresitan al la LAN-subreto, kaj forĵetu ĝin.

iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP

La -I estas tio, kio igas la regulon ruliĝi. Aldonita per -A, ĝi falas sub ĉiu ajn larĝa akcepto por la tunela subreto kaj neniam vidas pakaĵon. Kontrolu la pozicion per iptables -vnL FORWARD --line-numbers, kaj legu ankaŭ la nombrilojn: forĵeto ĉe la supro, kiu nombras nenion, signifas, ke la trafiko alvenas per alia vojo.

La propra LAN-adreso de la pordego estas alia vojo. Pakaĵoj senditaj al la skatolo mem iras al INPUT, ne al FORWARD, do kliento povas perdi LAN-gastiganton kaj tamen malfermi la administran paĝon de la enkursigilo. Aldonu la kongruan INPUT-regulon, kiam tio gravas.

Kion la filtro ne povas vidi

Filtrado okazas kiam pakaĵo estas taksata, do establita TCP-sesio povas daŭri ĝis ĝi fermiĝas aŭ estas restarigita. Se la bloko devas mordi tuj, viŝu la spuritajn fluojn por tiu fonto per conntrack -D -s 10.8.0.6 post kiam la regulo eniras. Se kelkaj sekundoj da interkovro estas akcepteblaj, registru tiun elekton anstataŭ lasi ĝin implicita. Ĉiuokaze, la sekva persono devas scii, ĉu la regulo haltigas vivan trafikon aŭ nur novajn konektojn.

Trafiko inter samtavolanoj neniam tuŝas la fajroŝirmilon de la gastiganto. Kun client-to-client ŝaltita, OpenVPN plusendas tiujn pakaĵojn ene de la demono, do nek FORWARD nek INPUT vidas ilin. La solaj riparoj estas malŝalti client-to-client aŭ akcepti, ke samtavolanoj povas atingi unu la alian; iptables-regulo ne vidos tiun trafikon.

IPv6, firmvaro kaj postvivo de restartigo

IPv4-regulo diras nenion pri IPv6. Se la tunelo kaj la LAN portas ambaŭ familiojn, la ekvivalenta regulo devas ekzisti en ip6tables, aŭ en la nftables-regula aro, kiu posedas politikon sur tiu gastiganto. Enkursigila firmvaro ofte kaŝas netfilter malantaŭ sia propra abstraktado, do sintakso kaj tabelnomoj kopiitaj el forumo eble ne aplikiĝas.

Sur OpenWrt, la dokumentita vojo estas fajroŝirmila agorda ero, ne permane skribita iptables-linio, kaj permane skribita linio povas malaperi kiam la fajroŝirmilo reŝarĝiĝas. Aliaj distribuaĵoj restarigas regulojn per netfilter-persistent, starta unuo aŭ vendista stokejo, kaj tiuj mekanismoj ne estas interŝanĝeblaj. Pruvu tiun, kiun vi elektis, per restartigo, ĉar reŝargo ekzercas alian vojon.

Kontrolu laŭ vojo, poste restarigu pure

Testu ĉiun vojon aparte, ĉar unu sukcesa kontrolo kaŝas la aliajn. Blokita kliento ankoraŭ devus atingi la interreton tra la tunelo dum ĝi malsukcesas kontraŭ LAN-gastiganto, dua kliento devus atingi tiun saman gastiganton, kaj la pordega adreso kaj la samtavolana vojo bezonas ĉiu sian propran observadon. Skribu la rezultojn apud la regulo, por ke la sekva ŝanĝo havu bazlinion. La suba tabelo estas la aro inda resti en la bileto.

Restarigo estas forigo laŭ specifiko, ne flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP forigas precize tiun eron kaj lasas la reston de la ĉeno sendifekta. Forigu la saman linion el kiu ajn dosiero restarigas la regulojn ĉe starto, reŝargu ĝin, kaj konfirmu, ke la kliento denove atingas la LAN-gastiganton. Flush de FORWARD ankaŭ malfarus regulojn, kiujn vi ne skribis, kio igas restarigon dua incidento.

Antaŭ ol fermi la bileton, konfirmu tri aferojn: la fiksita adreso kongruas kun la atestilo, la regulo situas super la akceptoj kun nombrilo ne nula, kaj la persista dosiero enhavas la saman regulon, kiun vi testis. Se iu el tiuj mankas, la bloko estas iluzio en shell-sesio.