macOS pf biztonsági kapcsoló OpenVPN-hez: szabályok, amelyek zárva hibáznak

macOS alatt egy biztonsági kapcsoló csak annyit ér, amennyit a mögötte lévő csomagszűrő szabályzat, és a pf az a rész, amely ezt a szabályzatot érvényesíti. A szabályzatnak egyszerre két ellentétes dolgot kell tennie: engedni a klienst a kiszolgálójához, hogy alagút létezhessen, és minden mást megállítani attól, hogy közvetlenül kimenjen. A legtöbb közzétett szabálykészlet a másodikat megoldja, és megfeledkezik az elsőről, ezért a gép elveszíti a kapcsolatot ahelyett, hogy védelmet nyerne. A működő változat megnevezi a végpontot, a feloldót és az alagutat, és semmi többet.

Mit dönthet el egy csomagszűrő, és mit nem

A pf felületeket, címeket, protokollszámokat és portokat néz, és ott megáll. Soha nem tudja meg, melyik folyamat nyitott egy foglalatot, ezért az egyik programra írt engedély minden olyan program engedélyévé válik, amely elérheti ugyanazt a portot. Így fordít vissza egy nagyvonalú UDP-kivétel egy biztonsági kapcsolót közönséges hálózattá. Az alkalmazástudatos blokkolás a klienshez vagy egy rendszerbővítményhez tartozik, nem ehhez a fájlhoz.

A szűrő útvonalakat sem hoz létre. Amikor a kliens kiesik, az alapértelmezett útvonal még egy halott alagútra mutathat, és a pf ezt blokkolt csomagokká alakítja, nem pedig csendes visszaeséssé Wi-Fi-re. A blokkolás a szándékolt eredmény, nem elkerülendő hiba.

A sorrend gyakrabban dönti el az eredményt, mint a szabály szövege. quick nélkül a pf egyezés után is tovább értékel, és az utolsó egyező szabály nyer, ezért egy széles átengedés alul felülírja a fölötte lévő gondos kivételeket. Az átengedések quick jelölésével az első egyezés lesz végleges, és a szabályzat írója általában ezt érti rajta.

Először olvassa el a felület és a végpont tényeit

A vezeték nélküli felületek nem minden Macen ugyanúgy vannak számozva, és az alagúteszköz olyan számot kap, amely újraindítások között változhat. Az olyan szabály, amely nem létező eszközt nevez meg, elemzéskor meghiúsul, ami hangos és könnyen elkapható, míg a rossz létező eszközt megnevező szabály tisztán elemződik, és engedi a forgalmat, amelyet meg akart állítani.

A tényeket akkor gyűjtse, amikor a kliens csatlakozva van, mert az alagúteszköz csak akkor létezik. Szüksége van az alapértelmezett útvonalat tartó felületre, a kliens által létrehozott eszközre, valamint annak a kiszolgálónak a címére és portjára, amelyet tárcsáz. Ezt az utolsó értéket hagyja ki a legtöbb szabálykészlet, és a kihagyása az oka annak, hogy egy másolt készlet blokkolja a saját alagútját.

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

Az első parancs megnevezi a jelenleg nyerő felületet, a második felsorolja az összes eszközt, amelyet a kernel ismer, a harmadik pedig megmutatja a VPN-konfigurációkat, amelyeket a rendszer indíthat. Írja le ezeket a válaszokat, majd olvassa ki a kiszolgáló címét és portját a kliens saját konfigurációjából.

Írja meg a szabálykészletet az alagút útvonala körül

Az alábbi fájl alapértelmezésben elutasít, és öt dolgot újra beenged: loopback, az alagúteszköz, a kliens útvonala a kiszolgálójához, az alagút előtt használt feloldó, és az a két csere, amely használhatóan tartja a vezeték nélküli kapcsolatot. A felületnevek és a kiszolgáló címe az Ön gépéről származnak, ezért cserélje ki az ellenőrzött értékeket. Az alagút száma sem fog egyezni az önével.

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

A DHCP-sor azért van, mert a Mac a címet azelőtt kéri, hogy lenne neki, ezért a kérés a 68-as portról a 67-es port felé lép ki használható forráscím nélkül. A multicast-sor lehetővé teszi a rendszernek, hogy eldöntse, érdemes-e a vezeték nélküli kapcsolatot használni, és eltávolítása olyan gépet eredményez, amely működő hálózaton sem jelez kapcsolatot. A végpont sora az, amely OpenVPN számára egyáltalán lehetővé teszi a kiszolgálója elérését; nélküle a block all eldobja a külső kézfogást, és az alagút soha nem jön fel. A feloldó sora szűkebb egy általános DNS-engedélynél, mert egy címet és egy portot nevez meg a gép minden lekérdezése helyett.

Ez a végpont- és feloldókivétel az a kettő, amelynek léteznie kell; minden más blokkolva marad. Ha a kliens szó szerinti címet tárcsáz, törölje a feloldó sorát, és tartsa meg a végpont sorát. Ha a kiszolgáló címe megváltozik, frissítse azt a sort a következő kapcsolat előtt, vagy töltsön fel egy pf táblát a kliens saját horgából, és inkább a táblát illessze.

Vegye le az alagutat, majd indítsa újra

Elemzés a betöltés előtt, mert egy szintaktikai hiba olcsó egy száraz futásban és drága egy távoli munkamenetben. Aztán töltse be a fájlt, kapcsolja be a szűrőt, ha ki volt kapcsolva, és olvassa vissza, mi van valóban érvényben. A visszaolvasás nem szertartás: egy másik horgony olyan szabályokat adhat hozzá, amelyeket nem írt, ezért hasonlítsa össze a kiírt készletet a fájljával.

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

A betöltött szabályokkal vegye le az alagutat, és próbáljon meg betölteni egy oldalt. A közönséges forgalomnak meg kell állnia, és állva kell maradnia azután is, hogy a gép elalszik és felébred, mert éppen ebben az átmenetben kúszik vissza az elavult állapot. Csatlakozzon újra, és erősítse meg, hogy a forgalom a szabálykészlet érintése nélkül folytatódik. Ha a böngésző leállított alagút mellett is működik, valamelyik szabály szélesebb a gondoltnál, és a visszaolvasás általában megnevezi.

Az újraindítás az a rész, amelyet az emberek kihagynak. A macOS rendszerindításkor olvassa a /etc/pf.conf fájlt, de a fájl olvasása nem ugyanaz, mint a szűrő engedélyezése, ezért egy most működő szabálykészlet újraindítás után inaktív lehet. Ezután futtassa a sudo pfctl -s info parancsot, és erősítse meg, hogy az állapotsor engedélyezettként jelenti a szűrőt.

Tartsa őszintén a kijáratot és az újraindítási útvonalat

Egy mindent blokkoló szabálykészlet ki is zárhat egy gépről, amelyet távolról adminisztrál. Szerkesszen helyi munkamenetből, amikor csak tud, tartsa az előző fájlt az új mellett, és ismerje a visszaállítást, mielőtt szüksége lenne rá. Az alábbi parancsok kikapcsolják a szűrőt és újratöltik a megtartott másolatot, és ez a konzolról futtatandó sorrend, nem azon az alagúton át, amelyet éppen elvágott. Az öt másodperces visszaállítás minden alkalommal legyőzi az okos szabályt.

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

A tartóssághoz olyan indító démon kell, amely futtatja a pfctl -e parancsot, és rendszerindításkor betölti a fájlját. Kezelje úgy, mint bármely más kiemelt feladatot: abszolút útvonalak, utólag olvasható napló, és teszt egy gépen, amelyet fizikailag el tud érni. A csendben meghiúsuló démon védtelenül és normálisnak látszva hagyja a gépet.

Dokumentálja a hézagokat, kezdve egy második VPN-klienssel, amely saját alagúteszközt hoz létre. Az Ön szabályai egy alagútfelületet neveznek meg, ezért a második blokkolva marad, vagy egy később hozzáadott széles szabály elkapja. A tethering- és hotspot-felületek csak néha jelennek meg, és ugyanazt a megjegyzést érdemlik. E hézagok egyike sem ok a szabályzat kihagyására; ezek azok a feltételek, amelyek mellett még érvényes.