iptables-gasheer met net VPN: noem die tun-toestel, nie tun+ nie

Om -o tun+ te skryf voel soos ’n presiese opdrag en is in werklikheid ’n wildcard oor elke tonnel wat die kernel het. ’n Tweede VPN-kliënt, ’n houer-brug of ’n koppelvlak wat deur ’n omgestorte sessie agtergelaat is, voldoen almal daaraan, en die gasheer laat dan verkeer deur wat jou beleid bedoel het om te verhoed. Die prosedure hieronder pen een toestelnaam vas, orden die uitsonderings sodat die tonnel werklik kan vorm, en laat jou ’n weg terug as die reëls sleg val. Elke stap is kort genoeg om op sy eie ongedaan te maak.

Stap 1: teken die reëls aan wat jy nou het

Voordat jy ’n verstekbeleid verander, stoor die huidige toestand sodat die terugrol ’n opdrag is eerder as ’n herinnering. iptables-save > /root/iptables.pre skryf elke tabel na ’n lêer wat jy kan herstel, en ’n tweede terminaal met ’n oop root-sessie is nie paranoia nie wanneer die beleid wat jy op die punt is om te stel die verbinding laat val wat dit dra. As jy op afstand werk, skeduleer ook ’n flush as ’n doodbreek-skakelaar.

Lys dan die koppelvlakke, want ’n naam wat jy aangeneem het, is ’n naam wat jy moes gelees het: ip -br link wys wat nou bestaan, en die tonnel sal nie verskyn voordat dit op is nie. Skryf die toestelname neer soos jy dit lees.

Stap 2: gee die tonnel sy eie naam

OpenVPN aanvaar dev tun_work in die kliëntkonfigurasie, en Linux skep dan ’n koppelvlak met presies daardie naam in plaas daarvan om tun0 toe te wys. Die naam bly stabiel oor herverbindings heen solank niks anders dit opeis nie, en dit is wat ’n reël wat die toestel noem betekenisvol maak.

Waar die naam nie beheer kan word nie, pas eerder op die tonneladres of ’n pakkietmerk. Albei werk, albei is moeiliker om te lees, en albei faal stiller wanneer die tonnel hernommer. Maak in elk geval op een ding pas en wees eksplisiet oor watter een.

Stap 3: skryf die beleid met die eindpunt-uitsondering eerste

’n Gasheer met net VPN is ’n gasheer met verstek-weiering en ’n kort uitsonderingslys, en die uitsondering wat die meeste saak maak, is die een wat die tonnel laat bestaan. Bou dit in hierdie orde, met die eindpunt-reël voor die tonneltoestel-reël, sodat die handskud êrens heen kan gaan:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Die letterlike eindpuntadres en -poort behoort aan jou verskaffer, nie aan hierdie bladsy nie. As die eindpunt ’n hostnaam is, los dit een keer op en pen die resultaat vas, want ’n reël kan nie ’n naam opsoek nie en ’n roterende antwoord sal die beleid stilweg breek ná die volgende DNS-verandering. Kyk ook na die poort, want verskaffers wat jou na TCP 443 skuif, sal andersins ’n reël nodig hê wat niemand neergeskryf het nie. ’n Tonnel wat net op een protokol werk, is gewoonlik hierdie weglating eerder as ’n firewall-fout.

Op ’n router gaan dieselfde vorm in die FORWARD-ketting vir die kliënte agter dit, en die router se eie verkeer het sy eie reëls nodig. ’n Reëlstel wat net deurgestuurde pakkette dek, laat SSH en DNS op die ou pad, en dit is hoe ’n router onbereikbaar word die oomblik wanneer die tonnel opkom.

Stap 4: kontroleer die orde, nie net die teenwoordigheid nie

Reëls evalueer in volgorde, so ’n ACCEPT wat vroeër kom, verberg bloot die REJECT wat jy daarna bygevoeg het. Die established- en related-passing is wat antwoorde op jou eie uitgaande versoeke laat terugkeer sonder om ’n algemene inkomende pad oop te maak, en om dit ná die tonnel-aanvaarding te plaas, beteken dat ’n gedropte tonnel steeds terugkeerverkeer op sy eie koppelvlak deurlaat.

Hou die reëlgetal klein genoeg om op een skerm te lees. ’n Reëlstel wat jy nie kan oudit nie, is een wat jy sal pleister deur uitsonderings bo-aan by te voeg, en dit is hoe verstek-weieringsbeleide geleidelik ’n verstek-toelaat-rand kry. Tel die ACCEPT's voor en ná die verandering.

Stap 5: laat dit die selflaai en die adresfamilie oorleef

Reëls wat met die hand ingevoer is, verdwyn by herlaai, so laai hulle uit die verspreiding se firewall-diens of ’n eenheid wat loop nadat die tonnelkoppelvlak bestaan. Om tun_work te verwys in ’n skrip wat uitvoer voordat OpenVPN begin, is ’n algemene manier om ’n selflaai-lus van gedropte verkeer te veroorsaak.

Kontroleer dan IPv6 apart, want ’n goeie IPv4-verstek-weieringsbeleid sê niks oor die ander familie nie. ip -6 route sal jou vertel of die gasheer ’n roete het wat verkeer om ’n tonnel kan dra wat net IPv4 hanteer, en ip6tables of nftables het sy eie ekwivalente reëls nodig. Toets met ’n IPv6-only-bestemming eerder as om die simmetrie van die reëlstel te vertrou.

Stap 6: verifieer en wees gereed om te herstel

Bring die tonnel op, bevestig dat jou beoogde diens werk, en probeer dan iets wat die beleid behoort te weier. Herstel met iptables-restore < /root/iptables.pre as die antwoord jou verras, en begin eers daarna reëls redigeer. Volharding plus ’n getoetsde herstelpad is wat dit ’n verandering maak wat jy twee keer kan maak.