Beperk 'n OpenVPN-poortweg tot een LAN met UFW-reëls

Besluit die toestemming voordat jy 'n vuurmuurlêer oopmaak: geauthentiseerde kliënte mag verbindings na een spesifieke subnet open, en die poortweg moet elke ander deurvoerpad weier, selfs wanneer 'n kliënt ekstra roetes installeer. Daardie sin is die ontwerp, en elke reël hieronder bestaan om dit af te dwing. Enigiets wyer, soos die hele private adresruimte, internetuitgang deur die tonnel of eweknieverkeer, is 'n ander ontwerp wat sy eie besluit nodig het. Die reëls is ook doelbewus vervelig, want 'n slim vuurmuur is een wat niemand later kan audit nie.

Skryf eers die topologie en die toestemming neer

Die voorbeeld gebruik 'n Community OpenVPN bediener met 'n TUN-toestel in gebruikersruimte genaamd tun0, 'n kliëntpoel van 10.77.0.0/24, en een gekoppelde subnet 192.168.60.0/24 op lan0. IPv4-deurvoer werk reeds en die LAN het reeds 'n terugroete na die poel, so niks hier hang van vertaling tussen hulle af nie.

UFW besit die vuurmuur op hierdie gasheer, en geen houerreëlversameling of aparte nftables-tabel mag 'n vroeër aanvaardingspad installeer nie. 'n Vloei-afwentelkortpad wat die filter oorslaan, sou die wagkettings bloot versierend maak, so bevestig dat nie een aktief is nie. Laat OpenVPN se eie client-to-client deurvoer gedeaktiveer, want eweknieverkeer wat nooit die bedryfstelsel se filter oorsteek nie kan nie daardeur begrens word nie. Die eksterne luisteraar en die administrasiereëls bly soos hulle is, want hierdie verandering beheer ontsleutelde tonnelverkeer eerder as om die vuurmuur te vervang.

Plaas die wagte voor UFW se vroeë aanvaardings

Toestemming vir 'n roete gevolg deur 'n weiering is nie genoeg vir 'n streng grens nie. Die standaard before-reëls aanvaar gevestigde verkeer en sekere ICMP voordat enige gebruikersreël geraadpleeg word, so 'n vloei wat verlede week toegelaat is, kan buite die nuwe bestemmingsbeperking bly bloot omdat dit nog toestand het. Maak 'n rugsteun van die UFW-lêers en hou 'n buitebandkonsole oop voordat jy redigeer.

In die *filter-afdeling van /etc/ufw/before.rules, verklaar twee kettings langs die bestaande verklarings en voor enige reëllyn.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Dadelik ná die verklarings, en voor die toelatings vir invoer en deurvoer, spring daarin en definieer wat hulle toelaat.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Hou die res van die afdeling en sy COMMIT-lyn. Om 'n tweede filtertabel in te plak of onverwante reëls te verwyder, is hoe 'n vuurmuurverandering 'n onderbreking word, en die lêer is een herbegin weg van die enigste kopie wat saak maak.

Lees wat elke wag toelaat en weier

Die eerste ketting gaan net voort met verwerking wanneer die bron in die poel is, die bestemming die een subnet is, die uitgangskoppelvlak die LAN is en die pakket in die oorspronklike rigting van sy vloei beweeg. Alles anders wat uit die tonnel kom, word laat val, insluitend 'n bron buite die poel en enige bestemming anderkant die toegelate subnet.

'n Ewekniepakket kom in en verlaat tun0, so dit faal die LAN-koppelvlaktoets voordat 'n bestemmingstoets selfs bereik word. Nuwe verbindings van die LAN na kliënte faal ook die antwoordrigtingtoets, wat die omgekeerde terugbelpad by verstek sluit.

Die RETURN-teiken hou gewone UFW-beleid in werking. Hierdie kettings filter, en die roete-toestemming wat jy volgende byvoeg, besluit steeds of 'n oorlewende pakket aanvaar word. Daardie skeiding is wat jou later toelaat om die toegelate subnet op een plek te verander. As die wagte pakkette dadelik aanvaar het, sou elke toekomstige reël twee keer bygevoeg moes word.

Magtig die subnet en sluit die symdeure

Voorskou eers die roete-toestemming, en laat dan die voorskou-vlag val om dit toe te pas: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Kyk daarna na die volgorde van die gebruikersreëls, want 'n vroeëre weiering wen steeds bo 'n latere toelating. 'n Toestemming vir 'n hele subnet is ook die verkeerde vorm wanneer net een gasheer se HTTPS-poort bereikbaar moet wees.

Let op wat die invoerweiering doen: tonnelkliënte kan geen diens op die poortweg self bereik nie, insluitend 'n DNS-luisteraar wat aan sy LAN-adres gebind is. Om DNS daar te huisves, vereis 'n doelbewuste uitsondering voor die weiering en 'n hersiene toestemmingskontrak. As UFW IPv6 bestuur, voeg ooreenstemmende weierings by vir tun0 in before6.rules ook, want 'n IPv4-bestemmingslys sê niks oor IPv6-pakkette nie.

Verifieer die gelaaide beleid, nie die voorskou nie

Voorskou die herlaai, pas dit in 'n onderhoudsvenster toe, en lees die lewende reëlversameling.

sudo ufw --dry-run reload
sudo ufw show raw

Bevestig dat die tonnelwagte verskyn voor die standaardtoestands- en ICMP-toelatings. Gewone ufw status wys nie met die hand geredigeerde before-reëls nie, en daarom kom operateurs tot die slotsom dat 'n reël ontbreek terwyl dit in werklikheid gelaai is. Lees die rou lys van bo na onder eerder as om na 'n fragment te soek. As die wagte ná 'n toestandstoelating verskyn, doen die grens nie wat die lêer voorstel nie.

Toets dan gedrag eerder as teks. Open 'n nuwe verbinding na 'n toegelate gasheer en kyk na die antwoord, stuur 'n onskadelike versoek na 'n bestemming buite die subnet en bevestig dat dit sterf, probeer 'n eweknieverbinding, probeer 'n diens wat plaaslik op die poortweg is, en probeer 'n ongevraagde LAN-na-kliënt-verbinding. Sluit een buite-omvangvloei in wat voor die verandering bestaan het, en wis net daardie vloei eerder as om die masjien se hele naspeuringstabel te spoel.

Teken die beperkinge langs die reëls aan: dit begrens deurvoer en niks anders nie. Dit keer nie dat 'n kliënt sy eie internetverbinding gebruik nie, keer nie dat 'n toegelate LAN-gasheer verkeer verder deurstuur nie, en vervang nie die verifikasie binne die toegelate dienste nie.