Ien OpenVPN-klant fan it LAN blokkearje sûnder de tunnel te stopjen

Ien klant op jo OpenVPN-tsjinner moat LAN-tagong ferlieze wylst elke oare tunnel oan bliuwt. Sykje jo dêrnei, dan seit it bêste antwurd meastentiids dat de daemon dat net kin, wat mar heal wier is: OpenVPN hat gjin firewall per klant, mar de host dy't de tunnel einiget filteret al pakketten. De twa besluten dy't der ta dogge binne de identiteit dy't jo blokkearje en de posysje fan 'e regel. Krij dy goed en de feroaring wurdt ien rigel dy't jo testen en fuorthelje kinne.

Pin de klant foardat jo de regel skriuwe

OpenVPN ferhiert tunneladressen út in poel, dus 10.8.0.6 is in sitplak, net in persoan. As de sesje einiget komt de hier werom en kin oan de folgjende ferbining jûn wurde, wat betsjut dat in regel skreaun tsjin dat adres it sitplak folget, net de brûker. Beslis dus earst wat jo eins blokkearje: in adres foar in koart eksperimint, of in sertifikaat foar ien dy't jo bûten hâlde wolle.

Om it adres oan it sertifikaat te binen, meitsje in bestân yn 'e map neamd troch client-config-dir en jou it bestân krekt de common name fan it sertifikaat. Set der ien rjochtline yn, ifconfig-push 10.8.0.6 255.255.255.0, en dy klant hâldt itselde tunneladres oer werferbiningen hinne. Twa ynstellingen moatte bestean om dit te litten wurkjen: client-config-dir moat yn 'e tsjinnerkonfiguraasje ferklearre wêze, en it stjoerde adres moat yn in subnet lizze dat de tsjinner routearje kin. Mis ien fan beide en it bestân wurdt sûnder flater negearre, wat de folgjende firewaltest misliedend makket.

In tydlike blokkade kin in poeladres brûke, salang't it ticket fêstleit hokker sesje it doedestiden hie.

De folchoarder beslút oft de drop rint

Op in Linux-gateway dy't tusken de tunnel en it LAN trochstjoert, geane pakketten troch de keatling FORWARD. Lês it kommando hjirûnder as in sin: foegje oan 'e kop fan FORWARD ta, match ferkear dat fan tun0 ynkomt, fan dat iene host, rjochte op it LAN-subnet, en smyt it fuort.

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

It -I is wat de regel rinne lit. Tafoege mei -A, lânet it ûnder elke brede akseptaasje foar it tunnelsubnet en sjocht nea in pakket. Ferifiearje de posysje mei iptables -vnL FORWARD --line-numbers, en lês ek de tellers: in drop boppeoan dy't neat telt betsjut dat it ferkear fia in oare wei komt.

It eigen LAN-adres fan 'e gateway is in oare wei. Pakketten nei de doaze sels geane nei INPUT, net nei FORWARD, dus in klant kin in LAN-host ferlieze en dochs de admin-side fan 'e router iepenje. Foegje de byhearrende INPUT-regel ta as dat der ta docht.

Wat it filter net sjen kin

Filtering bart as in pakket evaluearre wurdt, dus in fêstige TCP-sesje kin trochgean oant dy slút of weromset wurdt. As de blokkade daliks bite moat, wiskje de folge streamen foar dy boarne mei conntrack -D -s 10.8.0.6 nei't de regel der yn sit. As in pear sekonden oerlap akseptabel is, skriuw dy kar op ynstee fan it ymplisyt te litten. Hoe dan ek, de folgjende persoan moat witte oft de regel libjend ferkear stopet of allinnich nije ferbiningen.

Ferkear tusken pearen rekket nea de firewall fan 'e host. Mei client-to-client oan stjoert OpenVPN dy pakketten binnen de daemon troch, dus noch FORWARD noch INPUT sjocht se. De iennige oplossingen binne client-to-client útsette of akseptearje dat pearen elkoar berikke kinne; in iptables-regel sil dat ferkear net sjen.

IPv6, firmware en oerlibjen nei in werstart

In IPv4-regel seit neat oer IPv6. As de tunnel en it LAN beide famyljes drage, moat de lykweardige regel bestean yn ip6tables, of yn 'e nftables-regelset dy't it belied op dy host hat. Routerfirmware ferstoppet netfilter faak efter syn eigen abstraksje, dus syntaksis en tabelnammen kopiearre fan in foarum jouwe miskien net.

Op OpenWrt is it dokumintearre paad in firewallkonfiguraasje-ynstap, net in hânskreaune iptables-rigel, en in hânskreaune rigel kin ferdwine as de firewall wer lâdt. Oare distribúsjes restaurearje regels fia netfilter-persistent, in boot-ienheid of in leveransiersopslach, en dy meganismen binne net útwikselber. Bewiis dy't jo keazen hawwe mei in werstart, want in werladen oefenet in oar paad.

Ferifiearje per paad, en rol dan skjin werom

Test elk paad apart, want ien slagge kontrôle ferstoppet de oaren. In blokkearre klant moat noch fia de tunnel it ynternet berikke wylst er tsjin in LAN-host mislearret, in twadde klant moat deselde host berikke, en it gatewayadres en it peerpaad hawwe elk har eigen observaasje nedich. Skriuw de resultaten njonken de regel, sadat de folgjende feroaring in basisline hat. De tabel hjirûnder is de set dy't it wurdich is om yn it ticket te hâlden.

Weromrollen is in fuortsmite neffens spesifikaasje, net in flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP hellet krekt dy ynstap fuort en lit de rest fan 'e keatling yntakt. Helje deselde rigel fuort út hokker bestân dan ek dat de regels by boot werombringt, laad it wer en befêstigje dat de klant de LAN-host wer berikt. In flush fan FORWARD soe ek regels ôfbrekke dy't jo net skreaun hawwe, wat in weromrollen yn in twadde ynsidint feroaret.

Foardat jo it ticket slute, befêstigje trije dingen: it fêstsette adres komt oerien mei it sertifikaat, de regel stiet boppe de akseptaasjes mei in teller dy't net nul is, en it persistinsjebestân befettet deselde regel dy't jo testen. As ien fan dy mist, is de blokkade in yllúzje yn in shell-sesje.