Gazdă iptables doar cu VPN: numiți dispozitivul tun, nu tun+

A scrie -o tun+ pare o instrucțiune precisă și este de fapt un metacaracter care acoperă fiecare tunel pe care îl are nucleul. Un al doilea client VPN, un pod de containere sau o interfață lăsată de o sesiune prăbușită le satisfac pe toate, iar gazda permite apoi trafic pe care politica voia să îl împiedice. Procedura de mai jos fixează un singur nume de dispozitiv, ordonează excepțiile astfel încât tunelul să poată chiar să se formeze și vă lasă o cale de întoarcere dacă regulile ies prost. Fiecare pas este destul de scurt pentru a fi anulat singur.

Pasul 1: notați regulile pe care le aveți acum

Înainte de a schimba o politică implicită, salvați starea curentă astfel încât revenirea să fie o comandă, nu o amintire. iptables-save > /root/iptables.pre scrie fiecare tabel într-un fișier pe care îl puteți restaura, iar un al doilea terminal cu o sesiune root deschisă nu este paranoia când politica pe care urmează să o setați întrerupe conexiunea care o transportă. Dacă lucrați de la distanță, programați și un flush ca întrerupător de siguranță.

Apoi listați interfețele, pentru că un nume pe care l-ați presupus este un nume pe care ar fi trebuit să îl citiți: ip -br link arată ce există chiar acum, iar tunelul nu va apărea până nu este ridicat. Notați numele dispozitivelor pe măsură ce le citiți.

Pasul 2: dați tunelului propriul nume

OpenVPN acceptă dev tun_work în configurația clientului, iar Linux creează atunci o interfață exact cu acel nume în loc să aloce tun0. Numele rămâne stabil între reconectări atât timp cât nimic altceva nu îl revendică, și exact asta face semnificativă o regulă care numește dispozitivul.

Unde numele nu poate fi controlat, potriviți în schimb adresa tunelului sau un marcaj de pachet. Ambele funcționează, ambele sunt mai greu de citit și ambele eșuează mai silențios când tunelul se renumerează. În orice caz, potriviți un singur lucru și spuneți clar care.

Pasul 3: scrieți politica cu excepția pentru endpoint prima

O gazdă doar cu VPN este o gazdă cu refuz implicit și o listă scurtă de excepții, iar excepția care contează cel mai mult este cea care permite tunelului să existe. Construiți-o în această ordine, cu regula pentru endpoint înaintea regulii pentru dispozitivul tunelului, ca strângerea de mână să aibă unde să meargă:

# 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

Adresa și portul literale ale endpointului aparțin furnizorului dvs., nu acestei pagini. Dacă endpointul este un nume de gazdă, rezolvați-l o dată și fixați rezultatul, pentru că o regulă nu poate căuta un nume, iar un răspuns care se rotește va rupe politica în tăcere după următoarea schimbare DNS. Verificați și portul, pentru că furnizorii care vă mută pe TCP 443 vor avea altfel nevoie de o regulă pe care nimeni nu a scris-o. Un tunel care funcționează doar pe un protocol este de obicei exact această omisiune, nu o defecțiune a firewall-ului.

Pe un router aceeași formă merge în lanțul FORWARD pentru clienții din spatele lui, iar traficul propriu al routerului are nevoie de propriile reguli. Un set de reguli care acoperă doar pachetele redirecționate lasă SSH și DNS pe vechea cale, și așa devine un router inaccesibil în momentul în care tunelul urcă.

Pasul 4: verificați ordinea, nu doar prezența

Regulile sunt evaluate în succesiune, așa că un ACCEPT care vine mai devreme ascunde pur și simplu REJECT-ul adăugat după el. Potrivirea established și related este cea care lasă răspunsurile la propriile cereri de ieșire să revină fără a deschide o cale generală de intrare, iar plasarea ei după acceptarea tunelului înseamnă că un tunel căzut mai lasă să treacă trafic de retur pe propria interfață.

Țineți numărul de reguli suficient de mic pentru a fi citit pe un singur ecran. Un set de reguli pe care nu îl puteți audita este cel pe care îl veți petici adăugând excepții în partea de sus, și așa politicile de refuz implicit dobândesc treptat o margine de permisiune implicită. Numărați ACCEPT-urile înainte și după schimbare.

Pasul 5: faceți-o să supraviețuiască pornirii și familiei de adrese

Regulile introduse manual dispar la repornire, așa că încărcați-le din serviciul de firewall al distribuției sau dintr-o unitate care rulează după ce interfața tunelului există. Referirea la tun_work într-un script executat înainte ca OpenVPN să pornească este o modalitate obișnuită de a produce o buclă de pornire cu trafic abandonat.

Apoi verificați IPv6 separat, pentru că o politică bună de refuz implicit pentru IPv4 nu spune nimic despre cealaltă familie. ip -6 route vă va spune dacă gazda are o rută care ar putea duce trafic în jurul unui tunel care tratează doar IPv4, iar ip6tables sau nftables are nevoie de propriile reguli echivalente. Testați cu o destinație IPv6-only în loc să vă bazați pe simetria setului de reguli.

Pasul 6: verificați și fiți gata să restaurați

Ridicați tunelul, confirmați că serviciul dorit funcționează, apoi încercați ceva ce politica ar trebui să refuze. Restaurați cu iptables-restore < /root/iptables.pre dacă răspunsul vă surprinde, și abia apoi începeți să editați reguli. Persistența plus o cale de restaurare testată este ce face din aceasta o schimbare pe care o puteți face de două ori.