VPS-firewall: iepenje allinnich de VPN-poarte en bewiis it dan

In firewall dy’t allinnich de VPN-poarte talit, is net ien regel. It binne trije aparte besluten dy’t tafallich oer itselde poartenûmer geane: de ynfierkeatling beslút wat in lokaal proses berikke kin, de trochstjoerkeatling beslút wat út namme fan tunnelklanten troch de host gean kin, en de NAT-tabel skriuwt it boarneadres op ’e wei nei bûten oer. Doch ien fan dy ferkeard en it resultaat is selden in skjinne útfal. Jo krije in host dy’t klanten akseptearret mar neat laden, of in host dy’t sletten liket oant immen de folchoarder fan de keatlingen lêst.

De iennige poarte dy’t net sletten wurde kin

De VPN-harker moat ferbiningen akseptearje fan adressen dy’t jo net foarsizze kinne, dus is it per definysje in iepenbiere tsjinst. Dat is de iennige útsûndering dêr’t it ûntwerp omhinne boud is: ien UDP-poarte foar OpenVPN, ien UDP-poarte foar WireGuard, ien TCP-poarte foar in SSL VPN. Al it oare heart efter de tunnel, wat betsjuttet dat applikaasjetsjinsten har bine moatte oan it tunneladres of oan loopback, net oan alle ynterfaces.

Binen is lykwols gjin hânhaven. In proses dat oan 0.0.0.0 bûn is, is allinnich berikber as in regel it talit, en it standertbelied is de efterfal foar ferkear dat gjin regel trof, net de regel dy’t de poarte regelet. In talitting boppe jo wegering bliuwt in talitting, en in tsjinst fan it iepenbiere adres ôf helje is in selsstannige ferbettering, gjin ferfanging foar de keatling.

Ynfier, trochstjoeren en NAT beäntwurdzje ferskillende fragen

Ynfierferkear is ornearre foar de host sels, dus dêr wenje de VPN-harker en it administraasjepaad. Trochstjoerferkear giet troch de host, en tunnelklanten hawwe it nedich tegearre mei net.ipv4.ip_forward=1. De klassike heal stikken konfiguraasje lit de útgeande stream ta en ferjit de weromrûte, sadat de klient syn hânskodding foltôget en der dêrnei neat laden wurdt; in conntrack-regel foar fêstige en besibbe ferkear dekt dy rjochting.

NAT is de tredde fraach. Sûnder oerskriuwing yn postrouting geane trochstjoerde pakketten fuort mei de partikuliere boarne fan de tunnel en wurde se boppe streamen weilitten, om’t gjin netwurk bûten de host wit hoe’t it pool werom rûte moat. It boarneprefiks yn dy regel moat by it VPN-pool passe, net by it eigen adres fan de host, en itselde jildt foar de trochstjoerregel dy’t it kliïntsubnet neamt.

IPv6 is in twadde belied, gjin neitins. In host mei in strange IPv4-keatling en in iepen belied op ip6tables hat neat sletten; de tsjinsten binne noch berikber oer de oare famylje. Of spegelje de regelset mei ip6tables, of skakel IPv6 bewust út op de iepenbiere ynterface, en skriuw op hokker fan beiden jo keazen hawwe.

In basisline dy’t jo yn ien pass lêze kinne

Begjin mei wegerje en foegje dêrnei allinnich ta wat de host nedich hat. Earst loopback en antwurden, dan it administraasjepaad, dan de tunnelharker, dan it trochstjoerbelied foar klanten:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

De ynterfacenammen, de poarte en it pool binne plakhâlders; lês se fan de tsjinner ynstee fan se te kopiearjen. It resultaat bewarje is like wichtich as it skriuwen, om’t in regelset dy’t allinnich yn it ûnthâld libbet by de folgjende werstart ferdwynt en de host stil wer iepenet. Meitsje it duorsum mei it meganisme fan de distribúsje, en hâld in kopy bûten de masine foar de dei dat de masine net opstartet.

De lêste poarte slute sûnder de host te ferliezen

Der sit in heak oan it ûntwerp. As SSH allinnich troch de tunnel bestiet, nimt in mislearre VPN-tsjinst SSH mei, en it iennige paad werom is miskien in konsôle dy’t jo nea iepene hawwe. Foardat jo de lêste iepenbiere poarte slute, befêstigje dat dy konsôle bestiet en dat jo har echt brûke kinne, of hâld ien smel administraasjepaad dat net fan de tunnel ôfhinklik is: SSH fan in fêst adres, allinnich kaaien, wachtwurdautentikaasje út.

Pas de wiziging ta fanút in sesje dy’t al fêstige is, net troch de ferbining dy’t jo op it punt steane te filterjen. Plan in weromdraaiing sadat in flater ferrint ynstee fan permanint te wurden, bygelyks in systemd-run --on-active=10min-taak dy’t de foarige regelset werstelt, en hâld in twadde SSH-sesje iepen wylst jo de earste test. Kontrolearje dêrnei dat de weromdraaiingstaak echt ôfgiet, want net testen werstel is itselde as gjin werstel.

Kontrolearje it paad, net it skript

Lês de laden regels, net it bestân dat se lade moatte soe. Fan in autorisearre eksterne host, befêstigje dat allinnich de bedoelde poarten antwurdzje; fan binnen de tunnel, befêstigje dat de tsjinsten dy’t jo publisearje woene berikber binne. In standertwegerjend belied dat ek tunnelferkear blokkearret, liket identyk oan in wurkjende ôfsluting oant immen besiket it te brûken.

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

Skriuw de tastiene poarte, it klantpool, de tunnelinterface, de administratieve boarne en de konsôleproseduere njonken de konfiguraasje. De folgjende wiziging yn it pool of de ynterfacename moat yn sawol de filter as de NAT-regel bylâns, oars giet de host werom nei in healiepen steat sûnder dat immen it merkt.

Ien gewoante is mear wurdich as de regelset: bewiis nei elke wiziging it trochstjoerpaad mei in klantfersyk en it werstelpaad mei in twadde sesje. In ôfsluting dy’t jo net brûkt hawwe, is in hypoteze.