Faqat VPN uchun iptables xost: tun qurilmasini nomlang, tun+ emas

-o tun+ yozish aniq ko'rsatmaga o'xshaydi, aslida esa yadroda mavjud har bir tunnelga mos keladigan joker belgidir. Ikkinchi VPN mijozi, konteyner ko'prigi yoki buzilgan sessiyadan qolgan interfeys — barchasi uni qanoatlantiradi, va xost siyosat to'smoqchi bo'lgan trafikni o'tkazib yuboradi. Quyidagi tartib bitta qurilma nomini qat'iylashtiradi, istisnolarni tunnel haqiqatan shakllanishi uchun tartibga soladi va qoidalar yomon tushsa, qaytish yo'lini qoldiradi. Har bir qadam alohida bekor qilinadigan darajada qisqa.

1-qadam: hozir mavjud qoidalarni yozib oling

Standart siyosatni o'zgartirishdan oldin joriy holatni saqlang, shunda orqaga qaytish xotira emas, buyruq bo'ladi. iptables-save > /root/iptables.pre har bir jadvalni tiklash mumkin bo'lgan faylga yozadi, va root sessiyasi ochiq ikkinchi terminal — o'rnatmoqchi bo'lgan siyosatingiz uni olib yuruvchi ulanishni uzganda, ortiqcha vahima emas. Agar masofadan ishlasangiz, flush ham favqulodda o'chirgich sifatida rejalashtiring.

Keyin interfeyslarni sanang, chunki siz taxmin qilgan nom — o'qishingiz kerak bo'lgan nom: ip -br link hozir nima borligini ko'rsatadi, tunnel esa ko'tarilmaguncha ko'rinmaydi. O'qiyotganingizda qurilma nomlarini yozib boring.

2-qadam: tunnelga o'z nomini bering

OpenVPN mijoz konfiguratsiyasida dev tun_work ni qabul qiladi, va keyin Linux tun0 ajratish o'rniga aynan shu nom bilan interfeys yaratadi. Boshqa hech narsa unga da'vo qilmasa, nom qayta ulanishlar orasida barqaror qoladi, va qurilmani nomlaydigan qoidani mazmunli qiladigan narsa ham shu.

Nomni boshqarib bo'lmaydigan joylarda tunnel manziliga yoki paket belgisiga moslashing. Ikkalasi ham ishlaydi, ikkalasini ham o'qish qiyinroq, va tunnel qayta raqamlanganda ikkalasi ham jimroq muvaffaqiyatsiz bo'ladi. Har holda, bitta narsaga moslashing va qaysi ekanini aniq ayting.

3-qadam: siyosatni endpoint istisnosi bilan birinchi yozing

Faqat VPN bilan ishlaydigan xost — qisqa istisnolar ro'yxati bo'lgan standart rad xosti, va eng muhim istisno tunnelning mavjud bo'lishiga ruxsat beradigan qoidadir. Uni shu tartibda quring, endpoint qoidasi tunnel qurilmasi qoidasidan oldin bo'lsin, shunda qo'l siqishga boradigan joy bo'ladi:

# 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

Endpointning so'zma-so'z manzili va porti sizning provayderingizga tegishli, bu sahifaga emas. Agar endpoint xost nomi bo'lsa, uni bir marta hal qiling va natijani qat'iylashtiring, chunki qoida nomni qidira olmaydi va aylanuvchi javob keyingi DNS o'zgarishidan keyin siyosatni jimgina buzadi. Portni ham tekshiring, chunki sizni TCP 443 ga o'tkazadigan provayderlar aks holda hech kim yozmagan qoidaga muhtoj bo'ladi. Faqat bitta protokolda ishlaydigan tunnel odatda aynan shu kamchilik, firewall nosozligi emas.

Routerda xuddi shu shakl uning orqasidagi mijozlar uchun FORWARD zanjiriga tushadi, va routerning o'z trafigi o'z qoidalarini talab qiladi. Faqat yo'naltirilgan paketlarni qamrab oluvchi qoidalar to'plami SSH va DNSni eski yo'lda qoldiradi, va tunnel ko'tarilgan lahzada routerning yetib bo'lmaydigan bo'lishi shundan.

4-qadam: faqat borligini emas, tartibini tekshiring

Qoidalar ketma-ket baholanadi, shuning uchun oldinroq keladigan ACCEPT keyin qo'shgan REJECTni shunchaki yashiradi. established va related mosligi — o'zingizning chiquvchi so'rovlaringizga javoblarning umumiy kiruvchi yo'lni ochmasdan qaytishiga imkon beradigan narsa, va uni tunnel qabul qilingandan keyin qo'yish qulagan tunnel ham o'z interfeysida qaytish trafigini o'tkazishini bildiradi.

Qoidalar sonini bitta ekranda o'qish mumkin bo'lgan darajada kam saqlang. Auditi qila olmaydigan qoidalar to'plami — yuqoriga istisnolar qo'shib yamab oladigan to'plam, va standart rad siyosatlari asta-sekin standart ruxsat chetiga ega bo'lishi shundan. O'zgartirishdan oldin va keyin ACCEPTlarni sanang.

5-qadam: uni yuklanish va manzillar oilasidan o'tkazing

Qo'lda kiritilgan qoidalar qayta yuklashda yo'qoladi, shuning uchun ularni distributivning firewall xizmatidan yoki tunnel interfeysi mavjud bo'lgandan keyin ishlaydigan unitdan yuklang. OpenVPN boshlanishidan oldin ishlaydigan skriptda tun_work ga murojaat qilish — qulagan trafikning yuklanish halqasini yaratishning keng tarqalgan usuli.

Keyin IPv6ni alohida tekshiring, chunki IPv4 uchun yaxshi standart rad siyosati boshqa oila haqida hech narsa demaydi. ip -6 route xostda faqat IPv4 bilan ishlaydigan tunnelni chetlab o'tadigan marshrut bor-yo'qligini aytadi, va ip6tables yoki nftables o'zining ekvivalent qoidalarini talab qiladi. Qoidalar to'plamining simmetriyasiga ishonish o'rniga IPv6-only manzil bilan sinang.

6-qadam: tekshiring va tiklashga tayyor bo'ling

Tunnelni ko'taring, mo'ljallangan xizmat ishlayotganiga ishonch hosil qiling, so'ng siyosat rad etishi kerak bo'lgan narsani sinab ko'ring. Javob sizni hayratlantirsa iptables-restore < /root/iptables.pre bilan tiklang, va shundan keyingina qoidalarni tahrirlashni boshlang. Barqarorlik va sinalgan tiklash yo'li — buni ikki marta qilish mumkin bo'lgan o'zgarishga aylantiradigan narsa.