Host iptables vetëm me VPN: emërtoni pajisjen tun, jo tun+

Të shkruash -o tun+ duket si udhëzim i saktë dhe në të vërtetë është një karakter i përgjithshëm që përputhet me çdo tunel që ka kerneli. Një klient i dytë VPN, një urë kontejnerësh ose një ndërfaqe e lënë nga një sesion i rrëzuar të gjitha e plotësojnë atë, dhe pretënduesi atëherë lejon trafikun që politika synonte ta pengojë. Procedura më poshtë fikson një emër pajisjeje, rendit përjashtimet në mënyrë që tuneli të mund të formohet vërtet dhe ju lë një rrugë kthimi nëse rregullat bien keq. Çdo hap është mjaft i shkurtër për t'u anuluar vetë.

Hapi 1: shënoni rregullat që keni tani

Përpara se të ndryshoni një politikë parazgjedhur, ruani gjendjen aktuale që kthimi të jetë një komandë dhe jo një kujtim. iptables-save > /root/iptables.pre shkruan çdo tabelë në një skedar që mund ta riktheni, dhe një terminal i dytë me sesion root të hapur nuk është paranojë kur politika që do të vendosni shkëput lidhjen që e mban atë. Nëse punoni nga distanca, planifikoni gjithashtu një flush si çelës emergjence.

Pastaj renditni ndërfaqet, sepse një emër që supozuat është një emër që duhet të kishit lexuar: ip -br link tregon çfarë ekziston pikërisht tani, dhe tuneli nuk do të shfaqet derisa të jetë lart. Shkruani emrat e pajisjeve ndërsa i lexoni.

Hapi 2: jepini tunelit emrin e vet

OpenVPN pranon dev tun_work në konfigurimin e klientit, dhe atëherë Linux krijon një ndërfaqe pikërisht me atë emër në vend që të caktojë tun0. Emri mbetet i qëndrueshëm midis rilidhjeve për sa kohë asgjë tjetër nuk e pretendon, dhe kjo është ajo që e bën kuptimplotë një rregull që emërton pajisjen.

Aty ku emri nuk mund të kontrollohet, përputhni adresën e tunelit ose një shenjë pakete. Të dyja funksionojnë, të dyja lexohen më vështirë dhe të dyja dështojnë më në heshtje kur tuneli rinumeron. Në çdo rast, përputhni një gjë të vetme dhe thoni qartë cilën.

Hapi 3: shkruani politikën me përjashtimin e endpoint-it të parin

Një pretëndues vetëm me VPN është një pretëndues me refuzim parazgjedhur dhe një listë të shkurtër përjashtimesh, dhe përjashtimi që ka më shumë rëndësi është ai që lejon tunelin të ekzistojë. Ndërtojeni në këtë rend, me rregullin e endpoint-it përpara rregullit të pajisjes së tunelit, që shtrëngimi i duarve të ketë ku të shkojë:

# 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 dhe porta fjalëpërfjalë e endpoint-it i përkasin ofruesit tuaj, jo kësaj faqeje. Nëse endpoint-i është emër pretënduesi, zgjidheni një herë dhe fiksoni rezultatin, sepse një rregull nuk mund të kërkojë një emër dhe një përgjigje që rrotullohet do ta prishë politikën në heshtje pas ndryshimit të ardhshëm të DNS. Kontrolloni edhe portën, sepse ofruesit që ju zhvendosin në TCP 443 përndryshe do të kenë nevojë për një rregull që askush nuk e shkroi. Një tunel që punon vetëm me një protokoll është zakonisht pikërisht ky lëshim dhe jo një defekt i firewall-it.

Në një ruter e njëjta formë shkon në zinxhirin FORWARD për klientët pas tij, dhe trafiku i vetë ruterit ka nevojë për rregullat e veta. Një grup rregullash që mbulon vetëm paketat e përcjella i lë SSH dhe DNS në rrugën e vjetër, dhe kështu ruteri bëhet i paarritshëm në momentin që tuneli ngrihet.

Hapi 4: kontrolloni rendin, jo vetëm praninë

Rregullat vlerësohen sipas radhës, kështu që një ACCEPT që vjen më herët thjesht fsheh REJECT-in që shtuat më pas. Përputhja established dhe related është ajo që i lejon përgjigjet ndaj kërkesave tuaja dalëse të kthehen pa hapur një rrugë të përgjithshme hyrëse, dhe vendosja e saj pas pranimit të tunelit do të thotë që një tunel i rënë ende kalon trafik kthimi në ndërfaqen e vet.

Mbani numrin e rregullave mjaft të vogël për t'u lexuar në një ekran. Një grup rregullash që nuk mund ta auditoni është ai që do ta patchoni duke shtuar përjashtime sipër, dhe kështu politikat e refuzimit parazgjedhur fitojnë gradualisht një skaj të lejimit parazgjedhur. Numëroni ACCEPT përpara dhe pas ndryshimit.

Hapi 5: bëni që të mbijetojë nisjen dhe familjen e adresave

Rregullat e futura me dorë zhduken në rinisje, prandaj ngarkojini nga shërbimi i firewall-it i shpërndarjes ose nga një unit që ekzekutohet pasi ekziston ndërfaqja e tunelit. Referimi i tun_work në një skript që ekzekutohet përpara se OpenVPN të nisë është një mënyrë e zakonshme për të krijuar një cikël nisjeje me trafik të hedhur.

Pastaj kontrolloni IPv6 veçmas, sepse një politikë e mirë refuzimi parazgjedhur për IPv4 nuk thotë asgjë për familjen tjetër. ip -6 route do t'ju tregojë nëse pretënduesi ka një rrugë që mund të mbajë trafik rreth një tuneli që trajton vetëm IPv4, dhe ip6tables ose nftables ka nevojë për rregullat e veta ekuivalente. Testoni me një destinacion IPv6-only në vend që të mbështeteni në simetrinë e grupit të rregullave.

Hapi 6: verifikoni dhe jini gati të riktheni

Ngrini tunelin, konfirmoni që shërbimi i synuar funksionon, pastaj provoni diçka që politika duhet ta refuzojë. Rikthejeni me iptables-restore < /root/iptables.pre nëse përgjigjja ju befasen, dhe vetëm atëherë filloni të redaktoni rregulla. Këmbëngulja plus një rrugë rikthimi e testuar është ajo që e bën këtë një ndryshim që mund ta bëni dy herë.