Twee ondersteuningskaartjies wat onverwant lyk, blyk een oorsaak te deel. In die eerste wil ’n administrateur hê die bediener moet verbindings net van die tonnel aanvaar; in die tweede moet VPN-gebruikers ’n enkele interne gasheer bereik en niks meer nie. Albei beleide hoort in FORWARD, en albei word gewoonlik in INPUT probeer. Die resultaat lyk soos ’n vuurmuur en gedra hom soos ’n plekhouer.

Watter ketting beantwoord jou vraag

Pakette wat ’n VPN-kliënt na ’n LAN-gasheer stuur, of verder na die internet, word deur die kern deurgestuur en in FORWARD geëvalueer. INPUT en OUTPUT sien net verkeer wat by die bediener self eindig of daar ontstaan. ’n Verwerping vir enigiets wat nie op tun0 aankom nie, beskerm dus die bediener se eie luisteraars, en dit sal ook jou SSH-sessie beëindig tensy gevestigde vloei eerste toegelaat word. Dit verander niks aan waarheen kliënte mag gaan nie.

Benoem eers die vraag: wie mag die bediener bereik, of waarheen mag kliënte gaan. Die meeste netwerke het albei antwoorde nodig, in verskillende kettings.

Eers die toestand, dan die toelating, dan die weiering

’n Toelatingslys werk net as die spesifieke toestemming bo die algemene weiering sit, en as terugkeerverkeer bo albei toegelaat word. Voeg reëls op eksplisiete posisies in en gooi dan die ketting uit met iptables -S FORWARD sodat die volgorde sigbaar is eerder as aangeneem.

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

Twee besonderhede bepaal of dit die kontak met werklike verkeer oorleef. Sonder die toestandreël word antwoorde op die verbindings wat jy pas toegelaat het, self teen die weiering geëvalueer en laat vaar. ’n Ongebreidelde LOG-reël kan ’n klein partisie uitgeput kry die eerste keer dat ’n skandering dit tref, so voeg -m limit --limit 10/min by voordat jy aanhou log. REJECT gee dadelik ’n fout terug, wat vriendeliker is terwyl jy die lys fyn instel; DROP gooi stilweg weg, so elke fout lyk soos ’n tydsverloop. Kies een doelbewus en skryf die keuse in die veranderingsrekord.

Deurstuur en NAT moet reeds werk

Filtering kan nie bewys dat ’n pad bestaan nie. Bevestig eers dat die kern hoegenaamd deurstuur, en maak daardie instelling blywend eerder as ’n eenmalige skrip. Die filter is die laaste laag, nie die eerste nie.

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

Waar die maskerade hoort, hang af van waar kliënte uitgaan. As hulle deur die tonnel na ’n afgeleë netwerk vertrek, sit die NAT-reël op daardie koppelvlak eerder as op die WAN-koppelvlak. Kyk dan na die tellers: as die POSTROUTING-teller nooit beweeg terwyl die FORWARD-toelatings telling styg, is die terugpad stukkend en die filter heeltemal reg. Daardie lees spaar ’n middag se herskryf van reëls wat nooit die probleem was nie.

Die e-posblok hoort een ketting verder

Om poort 25 in INPUT te blokkeer, stop net e-pos wat aan die VPN-bediener geadresseer is. ’n Gekomponeerde kliënt wat e-pos deur die tonnel stuur, word deurgestuur, so die blok moet in FORWARD langs 465 en 587 sit. As een toepassing wettig e-pos herlei, sit sy bestemming en poort bo daardie reël.

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

Laat die verwerpingsteller ’n week lank loop voordat jy enigiets anders stywer maak. Die getal wat ophou klim, is die wettige vloei wat jy pas gebreek het.

Lees dit terug en bewys dit dan vanaf ’n kliënt

Lees die reëlstel soos die kern dit rapporteer, nie soos jou skrip dit geskryf het nie. Begin met iptables -S FORWARD, dan die NAT-tabel met iptables -t nat -L POSTROUTING -n -v, dan die conntrack-inskrywing vir die vloei wat jy ondersoek. Hou ’n terugrolopdrag of ’n geskeduleerde spoeling solank die werk duur. Elke aanroep het -w nodig, anders bots twee administrateurs op die xtables-slot. Niks daarvan is opsioneel tydens ’n veranderingsvenster nie.

Eindig deur te toets vanaf ’n kliënt binne die poel en vanaf een daarbuite. ’n Reël wat net werk vanaf die masjien waarop jy dit getik het, is nie ’n beleid nie.

Verwante artikels