Een kliënt op jou OpenVPN-bediener moet LAN-toegang verloor terwyl elke ander tonnel aan bly. Soek daarvoor, en die top-antwoord sê gewoonlik die daemon kan dit nie doen, wat net half waar is: OpenVPN het geen per-kliënt-vuurmuur nie, maar die gasheer wat die tonnel termineer, filter reeds pakkette. Die twee besluite wat saak maak, is die identiteit wat jy blokkeer en die posisie van die reël. Kry dit reg, en die verandering word een reël wat jy kan toets en verwyder.

Pen die kliënt vas voordat jy die reël skryf

OpenVPN verhuur tonneladresse uit 'n poel, so 10.8.0.6 is 'n sitplek eerder as 'n persoon. Wanneer die sessie eindig, keer die huur terug en kan dit aan die volgende verbinding gegee word, wat beteken 'n reël wat teen daardie adres geskryf is, volg die sitplek en nie die gebruiker nie. Besluit dus eers wat jy eintlik blokkeer: 'n adres vir 'n kort eksperiment, of 'n sertifikaat vir iemand wat jy wil uitsluit.

Om die adres aan die sertifikaat te bind, skep 'n lêer in die gids wat deur client-config-dir genoem word en gee die lêer presies die sertifikaat se common name. Sit een opdrag daarin, ifconfig-push 10.8.0.6 255.255.255.0, en daardie kliënt behou dieselfde tonneladres oor herverbindings heen. Twee instellings moet bestaan voordat dit effek het: client-config-dir moet in die bedienerkonfigurasie verklaar word, en die gestuurde adres moet in 'n subnet sit wat die bediener kan roeteer. Mis een van die twee en die lêer word sonder 'n fout geïgnoreer, wat die volgende vuurmuurtoets misleidend maak.

'n Tydelike blok kan 'n poeladres gebruik, solank die kaartjie aanteken watter sessie dit destyds gehad het.

Volgorde bepaal of die drop uitgevoer word

Op 'n Linux-gateway wat tussen die tonnel en die LAN aanstuur, kruis pakkette die FORWARD-ketting. Lees die opdrag hieronder as 'n sin: voeg by die kop van FORWARD in, pas verkeer wat van tun0 inkom, van daardie enkele gasheer, gerig op die LAN-subnet, en laat dit val.

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

Die -I is wat die reël laat loop. Met -A bygevoeg, beland dit onder enige breë aanvaarding vir die tonnel-subnet en sien nooit 'n pakket nie. Verifieer die posisie met iptables -vnL FORWARD --line-numbers, en lees ook die tellers: 'n drop bo wat niks tel nie, beteken die verkeer kom via 'n ander pad.

Die gateway se eie LAN-adres is 'n ander pad. Pakkette wat na die boks self gestuur word, gaan na INPUT, nie FORWARD nie, so 'n kliënt kan 'n LAN-gasheer verloor en steeds die router se admin-bladsy oopmaak. Voeg die ooreenstemmende INPUT-reël by wanneer dit saak maak.

Wat die filter nie kan sien nie

Filtering gebeur wanneer 'n pakket geëvalueer word, so 'n gevestigde TCP-sessie kan voortduur totdat dit sluit of teruggestel word. As die blok onmiddellik moet byt, vee die gevolgde strome vir daardie bron uit met conntrack -D -s 10.8.0.6 nadat die reël ingegaan het. As 'n paar sekondes oorvleueling aanvaarbaar is, teken daardie keuse aan eerder as om dit implisiet te laat. Hoe dit ook al sy, die volgende persoon moet weet of die reël lewendige verkeer stop of net nuwe verbindings.

Eweknie-verkeer raak nooit die gasheer se vuurmuur nie. Met client-to-client geaktiveer, stuur OpenVPN daardie pakkette binne die daemon aan, so nóg FORWARD nóg INPUT sien hulle. Die enigste oplossings is om client-to-client af te skakel of te aanvaar dat eweknieë mekaar kan bereik; 'n iptables-reël sal daardie verkeer nie sien nie.

IPv6, firmware en oorlewing na herlaai

'n IPv4-reël sê niks oor IPv6 nie. As die tonnel en die LAN albei families dra, moet die ekwivalente reël in ip6tables bestaan, of in die nftables-reëlstel wat beleid op daardie gasheer besit. Router-firmware versteek dikwels netfilter agter sy eie abstraksie, so sintaksis en tabelname wat van 'n forum gekopieer is, geld dalk nie.

Op OpenWrt is die gedokumenteerde pad 'n vuurmuurkonfigurasie-inskrywing eerder as 'n handgeskrewe iptables-reël, en 'n handgeskrewe reël kan verdwyn wanneer die vuurmuur herlaai. Ander verspreidings herstel reëls deur netfilter-persistent, 'n boot-eenheid of 'n verkoperswinkel, en daardie meganismes is nie uitruilbaar nie. Bewys watter een jy gekies het met 'n herlaai, want 'n herlaai oefen 'n ander pad.

Verifieer per pad, en rol dan skoon terug

Toets elke pad afsonderlik, want een suksesvolle kontrole verberg die ander. 'n Geblokkeerde kliënt moet steeds die internet deur die tonnel bereik terwyl dit teen 'n LAN-gasheer faal, 'n tweede kliënt moet daardie selfde gasheer bereik, en die gateway-adres en die eweknie-pad het elk sy eie waarneming nodig. Skryf die resultate langs die reël sodat die volgende verandering 'n basislyn het. Die tabel hieronder is die stel wat werd is om in die kaartjie te hou.

PadVerwag met die reëlWanneer dit faal
Geblokkeerde kliënt na 'n LAN-gasheerGeen antwoordReël sit onder 'n aanvaarding, of die bron stem nie ooreen nie
Geblokkeerde kliënt na die internetWerk deur tun0Reël is te breed, met geen bestemming-passing nie
Tweede kliënt na dieselfde LAN-gasheerWerkReël het meer as die beoogde gasheer gepas
Geblokkeerde kliënt na die gateway se LAN-adresSlegs geblokkeer met die ooreenstemmende INPUT-reëlINPUT-reël ontbreek
Geblokkeerde kliënt na 'n eweknie-tonneladresWerk steedsclient-to-client is geaktiveer en buite die vuurmuur se omvang

Terugrol is 'n skrapping volgens spesifikasie, nie 'n flush nie: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP verwyder presies daardie inskrywing en laat die res van die ketting ongeskonde. Verwyder dieselfde reël uit watter lêer ook al die reëls by boot herstel, herlaai dit, en bevestig die kliënt bereik weer die LAN-gasheer. Om FORWARD te flush sou ook reëls ongedaan maak wat jy nie geskryf het nie, wat 'n terugrol in 'n tweede voorval verander.

Voordat jy die kaartjie sluit, bevestig drie dinge: die vasgepen adres stem ooreen met die sertifikaat, die reël sit bo die aanvaardings met 'n nie-nul teller, en die volhardingslêer bevat dieselfde reël wat jy getoets het. As enige van dié ontbreek, is die blok 'n shell-sessie-illusie.

Verwante artikels