La regulo ŝajnas ĝusta kaj la printilo plu rifuzas. Aŭ la printilo funkcias kaj la sama uzanto atingas ankaŭ la dosier-servilon, kio estas pli malbona. Ambaŭ rezultoj kutime venas el la sama loko: la mallarĝa regulo aldoniĝis al regularo, kiu jam permesis ion pli vastan. Legi la efektivan ordon klarigas la rezulton antaŭ ol skribi iun ajn novan regulon.

La simptomo: la mallarĝa regulo ŝanĝis nenion

Dediĉita VPN-aro, unu printila adreso kaj permesregulo sur TCP 631 estas racia dizajno. Kiam ĝi tute ne donas ŝanĝon, la unua suspekto estu, ke la trafiko neniam atingis tiun regulon. Regulo decidas nur pri trafiko, kiu alvenas al ĝia pozicio en la taksa ordo. La kampoj facile kontroleblas kaj malofte estas la kaŭzo de la malsukceso.

La kontraŭa simptomo pli facile preteratentiĝas. La printa tasko sukcesas, kaj same konekto al dosier-kunhavaĵo, kiun tiu uzanto neniam devis atingi. Tio signifas, ke io pli frua jam permesis la LAN-on.

Ambaŭ simptomoj montras al la ordo, ne al la kampoj de la nova regulo. Unu el ili estas regulo, kiu neniam kongruis, kaj la alia estas regulo, kiu kongruis tro frue.

Kiun regularon la trafiko efektive trafas

pfSense taksas regulojn laŭ interfaco, kaj OpenVPN havas propran langeton, kies reguloj validas por ĉiu servila kaj klienta kazo. Tiuj reguloj prilaboriĝas antaŭ la reguloj atribuitaj al difinita OpenVPN-interfaco. Do vasta permeso lasita sur la OpenVPN-langeto validas ankaŭ por ĉi tiu uzanto, kion ajn diras la interfaca langeto. Kopiu tiun ordon en la ŝanĝan protokolon, por ke la revizio povu kontroli ĝin sen malfermi la GUI.

Tial nova mallarĝa permeso ne povas forpreni aliron. Fajroŝirmilaj reguloj aldonas permeson kaj ne forprenas ĝin de pli frua kongruo.

Legu la efektivan liston de supre kaj haltu ĉe la unua regulo, kiu kongruas kun la trafiko. Tiu unua kongruo estas la decido, kaj ĉio sub ĝi estas neatingebla por tiu fluo.

Skribu la permesregulon el la printa tasko

Komencu per la tasko, ne per la printilo. La uzanto bezonas la printservon sur la printila adreso, do la regulo nomas tiun adreson, tiun protokolon kaj tiun pordon. Aliaso por la VPN-aro kaj aliaso por la printilo tenas la regulon legebla.

Rezistu aldonon de malkovraj aŭ administraj pordoj por ĝojigi asistanton. Regulo, kiu allasas la tutan printilon, estas alia politiko ol tiu, kiu allasas printovicon.

Konservu la propran aŭtentikigon de la printilo. Reta permeso ne anstataŭas ĝin. Konto je la nivelo de la vico estas la ĝusta kontrolo pri tio, kiu rajtas presi kion.

Ses valoroj portas la tutan intencon: permeso kiel ago, IPv4 kiel familio, TCP kiel protokolo, la ar-aliaso kiel fonto, la printila aliaso kiel celo kaj 631 kiel pordo. Io ajn preter tiuj ses estas alia politiko ol la petita.

Donu al la kliento vojon sen LAN-permeso

La kliento bezonas itineron al la printila adreso, kaj la oficeja flanko bezonas respondan vojon al la VPN-aro. Puŝi unu solan /32 tenas la klientan agordon mallarĝa, kio helpas la diagnozon. Ĝi ne estas la aŭtoriga limo, ĉar kliento povas mem aldoni itinerojn.

Se la vico estas adresata per nomo, difinu la dependon de la solvilo aparte. Permesi la tutan LAN-on por ke unu nomo solviĝu estas multe pli granda ŝanĝo ol la tasko postulas.

Elektu konscie inter enkursigado reen al la aro kaj tradukado de la fonto. Ambaŭ funkcias, kaj ĉiu kaŝas ion alian de la protokoloj.

Testu la malpermeson same kiel la taskon

Sendu unu malgrandan, ne-senteman taskon de la VPN-uzanto, poste provu LAN-rimedon, kiu devus esti malpermesita, kaj la propran administran paĝon de la fajroŝirmilo. Ĉiuj tri testoj apartenas al la sama sesio, ĉar nur tiel videblas la politiko kiel tuto. Sukcesa printa tasko sola pruvas preskaŭ nenion pri la limo.

Revizu IPv6 kaj iun ajn alian aktivan VPN-vojon antaŭ ol nomi la enkondukon nur-printila. Regularo mallarĝa en unu adresa familio povas esti tute malferma en la alia.

Rilataj artikoloj