Mac PF VPN-ŝloso: reteja politiko, ne liverenda funkcio
Packet Filter ne estas subtenata API por distribuitaj produktoj. Donu posedanton al la regulkomplekto, nomu ĉiun escepton kaj testu la transirojn.
Ĝi funkcias sur via Mac, do ĝi aspektas kiel io, kion vi povas transdoni al uzantoj. Tiu supozo estas la unua afero, kiun vi devas perdi. La TN3165 de Apple klare diras, ke Packet Filter ne estas subtenata API por ĝenerale distribuitaj produktoj, kaj ĝi prezentas privilegian, kontrolitan retejan administradon kiel la racian kazon. VPN-ŝloso konstruita sur PF do estas loka operacia politiko kun posedanto, ne funkcio, kiun vi povas liveri ene de programo.
PF ne estas pakaĵa surfaco
La distingo ne estas akademia. Distribuita produkto, kiu dependas de PF, heredas ĉiun ŝanĝon, kiun Apple faras al ĝi, ĉiun konflikton kun alia ilo, kiu ankaŭ skribas regulojn, kaj neniun subtenan promeson, ke la aranĝo daŭre funkcios. Retejo, kiu administras siajn proprajn maŝinojn, havas alian rilaton: ĝi povas dokumenti la dependecon, testi ĝin kontraŭ ĉiu OS-eldono kaj akcepti la prizorgadon.
Iuj instalaj konsiloj transiras limon, kiun indas nomi. Anstataŭigi la tutan sistemregularon por ke unu ankro ŝarĝiĝu, redakti la sisteman lanĉan agordon de Apple aŭ malŝalti System Integrity Protection ne estas akcepteblaj postuloj por reuzebla recepto. Se publikigita gvidilo bezonas iun el tiuj, ĝi priskribas laboratorion, ne deplojeblan politikon.
Skribu la eliran intencon antaŭ la sintakso
Decidu, kio estas permesata, antaŭ ol elekti eĉ unu ŝlosilvorton. Kutime devas ekzisti tri vojoj: la propra transporto de la VPN-kliento al sia servilo, la trafiko de la protektita aplikaĵo ene de la tunelo kaj ĉio, kion agordo aŭ lokaj servoj vere bezonas kiel rektan vojon.
Donu al ĉiu proponita escepto celon, transporton kaj posedanton. Permesi ĉiujn havenojn al finpunkto permesas multe pli ol la ununura transporto, kiun la tunelo uzas, kaj la plia eksponiĝo venas sen ke iu decidis, ke ĝi estu. Permesi publikan solvilon estas la sama kaptilo en pli amika kostumo: ĝi kreas rektan DNS-vojon eĉ dum la tunelo estas malaktiva, do nomserĉoj ankoraŭ likas.
| Path | Destination | Owner |
|---|---|---|
| VPN transport | Gateway address, one UDP port | Network team |
| Tunnel traffic | Internal prefixes | Application owner |
| Resolver exception | Named internal resolver | Security team |
La utila testo por escepto estas ĉu vi povas nomi la personon, kiu petis ĝin, kaj la fiaskon, kiun ĝi malhelpas. Se neniu el ambaŭ respondoj ekzistas, la regulo probable estas provizora solvo por erara agordo, kiu alie restus nevidebla.
utun-numeroj ne estas identeco
MacOS kreas tunelajn interfacojn kiel utun-aparatojn, kaj la numero atribuita al via VPN ne estas stabila tra restartigoj, rekonektoj aŭ la ĉeesto de alia kliento. Regulo, kiu listigas plurajn divenitajn numerojn, ne estas politiko; ĝi estas momentfoto de unu posttagmezo.
Ankru la regulon al io, kio identigas la celatan provizanton: la adresplano, kiun la tunelo atribuas, la procezo, kiu posedas la interfacon, aŭ agordo, kiun la VPN-kliento mem prizorgas. Poste registru, kiel tiu identigo funkcias, ĉar la persono, kiu revizios la regulon post jaro, ne havos vian ŝelhistorion.
Faru la ŝarĝitan politikon atribuebla
Ankra nomo organizas regulojn; ĝi ne pruvas, ke la efektiva politiko estas tiu, kiun vi intencis. Prioritato inter ankroj, reguloj ŝarĝitaj de alia programaro kaj ekzistanta stato povas ĉiuj ŝanĝi la rezulton. Reviziu la efektivan aron kun ĉiu ajn alia, kiu posedas PF sur tiu maŝino, kaj dokumentu la posedrajton en la sama loko kiel la agordon. Du posedantoj redaktantaj malsamajn ankrojn kun malsamaj supozoj estas la ordinara maniero, kiel ŝloso akiras truon.
Tenu la regulkomplekton en la subtenata agorda vojo de la retejo, versiigu ĝin kaj notu, kiuj macOS-eldonoj estis testitaj. Ŝanĝo aplikata permane kaj memorata de unu persono ne estas prizorgata infrastrukturo, kion ajn diras la dosierkapo.
Testu la transirojn, ne la konektitan staton
Ekrankopio farita dum la tunelo estas aktiva pruvas preskaŭ nenion. Paŝu la statojn anstataŭe: lanĉo antaŭ iu ajn konekto, funkcianta tunelo, tunelo falanta sen averto, intenca malkonekto kaj movo de Wi-Fi al hotspot. Ĉiu stato havas sian propran respondon, kaj la interesaj estas la fiaskoj, ne la feliĉa vojo.
En ĉiu stato registru, kio estas intence atingebla. Kontrolu IPv4 kaj IPv6 aparte, testu nomrezolucion kaj inkluzivu fluon, kiu jam estis establita antaŭ la transiro, ĉar ekzistantaj konektoj ne ĉiam sekvas la novan politikon. Retumilo, kiu fiaskas dum la tunelo estas malaktiva, estas unu datenpunkto, ne pruvo, ke ĉiu alia vojo estas blokita.
Fine, tenu rekuperan metodon, kiu ne dependas de la reta vojo, kiun vi ŝanĝas. Konata-bona agordo sur loka konservado kaj dokumentita maniero ŝarĝi ĝin transformas ŝloson en politikon; sen ili, unu malbona revizio ŝlosas la administranton for de la maŝino, kiu devis esti protektita.