VPS-vuurmuur: stel net die VPN-poort oop en bewys dit dan

’n Vuurmuur wat net die VPN-poort toelaat, is nie een reël nie. Dit is drie afsonderlike besluite wat toevallig dieselfde poortnommer raak: die invoerketting besluit wat ’n plaaslike proses mag bereik, die aanstuurketting besluit wat namens tonnelkliënte deur die gasheer mag gaan, en die NAT-tabel herskryf die bronadres op pad uit. Kry een daarvan verkeerd en die uitslag is selde ’n skoon onderbreking. Jy kry ’n gasheer wat kliënte aanvaar maar niks laai nie, of ’n gasheer wat toegesluit lyk tot iemand die kettingorde lees.

Die een poort wat nie toegemaak kan word nie

Die VPN-luisteraar moet verbindings van adresse aanvaar wat jy nie kan voorspel nie, dus is dit per definisie ’n publieke diens. Dit is die enkele uitsondering waarop die ontwerp gebou is: een UDP-poort vir OpenVPN, een UDP-poort vir WireGuard, een TCP-poort vir ’n SSL VPN. Alles anders hoort agter die tonnel, wat beteken toepassingsdienste moet aan die tonneladres of aan loopback bind, nie aan elke koppelvlak nie.

Binding is egter nie afdwinging nie. ’n Proses wat aan 0.0.0.0 bind, is net bereikbaar as ’n reël dit toelaat, en die verstekbeleid is die terugval vir verkeer wat geen reël gepas het nie, nie die reël wat die poort beheer nie. ’n Toelaat wat bo jou weier geplaas is, bly ’n toelaat, en om ’n diens van die publieke adres af te skuif is ’n onafhanklike verbetering eerder as ’n plaasvervanger vir die ketting.

Invoer, aanstuur en NAT antwoord verskillende vrae

Invoerverkeer is na die gasheer self gerig, dus is dit waar die VPN-luisteraar en die administratiewe pad woon. Aanstuurverkeer gaan deur die gasheer, en tonnelkliënte het dit nodig plus net.ipv4.ip_forward=1. Die klassieke halfgebroke opset laat die uitgaande vloei toe en vergeet die terugrigting, so die kliënt voltooi sy handdruk en dan laai niks; ’n conntrack-reël vir gevestigde en verwante verkeer dek daardie rigting.

NAT is die derde vraag. Sonder ’n postrouting-herskrywing verlaat aanstuurpakette die gasheer met die privaat tonnelbron en word stroomop laat val, want geen netwerk verby die gasheer weet hoe om die poel terug te roeteer nie. Die bronvoorvoegsel in daardie reël moet by die VPN-poel pas, nie by die gasheer se eie adres nie, en dieselfde geld die aanstuur-reël wat die kliëntsubnet noem.

IPv6 is ’n tweede beleid, nie ’n nagedagte nie. ’n Gasheer met ’n streng IPv4-ketting en ’n oop ip6tables-beleid het niks toegemaak nie; die dienste is steeds oor die ander familie bereikbaar. Weerspieël die reëlstel met ip6tables of skakel IPv6 doelbewus op die publieke koppelvlak af, en skryf neer watter een jy gekies het.

’n Basislyn wat jy in een lees kan snap

Begin by drop en voeg dan net by wat die gasheer nodig het. Eers loopback en antwoorde, dan die administratiewe pad, dan die tonnellaaier, dan die aanstuurbeleid vir kliënte:

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

Die koppelvlakname, die poort en die poel is plekhouers; lees hulle uit die bediener eerder as om hulle te kopieer. Om die resultaat te stoor is net so belangrik soos om dit te skryf, want ’n reëlstel wat net in geheue leef, verdwyn by die volgende herbegin en heropen die gasheer stil-stil. Maak dit met die distribusie se meganisme volhoubaar, en hou ’n kopie buite die masjien vir die dag wanneer die masjien nie wil boot nie.

Die laaste poort toemaak sonder om die gasheer te verloor

Daar is ’n vangplek in die ontwerp. As SSH net deur die tonnel bestaan, neem ’n mislukte VPN-diens SSH saam, en die enigste pad terug is dalk ’n konsole wat jy nog nooit oopgemaak het nie. Voordat jy die laaste publieke poort toemaak, bevestig dat daardie konsole bestaan en dat jy dit werklik kan gebruik, of hou een smal administratiewe pad wat nie van die tonnel afhang nie: SSH vanaf ’n vaste adres, net sleutels, wagwoordverifikasie af.

Pas die verandering toe vanuit ’n sessie wat al gevestig is, nie deur die verbinding wat jy op die punt is om te filtreer nie. Beplan ’n terugrol sodat ’n fout verval eerder as om permanent te word, byvoorbeeld ’n systemd-run --on-active=10min-taak wat die vorige reëlstel herstel, en hou ’n tweede SSH-sessie oop terwyl jy die eerste toets. Verifieer dan dat die terugroltaak werklik vuur, want ongetoetste herstel is dieselfde as geen herstel nie.

Verifieer die pad, nie die skrip nie

Lees die gelaaide reëls, nie die lêer wat hulle veronderstel was om te laai nie. Vanaf ’n gemagtigde eksterne gasheer, bevestig dat net die bedoelde poorte antwoord; van binne die tonnel, bevestig dat die dienste wat jy wou publiseer bereikbaar is. ’n Beleid wat by verstek weier en ook tonnelverkeer blokkeer, lyk identies aan ’n werkende toesluiting totdat iemand dit probeer gebruik.

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

Teken die toegelate poort, die kliëntpoel, die tonnelkoppelvlak, die administratiewe bron en die konsole-prosedure langs die konfigurasie aan. Die volgende verandering aan die poel of die koppelvlaknaam moet in beide die filter en die NAT-reël pas, anders keer die gasheer terug na ’n halfoop toestand sonder dat iemand dit agterkom.

Een gewoonte is meer werd as die reëlstel: na elke verandering, bewys die aanstuurpad met ’n kliëntversoek en bewys die herstelpad met ’n tweede sessie. ’n Toesluiting wat jy nog nooit gebruik het nie, is ’n hipotese.