VPS-Firewall: nëmmen de VPN-Port opmaachen an et du bewäisen

Eng Firewall, déi nëmmen de VPN-Port erlaabt, ass net eng eenzeg Regel. Et sinn dräi getrennt Entscheedungen, déi zoufälleg déiselwecht Portnummer betreffen: d’Input-Kette entscheet, wat e lokale Prozess erreeche kann, d’Weiderleedungs-Kette entscheet, wat am Numm vun den Tunnel-Cliente duerch den Host geet, an d’NAT-Tabell schreift d’Quelladress um Wee eraus ëm. Fänkt een dovunner uenech, ass d’Resultat selten en properen Ausfall. Dir kritt en Host, dee Cliente akzeptéiert, awer näischt lued, oder en Host, deen zou ausgesäit, bis een d’Uerdnung vun de Kette liest.

Den eenzege Port, deen net ka zougemaach ginn

Den VPN-Listener muss Verbindunge vun Adressen unhuelen, déi Dir net kënnt viraussoen, also ass en per Definitioun en ëffentlechen Déngscht. Dat ass déi eenzeg Ausnam, vun där d’Design ausgeet: een UDP-Port fir OpenVPN, een UDP-Port fir WireGuard, een TCP-Port fir eng SSL VPN. Alles anescht gehéiert hannert den Tunnel, dat heescht, d’Uwendungsdéngschter solle sech un d’Tunneladress oder u loopback binden an net un all Schnëttstell.

Binden ass awer keng Duerchsetzung. E Prozess, deen un 0.0.0.0 gebonnen ass, ass nëmmen erreechbar, wann eng Regel e duerchléisst, an d’Standardpolitik ass de Réckfall fir Verkéier, op dee keng Regel gepasst huet, net d’Regel, déi de Port dirigéiert. En Accept iwwer Ärem Drop bleift en Accept, an e Service vun der ëffentlecher Adress ewech ze huelen ass eng onofängeg Verbesserung an net en Ersatz fir d’Kette.

Input, Weiderleedung an NAT äntwerten op verschidde Froen

Input-Verkéier ass un den Host selwer adresséiert, do wunnen also den VPN-Listener an de Verwaltungswee. Weiderleedungsverkéier geet duerch den Host, an d’Tunnel-Cliente brauchen en zousätzlech zu net.ipv4.ip_forward=1. Déi klassesch hallef futti Konfiguratioun erlaabt de erausgehende Floss a vergësst d’Réckrichtung, sou datt de Client säin Handshake fäerdeg mécht an duerno näischt lued; eng Conntrack-Regel fir etabléierten a verbonne Verkéier deckt déi Richtung of.

NAT ass déi drëtt Fro. Ouni Ëmschreiwung am Postrouting verloossen weidergeleet Paketen den Host mat der privater Tunnelquell a ginn uewendriwwer verworf, well keen Netzwierk hannert dem Host weess, wéi de Pool zréck gerout gëtt. De Quellpräfix an där Regel muss zum VPN-Pool passen, net zu der Host senger eegener Adress, an datselwecht gëllt fir d’Weiderleedungsregel, déi den Client-Subnet nenneet.

IPv6 ass eng zweet Politik, kee spéideren Awand. En Host mat enger strenge IPv4-Kette an enger oppener ip6tables-Politik huet näischt zougemaach; d’Déngschter sinn iwwer déi aner Famill nach erreechbar. Entweder spiegelt Dir de Reegelsatz mat ip6tables oder Dir deaktivéiert IPv6 bewosst op der ëffentlecher Schnëttstell, a schreift op, wat Dir gewielt hutt.

Eng Basis, déi een an engem Passage liest

Fänkt mam Drop un a füügt du just derbäi, wat den Host brauch. Fir d’éischt loopback an Äntwerten, duerno de Verwaltungswee, duerno den Tunnel-Listener, duerno d’Weiderleedungspolitik fir d’Clienten:

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

D’Schnëttstellnimm, de Port an de Pool si Plazhalter; liest se vum Server, amplaz se ze kopéieren. D’Resultat ze späichere ass esou wichteg wéi et ze schreiwen, well e Reegelsatz, deen nëmmen am Späicher lieft, beim nächsten Neistart verschwënnt an den Host stëll erëm opmécht. Maacht en duerch de Mechanismus vun der Distributioun permanant a haalt eng Kopie baussent der Maschinn fir den Dag, wou d’Maschinn net start.

De leschten ëffentleche Port zoumaachen ouni den Host ze verléieren

Am Design ass eng Falle. Wann SSH nëmmen duerch den Tunnel existéiert, hëlt en ausgefallene VPN-Déngscht SSH mat, an deen eenzegen Hanneschtwee kann eng Konsole sinn, déi Dir ni opgemaach hutt. Ier Dir de leschten ëffentleche Port zoumaacht, bestätegt, datt déi Konsole existéiert an datt Dir se wierklech benotze kënnt, oder haalt ee schmuele Verwaltungswee op, deen net vum Tunnel ofhänkt: SSH vun enger fixer Adress, nëmme Schlësselen, Passwuert-Authentifikatioun aus.

Wend d’Ännerung aus enger Sessioun un, déi schonn etabléiert ass, net duerch d’Verbindung, déi Dir just wëllt filteren. Plangt e Rollback, sou datt e Feeler ofleeft, amplaz permanent ze ginn, zum Beispill en systemd-run --on-active=10min-Job, deen de fréiere Reegelsatz restauréiert, a haalt eng zweet SSH-Sessioun op, während Dir déi éischt testt. Duerno verifizéiert, datt de Rollback-Job wierklech ausléist, well eng ongetest Erhuelung datselwecht ass wéi keng Erhuelung.

Verifizéiert de Wee, net de Skript

Liest déi geluede Reegelen, net d’Datei, déi se hätt solle lueden. Vun engem autoriséierten externen Host bestätegt Dir, datt nëmmen déi virgesinn Porten äntwerten; vun bannen am Tunnel bestätegt Dir, datt d’Déngschter, déi Dir wëllt publizéieren, erreechbar sinn. Eng Standard-Deny-Politik, déi och den Tunnelverkéier blockéiert, gesäit genau esou aus wéi eng funktionéierend Spär, bis een se probéiert ze benotzen.

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

Notéiert den erlaabte Port, de Client-Pool, d’Tunnel-Schnëttstell, d’Verwaltungsquell an de Konsole-Prozedur nieft der Konfiguratioun. Déi nächst Ännerung um Pool oder um Schnëttstellnumm muss am Filter an an der NAT-Regel passen, soss geet den Host an en hallef oppenen Zoustand zréck, ouni datt et een mierkt.

Eng Gewunnecht ass méi wäert wéi de Reegelsatz: no all Ännerung bewäist Dir de Weiderleedungswee mat enger Client-Ufro an den Erhuelungswee mat enger zweeter Sessioun. Eng Spär, déi Dir net benotzt hutt, ass eng Hypothees.