iptables: lasu VPN-klientojn atingi nur unu gastigan komputilon

La regulo, kiun vi bezonas, estas en FORWARD, ne en INPUT. Permesu unu celon por la VPN-poolo, rifuzu la reston, kaj poste pruvu tion per nombriloj kaj restariga komando.

Du subtenaj biletoj, kiuj ŝajnas senrilataj, montriĝas havi unu kaŭzon. En la unua administranto volas, ke la servilo akceptu konektojn nur el la tunelo; en la dua la uzantoj de VPN devus atingi unu internan gastigan komputilon kaj nenion pli. Ambaŭ politikoj apartenas al FORWARD, kaj ambaŭ kutime proviĝas en INPUT. La rezulto aspektas kiel fajroŝirmilo kaj kondutas kiel anstataŭigilo.

Kiu ĉeno respondas vian demandon

Paketojn, kiujn VPN-kliento sendas al gastiga komputilo en la LAN aŭ plu al la interreto, la kerno plusendas kaj taksas en FORWARD. INPUT kaj OUTPUT vidas nur trafikon, kiu finiĝas ĉe la servilo mem aŭ originas de ĝi. Rifuzo por io ajn, kio ne alvenas sur tun0, do protektas la proprajn aŭskultantojn de la servilo, kaj ĝi ankaŭ finos vian SSH-sesion, se starigitaj fluoj ne estas unue permesitaj. Ĝi ŝanĝas nenion pri tio, kien klientoj rajtas iri.

Unue nomu la demandon: kiu rajtas atingi la servilon, aŭ kien klientoj rajtas iri. Plej multaj retoj bezonas ambaŭ respondojn, en malsamaj ĉenoj.

Unue la stato, poste la permeso, poste la rifuzo

Permeslisto funkcias nur se la specifa permeso staras super la ĝenerala rifuzo kaj se revena trafiko estas permesita super ambaŭ. Enŝovu regulojn ĉe eksplicitaj pozicioj, poste eligu la ĉenon per iptables -S FORWARD, por ke la ordo estu videbla anstataŭ supozita.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Du detaloj decidas, ĉu tio postvivos kontakton kun reala trafiko. Sen la stata regulo, respondoj al la konektoj, kiujn vi ĵus permesis, mem estas taksataj kontraŭ la rifuzo kaj forĵetataj. Regulo LOG sen limigo povas elĉerpi malgrandan dividaĵon la unuan fojon, kiam skanado trafas ĝin, do aldonu -m limit --limit 10/min antaŭ ol daŭrigi protokoladon. REJECT redonas eraron tuj, kio estas pli amika dum vi agordas la liston; DROP forĵetas silente, do ĉiu eraro prezentiĝas kiel tempolimo. Elektu unu intence kaj skribu la elekton en la ŝanĝprotokolo.

Plusendado kaj NAT jam devas funkcii

Filtrado ne povas pruvi, ke vojo ekzistas. Unue konfirmu, ke la kerno entute plusendas, kaj faru tiun agordon daŭra anstataŭ unufoja ŝela komando. La filtrilo estas la lasta tavolo, ne la unua.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Kie maskado apartenas dependas de tio, kie klientoj eliras. Se ili eliras tra la tunelo al fora reto, la regulo NAT iras sur tiun interfacon anstataŭ sur la WAN-interfacon. Poste rigardu la nombrilojn: se la nombrilo POSTROUTING neniam moviĝas dum la nombro de akceptoj en FORWARD kreskas, la revena vojo estas rompita kaj la filtrilo estas en ordo. Tiu legado ŝparas posttagmezon da reverkado de reguloj, kiuj neniam estis la problemo.

La retpoŝta bloko apartenas unu ĉenon pli fore

Bloki pordon 25 en INPUT haltigas nur retpoŝton adresitan al la VPN-servilo. Kompromitita kliento, kiu sendas retpoŝton tra la tunelo, estas plusendata, do la bloko devas sidi en FORWARD apud 465 kaj 587. Se unu aplikaĵo laŭleĝe plusendas retpoŝton, metu ĝian celon kaj pordon super tiu regulo.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Lasu la rifuzan nombrilon funkcii semajnon antaŭ ol streĉi ion alian. La nombro, kiu ĉesas grimpi, estas la laŭleĝa fluo, kiun vi ĵus rompis.

Legi ĝin reen, poste pruvu ĝin de kliento

Legu la regulan aron tiel, kiel la kerno raportas ĝin, ne tiel, kiel via skripto skribis ĝin. Komencu per iptables -S FORWARD, poste la NAT-tabelo per iptables -t nat -L POSTROUTING -n -v, poste la conntrack-enskribo por la fluo, kiun vi testas. Tenu restarigan komandon aŭ planitan malplenigon dum la laboro daŭras. Ĉiu voko bezonas -w, alie du administrantoj kolizios ĉe la xtables-seruro. Nenio el tio estas laŭvola dum ŝanĝfenestro.

Finu per testado de kliento ene de la poolo kaj de unu ekster ĝi. Regulo, kiu funkcias nur de la maŝino, sur kiu vi tajpis ĝin, ne estas politiko.

Rilataj artikoloj