Байланысы жоқ болып көрінетін екі қолдау билетінің түпкі себебі бір. Біріншісінде әкімші сервер тек туннельден қосылымдарды қабылдауын қалайды; екіншісінде VPN пайдаланушылары бір ішкі хостқа жетуі керек, одан артық емес. Екі саясат та FORWARD-қа жатады, және екеуі де әдетте INPUT-та сыналады. Нәтиже файрволға ұқсайды, бірақ орынбасар сияқты әрекет етеді.

Қай тізбек сұрағыңызға жауап береді

VPN клиенті LAN хостына немесе одан әрі интернетке жіберетін пакеттерді ядро қайта жібереді және олар FORWARD-та бағаланады. INPUT пен OUTPUT тек сервердің өзінде аяқталатын немесе одан басталатын трафикті көреді. Сондықтан tun0-ға келмейтіннің бәрін қабылдамау сервердің өз тыңдаушыларын қорғайды, сондай-ақ орныққан ағындар алдымен рұқсат етілмесе, SSH сессияңызды да тоқтатады. Бұл клиенттердің қайда бара алатыны туралы ештеңені өзгертпейді.

Алдымен сұрақты атаңыз: кім серверге жете алады, немесе клиенттер қайда бара алады. Көптеген желілерге екі жауап та керек, әртүрлі тізбектерде.

Алдымен күй, содан кейін рұқсат, содан кейін бас тарту

Рұқсат тізімі тек нақты рұқсат жалпы бас тартудың үстінде тұрса және қайтару трафигі екеуінен де жоғары рұқсат етілсе ғана жұмыс істейді. Ережелерді айқын позицияларға кірістіріңіз, содан кейін iptables -S FORWARD көмегімен тізбекті шығарыңыз, сөйтіп рет болжалмай, көрінетін болсын.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Бұл нақты трафикпен соқтығысқанда төтеп бере ме, оны екі бөлшек шешеді. Күй ережесі болмаса, жаңа ғана рұқсат еткен қосылымдарға келетін жауаптар бас тартуға қарсы бағаланып, тасталады. Шектеусіз LOG ережесі сканерлеу тигенде шағын бөлімді толтырып тастауы мүмкін, сондықтан жазуды жалғастырмас бұрын -m limit --limit 10/min қосыңыз. REJECT қатені бірден қайтарады, бұл тізімді реттеу кезінде қолайлырақ; DROP үнсіз тастайды, сондықтан әр қате уақыттың бітуі ретінде көрінеді. Біреуін әдейі таңдап, таңдауды өзгеріс жазбасына жазыңыз.

Қайта жіберу мен NAT бұрыннан жұмыс істеуі керек

Сүзгілеу жолдың бар екенін дәлелдей алмайды. Алдымен ядроның мүлдем қайта жіберетінін растаңыз және бұл параметрді қабықшаның бір реттік командасы емес, тұрақты етіңіз. Сүзгі соңғы қабат, біріншісі емес.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Маскарадтың қайда тұратыны клиенттердің қайдан шығатынына байланысты. Егер олар туннель арқылы алыс желіге шықса, NAT ережесі WAN интерфейсіне емес, сол интерфейске қойылады. Содан кейін санауыштарды қараңыз: егер POSTROUTING санауышы ешқашан қозғалмай, FORWARD рұқсаттарының саны артса, қайтару жолы бұзылған, ал сүзгі дұрыс. Бұл оқу ешқашан мәселе болмаған ережелерді қайта жазуға кететін жарты күнді үнемдейді.

Пошта блогы бір тізбек әрірек

INPUT-та 25 портын блоктау тек VPN серверіне арналған поштаны тоқтатады. Туннель арқылы пошта жіберетін зақымдалған клиент қайта жіберіледі, сондықтан блок 465 пен 587-нің қасында FORWARD-та тұруы керек. Егер бір қолданба поштаны заңды түрде қайта жіберсе, оның мақсаты мен портын сол ереженің үстіне қойыңыз.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Басқа нәрсені қатайтпас бұрын бас тарту санауышын бір апта жұмыс істетіңіз. Өсуін тоқтатқан сан — жаңа ғана бұзған заңды ағын.

Оны қайта оқып, содан кейін клиенттен дәлелдеңіз

Ережелер жинағын ядро хабарлағандай оқыңыз, сценарийіңіз жазғандай емес. iptables -S FORWARD-тен бастаңыз, содан кейін iptables -t nat -L POSTROUTING -n -v-пен NAT кестесі, содан кейін тексеріп жатқан ағынның conntrack жазбасы. Жұмыс жалғасқанша қайтару командасын немесе жоспарланған тазартуды ұстаңыз. Әр шақыруға -w керек, әйтпесе екі әкімші xtables құлпында соқтығысады. Өзгеріс терезесінде осының бәрі міндетті.

Пулдің ішіндегі клиенттен және оның сыртындағы клиенттен сынап аяқтаңыз. Тек өзіңіз теруге тиген машинадан жұмыс істейтін ереже саясат емес.

Қатысты мақалалар