VPS-brannmur: opne berre VPN-porten, og prov det etterpå

Ein brannmur som berre slepp inn VPN-porten, er ikkje éi regelen. Det er tre skilde avgjerder som tilfeldigvis gjeld same portnummer: inngangskjeda avgjer kva som kan nå ein lokal prosess, vidaresendingskjeda avgjer kva som kan passere gjennom verten på vegner av tunnelklientar, og NAT-tabellen skriv om kjeldeadressa på veg ut. Tek du feil på éi av dei, er resultatet sjeldan eit reint avbrot. Du får ein vert som tek imot klientar, men ikkje lastar noko, eller ein vert som ser stengd ut heilt til nokon les rekkjefølgja i kjedene.

Den einaste porten som ikkje kan stengjast

VPN-lyttaren må ta imot tilkoplingar frå adresser du ikkje kan føreseie, og er derfor ein offentleg teneste per definisjon. Dette er det einaste unntaket designet er bygt rundt: éin UDP-port for OpenVPN, éin UDP-port for WireGuard, éin TCP-port for ein SSL VPN. Alt anna høyrer til bak tunnelen, noko som tyder at applikasjonstenester bør binde seg til tunneladressa eller til loopback i staden for til alle grensesnitt.

Binding er likevel ikkje handheving. Ein prosess bunden til 0.0.0.0 er berre tilgjengeleg viss ei regel slepp han inn, og standardpolicyen er reservevegen for trafikk som ingen regel matcha, ikkje regelen som styrer porten. Ein accept plassert over din drop er framleis ein accept, og å flytte ei teneste bort frå den offentlege adressa er ei sjølvstendig betring, ikkje ein erstatning for kjeda.

Inngang, vidaresending og NAT svarar på ulike spørsmål

Inngåande trafikk er adressert til verten sjølv, så det er der VPN-lyttaren og den administrative vegen bur. Vidaresendingstrafikk passerer gjennom verten, og tunnelklientar treng han i tillegg til net.ipv4.ip_forward=1. Den klassiske halvt øydelagde konfigurasjonen tillèt den utgåande straumen og gløymer returretninga, så klienten fullfører handtrykket og deretter blir ingenting lasta; ei conntrack-regel for etablert og relatert trafikk dekkjer den retninga.

NAT er det tredje spørsmålet. Utan omskriving i postrouting forlèt vidaresende pakkar verten med den private kjelda til tunnelen og blir droppa lenger oppe, fordi ingen nettverk utanfor verten veit korleis poolen skal rutast tilbake. Kjelde-prefikset i den regelen må samsvare med VPN-poolen, ikkje med verten si eiga adresse, og det same gjeld vidaresendingsregelen som namngjev klientnettet.

IPv6 er ein andre policy, ikkje ein ettertanke. Ein vert med streng IPv4-kjede og open policy på ip6tables har ikkje stengt noko; tenestene er framleis tilgjengelege over den andre familien. Anten speglar du regelsettet med ip6tables, eller så deaktiverer du IPv6 med vilje på det offentlege grensesnittet, og skriv ned kva du valde.

Ei grunnlinje du kan lese i éin gjennomgang

Start med drop, og legg deretter berre til det verten treng. Fyrst loopback og svar, deretter den administrative vegen, deretter tunnel-lyttaren, deretter vidaresendingspolicyen for klientar:

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

Grensesnittnamna, porten og poolen er plasshaldarar; les dei frå tenaren i staden for å kopiere dei. Å lagre resultatet er like viktig som å skrive det, for eit regelsett som berre lever i minnet, forsvinn ved neste omstart og opnar verten stille igjen. Gjer det varig med mekanismen til distribusjonen, og hald ein kopi utanfor maskina for den dagen maskina ikkje vil starte.

Stengje den siste porten utan å miste verten

Det er ein hake i designet. Viss SSH berre finst gjennom tunnelen, tek ein mislukka VPN-teneste SSH med seg, og den einaste vegen tilbake kan vere ein konsoll du aldri har opna. Før du stengjer den siste offentlege porten, stadfest at den konsollen finst og at du faktisk kan bruke han, eller hald éin smal administrativ veg som ikkje er avhengig av tunnelen: SSH frå ei fast adresse, berre nøklar, passordautentisering av.

Bruk endringa frå ein økt som allereie er etablert, ikkje gjennom tilkoplinga du er i ferd med å filtrere. Planlegg ein tilbakerulling slik at ein feil går ut på tid i staden for å bli permanent, til dømes ein systemd-run --on-active=10min-jobb som gjenopprettar førre regelsett, og hald ei andre SSH-økt open medan du testar den fyrste. Kontroller deretter at tilbakerullingsjobben faktisk løyser ut, for utesta gjenoppretting er det same som inga gjenoppretting.

Stadfest vegen, ikkje skriptet

Les dei lasta reglane, ikkje fila som skulle laste dei. Frå ein autorisert ekstern vert, stadfest at berre dei tiltenkte portane svarar; frå innsida av tunnelen, stadfest at tenestene du ville publisere er tilgjengelege. Ein standard-avvisningspolicy som òg blokkerer tunneltrafikk, ser identisk ut med ei fungerande nedlåsing heilt til nokon prøver å bruke ho.

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

Noter den tillatne porten, klientpoolen, tunnelgrensesnittet, den administrative kjelda og konsollprosedyren ved sida av konfigurasjonen. Den neste endringa i poolen eller grensesnittnamnet må følgjast opp både i filteret og i NAT-regelen, elles går verten tilbake til ein halvopen tilstand utan at nokon merkar det.

Éin vane er verdt meir enn regelsettet: etter kvar endring, prov vidaresendingsvegen med ein klientførespurnad og gjenopprettingsvegen med ei andre økt. Ei nedlåsing du ikkje har brukt, er ein hypotese.