На macOS, заштитниот прекинувач е само толку добар колку политиката на пакетниот филтер зад него, а pf е делот што ја спроведува таа политика. Политиката мора истовремено да прави две спротивни работи: да му дозволи на клиентот да стигне до својот сервер за да може да постои тунел, и да го запре сето останато да излегува директно. Повеќето објавени збирови правила го совладуваат второто и го забораваат првото, па машината губи поврзаност наместо да добие заштита. Верзијата што работи ги именува крајната точка, разрешувачот и тунелот, и ништо повеќе.

Што може да одлучи пакетниот филтер, а што не

pf гледа интерфејси, адреси, броеви на протоколи и порти, и тука застанува. Никогаш не дознава кој процес отворил сокет, па дозвола напишана за една програма станува дозвола за секоја програма што може да стигне до истиот порт. Така дарежлив UDP исклучок го враќа заштитниот прекинувач во обична мрежа. Блокирање свесно за апликацијата им припаѓа на клиентот или на системско проширување, не на оваа датотека.

Филтерот не создава ни рути. Кога клиентот паѓа, стандардната рута може и понатаму да покажува на мртов тунел, и pf тоа го претвора во блокирани пакети наместо тивко враќање на Wi-Fi. Блокирањето е посакуваниот резултат, не дефект што треба да се заобиколи.

Редоследот го решава исходот почесто од текстот на правилото. Без quick pf продолжува да оценува по совпаѓање и победува последното правило што се совпаѓа, па широк пропуст при дното ги поништува внимателните исклучоци над него. Означувањето на пропустите како quick го прави првото совпаѓање конечно, што авторот на политика обично го мисли.

Прво прочитајте ги фактите за интерфејсот и крајната точка

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

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

route -n get default
ifconfig -l
scutil --nc list

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

Напишете го збирот правила околу патеката на тунелот

Датотеката подолу одбива по стандард и повторно прима пет работи: loopback, уредот на тунелот, патеката на клиентот до неговиот сервер, разрешувачот што се користи пред да постои тунел, и двете размени што држат безжична врска употреблива. Имињата на интерфејсите и адресата на серверот доаѓаат од вашата машина, затоа заменете ги вредностите што сте ги потврдиле. Ни бројот на тунелот нема да се совпадне со вашиот.

set skip on lo0
block all
pass out quick on utun0
# maintain this line when the server address changes
pass out quick on en1 inet proto udp to 203.0.113.10 port 1194
# only the resolver the client uses before the tunnel exists
pass out quick on en1 inet proto udp to 192.0.2.53 port 53
pass out quick on en1 inet proto udp from any port 68 to any port 67
pass out quick on en1 inet proto udp to 224.0.0.251 port 5353

Редот DHCP постои затоа што Mac бара адреса пред да ја има, па барањето излегува од порта 68 кон порта 67 без употреблива изворна адреса. Редот multicast му дозволува на системот да процени дали безжичната врска вреди да се користи, а неговото отстранување создава машина што пријавува нема врска на мрежа што работи. Редот на крајната точка е она што OpenVPN воопшто му овозможува да стигне до својот сервер; без него block all го отфрла надворешниот ракување и тунелот никогаш не се крева. Редот на разрешувачот е потесен од општа DNS дозвола, бидејќи именува една адреса и една порта наместо секое барање што машината го прави.

Тие исклучоци за крајната точка и разрешувачот се двете што мора да постојат; сето останато останува блокирано. Ако клиентот повикува буквална адреса, отстранете го редот на разрешувачот и задржете го редот на крајната точка. Ако адресата на серверот се промени, ажурирајте го тој ред пред следното поврзување, или наполнете pf табела од сопствената кука на клиентот и наместо тоа совпаѓајте ја табелата.

Спуштете го тунелот, потоа рестартирајте

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

sudo pfctl -n -v -f /etc/pf.conf
sudo pfctl -f /etc/pf.conf
sudo pfctl -e
sudo pfctl -s rules
sudo pfctl -s Anchors
sudo pfctl -a <anchor> -s rules
sudo pfctl -s info

Со вчитани правила, спуштете го тунелот и обидете се да вчитате страница. Обичниот сообраќај треба да запре, и треба да остане запрен откако машината ќе заспие и ќе се разбуди, бидејќи токму при таа транзиција застарената состојба повторно се вовлекува. Поврзете се повторно и потврдете дека сообраќајот продолжува без допирање на збирот правила. Ако прелистувачот и понатаму работи со спуштен тунел, некое правило е пошироко отколку што мислевте, и читањето обично го именува.

Рестартирањето е делот што луѓето го прескокнуваат. macOS при подигање ја чита /etc/pf.conf, но читањето на датотеката не е исто што и вклучување на филтерот, затоа збир правила што сега работи може да биде неактивен по рестарт. Потоа извршете sudo pfctl -s info и потврдете дека статусната линија го пријавува филтерот како вклучен.

Чувајте го излезот и патеката за рестарт чесни

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

sudo pfctl -d
sudo pfctl -f /etc/pf.conf.previous
sudo pfctl -s rules

Трајноста бара launch daemon што го извршува pfctl -e и ја вчитува вашата датотека при подигање. Однесувајте се кон него како кон секоја друга привилегирана работа: апсолутни патеки, дневник што можете да го прочитате подоцна, и тест на машина до која физички можете да стигнете. Демон што тивко паѓа ја остава машината незаштитена и со нормален изглед.

Документирајте ги празнините, почнувајќи од втор VPN клиент што создава сопствен уред за тунел. Вашите правила именуваат еден тунелски интерфејс, па вториот останува блокиран или го фаќа широко правило додадено подоцна. Интерфејсите за tethering и hotspot се појавуваат само понекогаш и заслужуваат иста белешка. Ниту една од тие празнини не е причина да се прескокне политиката; тие се условите под кои таа и понатаму важи.

Поврзани статии