iptables: дозволите VPN клијентима приступ само једном хосту

Две пријаве подршци које изгледају неповезано на крају деле један узрок. У првој администратор жели да сервер прихвата везе само из тунела; у другој 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-у расте, повратни пут је покварен, а филтер је у реду. То читање штеди поподне преписивања правила која никада нису била проблем.

Блок за пошту припада један ланац даље

Блокирање порта 25 у INPUT-у зауставља само пошту адресирану на VPN сервер. Компромитовани клијент који шаље пошту кроз тунел се прослеђује, па блок мора да стоји у FORWARD-у поред 465 и 587. Ако једна апликација легитимно прослеђује пошту, ставите њену дестинацију и порт изнад тог правила.

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

Пустите бројач одбијања недељу дана пре него што било шта друго затегнете. Број који престане да расте је легитиман ток који сте управо покварили.

Прочитајте то назад, па докажите са клијента

Читајте скуп правила онако како га језгро извештава, не како га је ваша скрипта написала. Почните са iptables -S FORWARD, затим NAT табела са iptables -t nat -L POSTROUTING -n -v, затим conntrack запис за ток који испитујете. Држите команду за враћање или заказано чишћење док год посао траје. Сваки позив захтева -w, иначе ће се два администратора сударити на xtables брави. Ништа од тога није опционо у прозору промена.

Завршите тестирањем са клијента унутар базена и са оног изван њега. Правило које ради само са машине на којој сте га откуцали није политика.