iptables-gastigo nur per VPN: nomu la tun-aparaton, ne tun+

Skribi -o tun+ ŝajnas preciza instrukcio kaj fakte estas ĵokero super ĉiu tunelo, kiun la kerno havas. Dua VPN-kliento, uja ponto aŭ interfaco lasita de kraŝinta seanco ĉiuj plenumas ĝin, kaj la gastigo tiam permesas trafikon, kiun la politiko celis malhelpi. La proceduro sube fiksas unu aparatan nomon, ordigas la esceptojn tiel, ke la tunelo povu efektive formiĝi, kaj lasas al vi vojon reen se la reguloj surteriĝas malbone. Ĉiu paŝo estas sufiĉe mallonga por esti malfarita sola.

Paŝo 1: notu la regulojn, kiujn vi havas nun

Antaŭ ol ŝanĝi defaŭltan politikon, konservu la nunan staton por ke la restarigo estu komando, ne memoro. iptables-save > /root/iptables.pre skribas ĉiun tabelon al dosiero, kiun vi povas restarigi, kaj dua terminalo kun malfermita root-seanco ne estas paranojo kiam la politiko, kiun vi baldaŭ starigos, faligos la konekton, kiu ĝin portas. Se vi laboras distance, planu ankaŭ flush kiel sekuran ŝaltilon.

Poste listigu la interfacojn, ĉar nomo, kiun vi supozis, estas nomo, kiun vi devus esti leginta: ip -br link montras, kio ekzistas nun, kaj la tunelo ne aperos ĝis ĝi estos supre. Notu la aparatajn nomojn dum vi legas ilin.

Paŝo 2: donu al la tunelo sian propran nomon

OpenVPN akceptas dev tun_work en la klienta agordo, kaj Linux tiam kreas interfacon kun ĝuste tiu nomo anstataŭ atribui tun0. La nomo restas stabila tra rekonektoj dum nenio alia postulas ĝin, kaj tio estas kio donas sencon al regulo, kiu nomas la aparaton.

Kie la nomo ne povas esti kontrolata, kongruu anstataŭe la tunelan adreson aŭ paketan markon. Ambaŭ funkcias, ambaŭ estas pli malfacile legeblaj, kaj ambaŭ malsukcesas pli silente kiam la tunelo renumeras. Ĉiukaze kongruu unu aferon kaj estu eksplicita pri kiu.

Paŝo 3: skribu la politikon kun la endpoint-escepto unue

Gastigo nur per VPN estas gastigo kun defaŭlta malpermeso kaj mallonga esceptlisto, kaj la escepto, kiu plej gravas, estas tiu, kiu permesas al la tunelo ekzisti. Konstruu ĝin en ĉi tiu ordo, kun la endpoint-regulo antaŭ la tunel-aparata regulo, por ke la manpremo havu kien iri:

# 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

La laŭvorta endpoint-adreso kaj haveno apartenas al via provizanto, ne al ĉi tiu paĝo. Se la endpoint estas gastiga nomo, solvu ĝin unufoje kaj fiksu la rezulton, ĉar regulo ne povas serĉi nomon, kaj rotacia respondo silente rompos la politikon post la sekva DNS-ŝanĝo. Kontrolu ankaŭ la havenon, ĉar provizantoj, kiuj movas vin al TCP 443, alie bezonos regulon, kiun neniu skribis. Tunelo, kiu funkcias nur per unu protokolo, estas kutime ĝuste ĉi tiu preterlaso kaj ne paneo de la fajroŝirmilo.

Sur enkursigilo la sama formo iras en la FORWARD-ĉenon por la klientoj malantaŭ ĝi, kaj la propra trafiko de la enkursigilo bezonas proprajn regulojn. Regula aro, kiu kovras nur plusenditajn pakojn, lasas SSH kaj DNS sur la malnova vojo, kaj tiel enkursigilo fariĝas neatingebla en la momento, kiam la tunelo supreniĝas.

Paŝo 4: kontrolu la ordon, ne nur la ĉeeston

Reguloj taksatas laŭvice, do ACCEPT, kiu venas pli frue, simple kaŝas la REJECT, kiun vi aldonis poste. La kongruo established kaj related estas tio, kio lasas respondojn al viaj propraj eliraj petoj reveni sen malfermi ĝeneralan eniran vojon, kaj meti ĝin post la tunela akcepto signifas, ke falinta tunelo ankoraŭ trapasigas revenan trafikon sur sia propra interfaco.

Tenu la regulan nombron sufiĉe malgranda por esti legata sur unu ekrano. Regula aro, kiun vi ne povas revizii, estas tiu, kiun vi flikos aldonante esceptojn supre, kaj tiel defaŭltaj malpermesaj politikoj iom post iom akiras defaŭltan permesan randon. Kalkulu la ACCEPT-ojn antaŭ kaj post la ŝanĝo.

Paŝo 5: faru, ke ĝi postvivu la starton kaj la adresan familion

Reguloj entajpitaj mane malaperas ĉe restartigo, do ŝargu ilin el la fajroŝirmila servo de la distribuo aŭ el unuo, kiu ruliĝas post kiam la tunela interfaco ekzistas. Referenci tun_work en skripto, kiu plenumiĝas antaŭ ol OpenVPN startas, estas ofta maniero produkti startan buklon de falinta trafiko.

Poste kontrolu IPv6 aparte, ĉar bona defaŭlta malpermesa politiko por IPv4 diras nenion pri la alia familio. ip -6 route diros al vi, ĉu la gastigo havas vojon, kiu povus porti trafikon ĉirkaŭ tunelo, kiu traktas nur IPv4, kaj ip6tables aŭ nftables bezonas siajn proprajn ekvivalentajn regulojn. Testu per IPv6-only-celo anstataŭ fidi la simetrion de la regula aro.

Paŝo 6: kontrolu kaj estu preta restarigi

Levigu la tunelon, konfirmu, ke la celita servo funkcias, poste provu ion, kion la politiko devus rifuzi. Restarigu per iptables-restore < /root/iptables.pre se la respondo surprizas vin, kaj nur tiam komencu redakti regulojn. Persisteco plus provita restariga vojo estas tio, kio faras ĉi tion ŝanĝo, kiun vi povas fari dufoje.