iptables-host allinne mei VPN: neam it tun-apparaat, net tun+

It skriuwen fan -o tun+ fielt as in krekte oanwizing en is eins in wildcard oer elke tunnel dy't de kernel hat. In twadde VPN-klant, in containerbrêge of in ynterface dy't troch in ferûngemakke sesje efterlitten is, foldogge der allegear oan, en dan lit de host ferkear troch dat it belied bedoelde te foarkommen. De proseduere hjirûnder fêstiget ien apparaatnamme, oardersket de útsûnderingen sa't de tunnel wier foarmje kin, en lit jo in paad werom as de regels ferkeard falle. Eltse stap is koart genôch om apart werom te draaien.

Stap 1: skriuw de regels op dy't jo no hawwe

Foardat jo in standertbelied feroarje, bewarje de hjoeddeistige tastân sadat it weromdraaien in opdracht is en gjin oantins. iptables-save > /root/iptables.pre skriuwt elke tabel nei in bestân dat jo werstelle kinne, en in twadde terminal mei in iepen root-sesje is gjin paranoia as it belied dat jo op it punt steane yn te stellen de ferbining docht dy't it draacht. As jo op ôfstân wurkje, plen dan ek in flush as needstop.

Lis dan de ynterfaces op, want in namme dy't jo oannommen hawwe is in namme dy't jo lêze moatten hiene: ip -br link lit sjen wat der no is, en de tunnel ferskynt net oant er omheech is. Skriuw de apparaatnammen op wylst jo se lêze.

Stap 2: jou de tunnel syn eigen namme

OpenVPN akseptearret dev tun_work yn 'e klantkonfiguraasje, en Linux makket dan in ynterface mei krekt dy namme ynstee fan tun0 ta te wizen. De namme bliuwt stabyl oer werferbiningen hinne salang't neat oars der oanspraak op makket, en dat is wat in regel dy't it apparaat neamt betsjuttingsfol makket.

Dêr't de namme net kontrolearre wurde kin, matchje dan op it tunneladres of in pakketmark. Beide wurkje, beide binne hurder te lêzen en beide mislearje stiller as de tunnel opnij nûmeret. Matchje yn alle gefallen ien ding en wês dúdlik hokker.

Stap 3: skriuw it belied mei de endpoint-útsûndering foarop

In host allinne mei VPN is in host mei standertwegering en in koarte útsûnderingslist, en de útsûndering dy't it meast ta docht is dy't de tunnel bestean litte. Bou it yn dizze oarder, mei de endpoint-regel foar de tunnelapparaatregel, sadat de hânskûd earne hinne kin:

# 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

It letterlike endpointadres en de poarte binne fan jo provider, net fan dizze side. As it endpoint in hostnamme is, los it dan ien kear op en fêstigje it resultaat, want in regel kin gjin namme opsykje en in draaiend antwurd sil it belied stil brekke nei de folgjende DNS-feroaring. Kontrolearje ek de poarte, want providers dy't jo nei TCP 443 ferpleatse sille oars in regel nedich hawwe dy't nimmen opskreaun hat. In tunnel dy't allinne op ien protokol wurket is meastentiids dizze weglitting en net in flater fan 'e firewall.

Op in router giet deselde foarm yn 'e FORWARD-ketting foar de klanten der efter, en it eigen ferkear fan 'e router hat eigen regels nedich. In regelset dy't allinne trochstjoerde pakketten dekt lit SSH en DNS op it âlde paad, en sa wurdt in router ûnberikber op it stuit dat de tunnel omheech komt.

Stap 4: kontrolearje de oarder, net allinne it bestean

Regels wurde op folchoarder beoardiele, dus in ACCEPT dy't earder komt ferberget gewoan de REJECT dy't jo dernei tafoege hawwe. De established- en related-match is wat antwurden op jo eigen útgeande oanfragen weromkomme lit sûnder in algemien yngeand paad te iepenjen, en it efter de tunnelakseptaasje pleatsen betsjut dat in fallen tunnel noch weromferkear op syn eigen ynterface trochlitten.

Hâld it oantal regels lyts genôch om op ien skerm te lêzen. In regelset dy't jo net auditsje kinne is ien dy't jo pleisterje sille troch útsûnderingen boppe-oan ta te foegjen, en sa krije standertwegeringsbelied stadichoan in standerttalittingsrâne. Tel de ACCEPT's foar en nei de feroaring.

Stap 5: meitsje dat it de opstart en de adresfamylje oerlibbet

Regels dy't mei de hân ynfierd binne ferdwine by werstart, dus laad se út 'e firewalltsjinst fan 'e distribúsje of út in unit dy't rint nei't it tunnel-ynterface bestiet. Ferwizen nei tun_work yn in skript dat draait foardat OpenVPN begjint is in gewoane manier om in opstartlus fan fallen ferkear te meitsjen.

Kontrolearje dan IPv6 apart, want in goed standertwegeringsbelied foar IPv4 seit neat oer de oare famylje. ip -6 route sil jo fertelle oft de host in rûte hat dy't ferkear om in tunnel hinne drage kin dy't allinne IPv4 oan kin, en ip6tables of nftables hat syn eigen lykweardige regels nedich. Test mei in IPv6-only-bestimming ynstee fan op 'e symmetry fan 'e regelset te fertrouwen.

Stap 6: ferifiearje en wês klear om wer te stellen

Bring de tunnel omheech, befêstigje dat de bedoelde tsjinst wurket, en besykje dan wat it belied wegerje moat. Werstel mei iptables-restore < /root/iptables.pre as it antwurd jo ferrast, en begjin dan pas regels te bewurkjen. Duorsumens plus in testen werstelpaad is wat dit in feroaring makket dy't jo twa kear meitsje kinne.