In OpenVPN-poarte oan ien LAN bine mei UFW-regels
Lit tunnelkliïnten ien subnet berikke en neat oars. Wachtkeatlingen foar de iere akseptaasjes fan UFW, in rûtefergunning en tests dy't de grins bewize.
Bepale de fergunning foardat jo in firewalltriem iepenje: autentisearre kliïnten meie ferbiningen nei ien beskaat subnet iepenje, en de poarte moat elke oare tranzytrûte wegerje, sels as in kliïnt ekstra rûtes ynstallearret. Dy sin is it ûntwerp, en elke regel hjirûnder bestiet om dy te hanthavenjen. Wat breder, lykas de hiele partikuliere adresromte, internetútgong troch de tunnel of peer-to-peer-ferkear, is in oar ûntwerp dat syn eigen beslút nedich hat. De regels binne ek bewust saai, want in tûke firewall is ien dy't nimmen letter auditearje kin.
Skriuw earst de topology en de fergunning op
It foarbyld brûkt in Community OpenVPN tsjinner mei in TUN-apparaat yn brûkersromte neamd tun0, in kliïntepool 10.77.0.0/24, en ien oansletten subnet 192.168.60.0/24 op lan0. IPv4-foarstjoering wurket al en it LAN hat al in weromrûte nei de pool, dus neat hjir hinget fan oersetting tusken dy beiden ôf.
UFW is eigner fan de firewall op dizze host, en gjin containerregelset of aparte nftables-tabel mei in eardere akseptaasjerûte ynstallearje. In floei-ôflaadkoarte paad dat it filter oerslacht soe de wachtkeatlingen fersierend meitsje, dus befêstigje dat gjinien aktyf is. Lit OpenVPN syn eigen client-to-client -foarstjoering útskeakele, want peer-to-peer-ferkear dat nea it filter fan it bestjoeringssysteem krúst kin dêrmei net beheind wurde. De eksterne listener en de administraasjeregels bliuwe sa't se binne, om't dizze wiziging ûntsiferre tunnelferkear regelet ynstee fan de firewall te ferfangen.
Set de wachten foar de iere akseptaasjes fan UFW
In rûtefergunning folge troch in wegering is net genôch foar in strikte grins. De standert before-regels akseptearje festige ferkear en guon ICMP foardat ea in brûkersregel besjoen wurdt, dus in floei dy't ferline wike tastien waard kin bûten de nije bestimmingsbeheining bliuwe, allinnich om't er noch steat hat. Meitsje in reservekopy fan de UFW-triemmen en hâld in bûtenbânskonsole iepen foardat jo bewurkje.
Yn de seksje *filter fan de triem /etc/ufw/before.rules, ferklearje twa keatlingen njonken de besteande ferklearringen en foar elke regelline.
:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]Daliks nei de ferklearringen, en foar de yngong- en foarstjoerfergunningen, spring deryn en definiearje wat se talitte.
-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 DROPHâld de rest fan de seksje en syn COMMIT -rige. In twadde filtertabel plakke of net besibbe regels wiskje is hoe't in firewallwiziging in steuring wurdt, en de triem is ien werstart fuort fan de iennichste kopy dy't fan belang is.
Lês wat elke wacht talit en wegeret
De earste keatling giet troch mei ferwurkjen allinnich as de boarne yn 'e pool is, de bestimming it iene subnet is, de útgongsynterface it LAN is en it pakket yn 'e oarspronklike rjochting fan syn floei reizget. Al it oare dat út 'e tunnel komt, wurdt weilitten, ynklusyf in boarne bûten de pool en elke bestimming foarby it tastiene subnet.
In peer-to-peer-pakket komt yn en giet út tun0, dus it falt by de LAN-ynterfaceproef noch foardat in bestimmingskontrôle berikt wurdt. Nije ferbiningen fan it LAN nei kliïnten falle ek by de antwurd-rjochtingsproef, wat it omkearde opskilpaad by default slút.
It doel RETURN hâldt gewoan UFW-belied yn it spul. Dizze keatlingen filterje, en de rûtefergunning dy't jo dêrnei tafoegje beslút noch hieltyd oft in oerlibjend pakket akseptearre wurdt. Krekt dy skieding lit jo letter it tastiene subnet op ien plak feroarje. As de wachten pakketten fuortendaliks akseptearren, soe elke takomstige regel twa kear tafoege wurde moatte.
Machtsje it subnet en slút de syddoarren
Besjoch earst de rûtefergunning, lit dan de foarbyldflagge falle om dy ta te passen: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Besjoch dêrnei de folchoarder fan de brûkersregels, want in eardere wegering wint noch hieltyd fan in lettere fergunning. In fergunning foar it hiele subnet is ek de ferkearde foarm as allinne de HTTPS-poarte fan ien host berikber wêze moat.
Tink derom wat it yngong-weilitten docht: tunnelkliïnten kinne gjin tsjinst op de poarte sels berikke, ynklusyf in DNS-listener dy't bûn is oan syn LAN-adres. DNS dêr hoste freget in bewuste útsûndering foar it weilitten en in wersjen fergunningskontrakt. As UFW IPv6 beheart, foegje dan ek byhearrende weilittingen ta foar tun0 yn before6.rules, want in list fan IPv4-bestimmingen seit neat oer IPv6-pakketten.
Ferifiearje it laden belied, net it foarbyld
Besjoch it werladen, pas it ta yn in ûnderhâldsfenster en lês de libbene regelset.
sudo ufw --dry-run reload
sudo ufw show rawBefêstigje dat de tunnelwachten ferskine foar de standert steat- en ICMP-fergunningen. In gewoane ufw status lit net mei de hân bewurke before-regels sjen, dêrom komme operators ta de konklúzje dat in regel mist wylst er eins laden is. Lês de rûge list fan boppe nei ûnderen ynstee fan nei in fragmint te sykjen. As de wachten nei in steatfergunning ferskine, docht de grins net wat de triem suggerearret.
Test dan gedrach ynstee fan tekst. Iepenje in nije ferbining nei in tastien host en besjoch it antwurd, stjoer in ûnskuldich fersyk nei in bestimming bûten it subnet en befêstigje dat it stjert, probearje in peer-to-peer-ferbining, probearje in tsjinst dy't lokaal is op de poarte, en probearje in net-frege LAN-nei-kliïnt-ferbining. Nim ien floei bûten it berik op dy't foar de wiziging bestie, en wiskje allinne dy floei ynstee fan de hiele folchtingstabel fan 'e masine te leegjen.
Skriuw de grinzen njonken de regels: dit beheint transit en neat oars. It ferhindert in kliïnt net om syn eigen internetferbining te brûken, it ferhindert in tastien LAN-host net om ferkear fierder troch te stjoeren, en it ferfangt net de autentikaasje binnen de tastiene tsjinsten.