Eldveggur sem hleypir aðeins VPN-gáttinni inn er ekki ein regla. Þetta eru þrjár aðskildar ákvarðanir sem varða fyrir tilviljun sama gáttarnúmer: inntakskeðjan ræður því hvað getur náð til staðbundins ferlis, framsendingarkeðjan ræður því hvað getur farið í gegnum hýsilinn fyrir hönd biðlara göngunnar, og NAT-taflan endurskrifar upprunafangið á leið út. Ef þú klikkar á einni þeirra er niðurstaðan sjaldan hrein bilun. Þú færð hýsil sem tekur við biðlarum en hleður engu, eða hýsil sem virðist lokaður þar til einhver les röð keðjanna.

Eina gáttin sem ekki er hægt að loka

VPN-hlustaranum verður að taka við tengingum frá föngum sem þú getur ekki séð fyrir, svo hún er opinber þjónusta samkvæmt skilgreiningu. Þetta er eina undantekningin sem hönnunin er byggð á: ein UDP-gátt fyrir OpenVPN, ein UDP-gátt fyrir WireGuard, ein TCP-gátt fyrir SSL VPN. Allt annað tilheyrir bak við gönguna, sem þýðir að forritarþjónustur ættu að binda sig viðfang göngunnar eða loopback, ekki hvert netviðmót.

Binding er þó ekki framfylgd. Ferli sem er bundið við 0.0.0.0 er aðeins aðgengilegt ef regla hleypir því í gegn, og sjálfgefna stefnan er varaleiðin fyrir umferð sem engin regla passaði við, ekki reglan sem stjórnar gáttinni. Samþykki sem sett er yfir höfnunina þína er enn samþykki, og að flytja þjónustu af opinberu fanginu er sjálfstæð endurbót, ekki staðgengill fyrir keðjuna.

Inntak, framsending og NAT svara mismunandi spurningum

Inntaksumferð er ætluð hýslinum sjálfum, svo þar búa VPN-hlustarinn og stjórnunarleiðin. Framsendingarumferð fer í gegnum hýsilinn, og biðlarar göngunnar þurfa hana ásamt net.ipv4.ip_forward=1. Klassíska hálfbrotið stillingin leyfir útstreymið og gleymir afturleiðinni, svo biðlarinn klárar handabandið og svo hleðst ekkert; conntrack-regla fyrir komna og tengda umferð nær yfir þá átt.

NAT er þriðja spurningin. Án endurskrifunar í postrouting fara framsend pakkar út með einkafangi göngunnar og eru felldir ofar, því ekkert net fyrir utan hýsilinn veit hvernig á að beina safninu til baka. Upprunaforskeytið í þeirri reglu verður að passa við VPN-safnið, ekki eigið fang hýsilsins, og sama gildir um framsendingarregluna sem nefnir undirnet biðlaranna.

IPv6 er önnur stefna, ekki eftirhugsuð hugsun. Hýsill með strangri IPv4-keðju og opinni stefnu á ip6tables hefur ekki lokað neinu; þjónusturnar eru enn aðgengilegar um hina fjölskylduna. Annað hvort speglaðu reglusafnið með ip6tables eða slökktu viljandi á IPv6 á opinbera viðmótinu, og skrifaðu niður hvort þú valdir.

Grunnlína sem lesin er í einni yfirferð

Byrjaðu á höfnun og bættu svo aðeins við því sem hýsillinn þarf. Fyrst loopback og svör, þá stjórnunarleiðin, þá hlustari göngunnar, þá framsendingarstefnan fyrir biðlara:

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

Viðmótsheiti, gáttin og safnið eru staðgenglar; lestu þau af netþjóninum í stað þess að afrita. Að vista niðurstöðuna skiptir jafn miklu og að skrifa hana, því reglusafn sem lifir aðeins í minni hverfur við næstu endurræsingu og opnar hýsilinn aftur hljóðlega. Gerðu það varanlegt með aðferð dreifingarinnar og hafðu afrit utan vélarinnar fyrir daginn sem vélin ræsist ekki.

Loka síðustu gáttinni án þess að missa hýsilinn

Það er gildra í hönnuninni. Ef SSH er aðeins til í gegnum gönguna tekur misheppnuð VPN-þjónusta SSH með sér, og eina leiðin til baka gæti verið stjórnborð sem þú hefur aldrei opnað. Áður en þú lokar síðustu opinberu gáttinni skaltu staðfesta að það stjórnborð sé til og að þú getir virkilega notað það, eða halda einni þröngri stjórnunarleið sem er ekki háð göngunni: SSH frá föstu fangi, aðeins lyklar, lykilorðaaðgangur óvirkur.

Beittu breytingunni úr þegar stofnuðu setu, ekki í gegnum tenginguna sem þú ert að fara að sía. Tímasettu afturköllun svo mistök renni út í stað þess að verða varanleg, til dæmis systemd-run --on-active=10min verk sem endurheimtir fyrra reglusafn, og hafðu aðra SSH-setu opna meðan þú prófar þá fyrstu. Staðfestu svo að afturköllunarverkið starti í raun, því óprófuð endurheimt er það sama og engin endurheimt.

Staðfestu leiðina, ekki skriftuna

Lestu hlaðnar reglur, ekki skrána sem átti að hlaða þeim. Frá heimiluðum utanaðkomandi hýsli, staðfestu að aðeins fyrirhugaðar gáttir svari; innan úr göngunni, staðfestu að þjónusturnar sem þú ætlaðir að birta séu aðgengilegar. Sjálfgefin höfnunarstefna sem lokar líka fyrir umferð göngunnar lítur nákvæmlega eins út og virk læsing þar til einhver reynir að nota hana.

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

Skráðu leyfðu gáttina, safn biðlaranna, viðmót göngunnar, stjórnunarupprunann og ferli stjórnborðsins við hlið stillingarinnar. Næsta breyting á safninu eða viðmótsheitinu verður að stemma í síunni og NAT-reglunni, annars fer hýsillinn aftur í hálfopna stöðu án þess að nokkur taki eftir því.

Ein venja er meira virði en reglusafnið: eftir hverja breytingu skaltu sanna framsendingarleiðina með beiðni frá biðlara og endurkomuleiðina með annarri setu. Læsing sem þú hefur ekki notað er tilgáta.

Tengdir greinar