Mac PF VPN-zár: helyi szabályzat, nem szállítható funkció

Működik a Macjén, ezért úgy tűnik, mintha odaadhatná a felhasználóknak. Ezt a feltevést kell elsőként elveszíteni. Az Apple TN3165 dokumentuma egyértelműen kimondja, hogy a Packet Filter nem támogatott API az általánosan terjesztett termékekhez, és a kiváltságos, ellenőrzött telephelyi adminisztrációt tekinti ésszerű esetnek. A PF-re épülő VPN-zár ezért tulajdonossal rendelkező helyi üzemeltetési szabályzat, nem olyan funkció, amelyet egy alkalmazáson belül szállíthat.

A PF nem csomagolási felület

A különbség nem akadémikus. A PF-től függő terjesztett termék örökli az Apple minden rajta végzett változtatását, minden ütközést egy másik eszközzel, amely szintén szabályokat ír, és semmilyen támogatási kötelezettséget arra, hogy az elrendezés továbbra is működik. Az a telephely, amely saját gépeit adminisztrálja, más viszonyban van: dokumentálhatja a függőséget, tesztelheti minden operációsrendszer-kiadás ellen, és elfogadhatja a karbantartást.

Egyes telepítési tanácsok átlépnek egy határt, amelyet érdemes megnevezni. A teljes rendszerszabály-készlet felülírása, hogy egy horgony betöltődjön, az Apple rendszerindítási konfigurációjának szerkesztése vagy a System Integrity Protection letiltása nem elfogadható követelmény egy újrahasznosítható recepthez. Ha egy közzétett útmutató bármelyiket igényli, laboratóriumot ír le, nem telepíthető szabályzatot.

A kimenő szándékot a szintaxis előtt írja meg

Döntse el, mi engedélyezett, mielőtt egyetlen kulcsszót választana. Általában három útnak kell léteznie: a VPN-kliens saját átvitele a szerveréhez, a védett alkalmazás forgalma az alagúton belül, és mindaz, aminek a beállítás vagy a helyi szolgáltatások valóban közvetlen utat igényelnek.

Minden javasolt kivételnek adjon célt, átvitelt és tulajdonost. Az összes port engedélyezése egy végpont felé sokkal többet engedélyez, mint az az egyetlen átvitel, amelyet az alagút használ, és a további kitettség anélkül jön létre, hogy bárki eldöntötte volna, hogy lennie kell. Egy nyilvános feloldó engedélyezése ugyanaz a csapda barátságosabb köntösben: közvetlen DNS-utat hoz létre akkor is, amikor az alagút le van állva, így a névkeresések továbbra is szivárognak.

Egy kivétel hasznos próbája, hogy meg tudja-e nevezni azt a személyt, aki kérte, és azt a hibát, amelyet megakadályoz. Ha egyik válasz sem létezik, a szabály valószínűleg egy hibás konfiguráció kerülőútja, amely különben láthatatlan maradna.

Az utun-számok nem identitások

A MacOS alagút-interfészeket utun eszközként hoz létre, és a VPN-jéhez rendelt szám nem stabil újraindítások, újracsatlakozások vagy egy másik kliens jelenléte között. Az a szabály, amely több találgatott számot sorol fel, nem szabályzat; egy délután pillanatképe.

Horgonyozza a szabályt valamihez, ami azonosítja a szándékolt szolgáltatót: az alagút által kiosztott címtervhez, az interfészt birtokló folyamathoz vagy egy konfigurációhoz, amelyet maga a VPN-kliens tart fenn. Ezután jegyezze fel, hogyan működik ez az azonosítás, mert aki egy év múlva felülvizsgálja a szabályt, nem fogja ismerni a shell-előzményeit.

Tegye a betöltött szabályzatot tulajdoníthatóvá

A horgonynév rendezi a szabályokat; nem bizonyítja, hogy a tényleges szabályzat az, amit szándékolt. A horgonyok közötti elsőbbség, a más szoftverek által betöltött szabályok és a meglévő állapot mind megváltoztathatják az eredményt. Tekintse át a tényleges készletet mindenkivel, aki szintén birtokol PF-et azon a gépen, és dokumentálja a tulajdonjogot ugyanott, ahol a konfiguráció van. Két tulajdonos, aki különböző horgonyokat szerkeszt különböző feltevésekkel, a szokásos módja annak, ahogy egy zár lyukat kap.

Tartsa a szabálykészletet a telephely támogatott konfigurációs útvonalán, verziózza, és jegyezze fel, mely macOS-kiadásokat tesztelték. A kézzel alkalmazott és egyetlen ember által megjegyzett változtatás nem karbantartott infrastruktúra, bármit is mond a fájl fejléce.

Az átmeneteket tesztelje, nem a csatlakoztatott állapotot

Az alagút aktív állapotában készült képernyőkép szinte semmit sem bizonyít. Járja végig inkább az állapotokat: indítás bármilyen kapcsolat előtt, működő alagút, figyelmeztetés nélkül leeső alagút, szándékos leválasztás és a Wi-Fi-ről hotspotra váltás. Minden állapotnak megvan a maga válasza, és az érdekesek a hibák, nem a boldog út.

Minden állapotban jegyezze fel, mi érhető el szándékosan. Ellenőrizze külön az IPv4-et és az IPv6-ot, tesztelje a névfeloldást, és vegyen bele egy olyan folyamot, amely már az átmenet előtt létrejött, mert a meglévő kapcsolatok nem mindig követik az új szabályzatot. Az a böngésző, amely leáll, amikor az alagút le van állva, egyetlen adatpont, nem bizonyíték arra, hogy minden más út blokkolva van.

Végül tartson fenn olyan helyreállítási módszert, amely nem függ a változtatott hálózati úttól. Egy ismerten jó konfiguráció helyi tárolón és egy dokumentált betöltési mód a zárat szabályzattá teszi; ezek nélkül egy rossz revízió kizárja az adminisztrátort abból a gépből, amelyet védeni kellett volna.