Firewall на VPS: отворете само VPN портата и потоа докажете го

Firewall што пушта само VPN портата не е едно правило. Тоа се три одделни одлуки што случајно се однесуваат на истиот број на порта: влезниот синџир одлучува што може да стигне до локален процес, синџирот за проследување одлучува што може да помине низ домаќинот во име на клиентите на тунелот, а NAT табелата ја препишува изворната адреса на излезот. Згрешете една од нив и резултатот ретко е чисто прекинување. Добивате домаќин што прифаќа клиенти, но не вчитува ништо, или домаќин што изгледа затворен додека некој не го прочита редоследот на синџирите.

Единствената порта што не може да се затвори

Слушачот на VPN мора да прифаќа врски од адреси што не можете да ги предвидите, па по дефиниција е јавна услуга. Ова е единствениот исклучок врз кој е изграден дизајнот: една UDP порта за OpenVPN, една UDP порта за WireGuard, една TCP порта за SSL VPN. Сето друго припаѓа зад тунелот, што значи дека апликациските услуги треба да се врзат за адресата на тунелот или за loopback, а не за сите интерфејси.

Врзувањето, сепак, не е спроведување. Процес врзан за 0.0.0.0 е достапен само ако правилото го пушта, а стандардната политика е резервата за сообраќај што не се совпаднал со ниту едно правило, не правилото што управува со портата. Прифаќање поставено над вашето отфрлање останува прифаќање, а преместувањето на услугата од јавната адреса е независно подобрување, не замена за синџирот.

Влез, проследување и NAT одговараат на различни прашања

Влезниот сообраќај е наменет за самиот домаќин, па таму живеат слушачот на VPN и административната патека. Сообраќајот за проследување поминува низ домаќинот, а на клиентите на тунелот им е потребен заедно со net.ipv4.ip_forward=1. Класичната полурасипана конфигурација го дозволува излезниот тек и ја заборава насоката на враќање, па клиентот ја завршува ракувањето и потоа ништо не се вчитува; правило conntrack за воспоставен и поврзан сообраќај ја покрива таа насока.

NAT е третото прашање. Без препишување во postrouting, проследените пакети излегуваат со приватниот извор на тунелот и се отфрлаат повисоко, бидејќи ниту една мрежа надвор од домаќинот не знае како да го врати базенот. Изворниот префикс во тоа правило мора да одговара на базенот на VPN, не на сопствената адреса на домаќинот, и истото важи за правилото за проследување што ја именува подмрежата на клиентите.

IPv6 е втора политика, не подоцнежна мисла. Домаќин со строг IPv4 синџир и отворена политика на ip6tables не затворил ништо; услугите сѐ уште се достапни преку другото семејство. Или пресликајте го множеството правила со ip6tables, или намерно исклучете го IPv6 на јавниот интерфејс, и запишете што избравте.

Основна линија што се чита во еден преглед

Почнете со отфрлање, потоа додајте само што му треба на домаќинот. Прво loopback и одговори, потоа административната патека, потоа слушачот на тунелот, потоа политиката за проследување за клиентите:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Имињата на интерфејсите, портата и базенот се места за пополнување; читајте ги од серверот наместо да ги копирате. Зачувувањето на резултатот е исто толку важно како и пишувањето, бидејќи множество правила што живее само во меморија исчезнува при следното рестартирање и тивко го отвора домаќинот повторно. Направете го трајно со механизмот на дистрибуцијата и чувајте копија надвор од машината за денот кога машината нема да се подигне.

Затворање на последната порта без губење на домаќинот

Во дизајнот има стапица. Ако SSH постои само преку тунелот, падната VPN услуга го носи SSH со себе, а единствениот пат назад може да биде конзола што никогаш не сте ја отвориле. Пред да ја затворите последната јавна порта, потврдете дека таа конзола постои и дека навистина можете да ја користите, или задржете една тесна административна патека што не зависи од тунелот: SSH од фиксна адреса, само клучеви, автентикација со лозинка исклучена.

Применете ја промената од веќе воспоставена сесија, а не низ врската што сакате да ја филтрирате. Закажете враќање за да истече грешката наместо да стане трајна, на пример задача systemd-run --on-active=10min што го враќа претходното множество правила, и држете втора SSH сесија отворена додека ја тестирате првата. Потоа проверете дали задачата за враќање навистина се активира, бидејќи непроверено враќање е исто како никакво враќање.

Проверете ја патеката, не скриптата

Читајте ги вчитаните правила, а не датотеката што требаше да ги вчита. Од овластен надворешен домаќин потврдете дека одговараат само предвидените порти; од внатрешноста на тунелот потврдете дека услугите што сакавте да ги објавите се достапни. Стандардна политика на отфрлање што го блокира и сообраќајот на тунелот изгледа исто како работење со заклучување додека некој не се обиде да го користи.

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

Запишете ја дозволената порта, базенот на клиентите, интерфејсот на тунелот, административниот извор и постапката за конзолата до конфигурацијата. Следната промена на базенот или на името на интерфејсот мора да се усогласи и во филтерот и во правилото NAT, инаку домаќинот се враќа во полуотворена состојба без никој да забележи.

Една навика вреди повеќе од множеството правила: по секоја промена докажете ја патеката за проследување со барање од клиент, а патеката за враќање со втора сесија. Заклучување што не сте го користеле е само хипотеза.