Пошта дасягае сервера без VPN: дзе ўжываць правіла

Пошта працягвае апытваць сервер, а VPN выключаны, але ўліковы запіс усё яшчэ сінхранізуецца. Праграма робіць тое, на што была наладжана; нішто ў звычайным профілі пошты не кажа, што сервер дасяжны толькі праз тунель. Гэта пакідае дзве розныя патрабаванні, і іх лёгка зблытаць: служба павінна адмаўляць прамым кліентам або Mac увогуле не павінен рабіць спробу.

Выберыце патрабаванне, перш чым выбіраць прадукт. Правіла сервера і правіла кліента церпяць няўдачу ў розных месцах, даюць розныя доказы і належаць розным уладальнікам. Ужываць абодва слушна, калі абодва сцвярджэнні праўдзівыя, але адно не замяняе другое. Абодва патрабаванні законныя; проста яны не адзін і той жа кантроль.

Сімптом выглядае як Mac, але ўцечка можа быць на серверы

Калі пошта сінхранізуецца па-за тунелем, пачніце з таго, што сервер прымае. Калі слухач пошты адказвае на прамое злучэнне з інтэрнэту, ніводная налада зручнасці на баку кліента гэты факт не зменіць. Mac паводзіць сябе звычайна адносна службы, якая ўсё яшчэ адкрытая.

Спытайце ў адміністратара пошты, які адрас крыніцы бачыць служба. Шлюз VPN, зваротны проксі або балансіроўшчык нагрузкі могуць змяняць адрас кліента, таму пул адрасоў у канфігурацыі VPN можа не супадаць з тым, што прыходзіць у працэс пошты. Правіла, напісанае супраць няправільнай крыніцы, альбо блакуе ўсіх, альбо не блакуе нікога.

Гэты адказ таксама пакажа, ці можа служба ўвогуле адрозніваць кліентаў VPN. Калі кожны кліент прыходзіць праз адзін і той жа адрас проксі, допуск па крыніцы не можа іх падзяліць, і патрабаванне трэба перанесці на аўтэнтыфікацыю або на бок кліента.

Допуск на серверы: адмаўляйце крыніцы, а не праграме

Міжсеткавы экран хоста або сеткі можа абмежаваць слухач пошты зацверджанымі дыяпазонамі крыніц, пакідаючы аўтэнтыфікацыю і TLS без змен. Умова правіла, якая супастаўляе аддаленыя адрасы, падсеткі або дыяпазоны, — звычайны будаўнічы блок; дакладны сінтаксіс належыць прадукту міжсеткавага экрана сервера, а не паштовай праграме.

Гэта самая моцная мяжа, калі патрабаванне гучыць як «служба не павінна абслугоўваць прамых кліентаў». Яно трымаецца, нават калі карыстальнік усталюе іншую паштовую праграму, бо адмова адбываецца да аўтэнтыфікацыі. Яно таксама перажывае Mac, які ігнаруе сваю палітыку VPN.

Яго мяжа не менш важная. Адхіленае злучэнне даказвае, што служба адмовіла ў сеансе; яно не даказвае, што Mac не рабіў спробы. Разрозненне DNS, TCP SYN да папярэдняга балансіроўшчыка нагрузкі і паўтор пасля збою — усё гэта можа адбыцца да таго, як правіла сервера будзе дасягнута. Калі патрабаванне тычыцца раскрыцця спроб, а не доступу, допуск на серверы — гэта толькі палова кантролю.

Прымус на баку кліента: блакуйце спробу, а не толькі тунель

Правіла на баку кліента павінна забараняць трафік, а не проста запускаць тунель пры адкрыцці пошты. Трыгер актывацыі для паштовага дамена можа ўзняць VPN у патрэбны момант, але ён не вызначае, што адбываецца, пакуль тунель не працуе або пасля яго збою.

Выкарыстоўвайце падтрыманую палітыку блакавання прадукту канчатковай кропкі і свядома вызначце яе ахоп. Правіла ўзроўню праграмы ахоплівае кожны ўліковы запіс у гэтай паштовай праграме, уключаючы асабістыя. Правіла ўзроўню прызначэння павінна назваць канчатковыя кропкі IMAP, адпраўкі і аўтэнтыфікацыі працоўнага ўліковага запісу і працягваць працаваць, калі гэтыя адрасы змяняюцца.

Ахапіце абодва сямействы адрасоў і існуючыя сеансы. Палітыка, якая блакуе новыя злучэнні IPv4, пакідаючы IPv6 або ўсталяваны сокет без увагі, дае перарывістыя сінхранізацыі, якія выглядаюць выпадковымі. Змены сеткі і цыклы сну — частка таго ж тэсту.

Правілы ўзроўню праграмы і прызначэння маюць розны маштаб наступстваў

Блакаванне ўзроўню праграмы проста ўявіць: ніводны трафік з Пошты не выходзіць без тунеля. Яно таксама грубае, бо тая ж праграма можа ўтрымліваць асабісты ўліковы запіс, які не мае ніякага дачынення да палітыкі. Карыстальнікі заўважаюць гэта першымі і паведамляюць як пра зламаную паштовую праграму.

Блакаванне ўзроўню прызначэння вузейшае і цяжэйшае ў суправаджэнні. Яму патрэбен поўны набор канчатковых кропак, якія выкарыстоўвае ўліковы запіс, уключаючы службы выяўлення і аўтэнтыфікацыі, і працэс іх абнаўлення. Прапусціце адну — уліковы запіс працуе напалову; уключыце лішняе — спыніцца непатрэбная пошта.

Выбірайце па фармулёўцы патрабавання. «Гэты працоўны ўліковы запіс не павінен падключацца напрамую» паказвае на ахоп прызначэння. «Гэты Mac не павінен запускаць пошту па-за VPN» апраўдвае шырэйшае правіла праграмы, калі ўладальнік прымае пабочны эфект для асабістых уліковых запісаў.

Тэстуйце адмову і адсутнасць асобна

З выдзеленым тэставым уліковым запісам падключыцеся праз VPN і пацвердзіце звычайную працу. Затым адключыцеся і праверце двойчы: адзін раз, ці адмаўляе сервер уваходу, і адзін раз, ці Mac увогуле спрабуе злучэнне. Гэта розныя назіранні, і яны належаць розным журналам.

Сачыце за доказамі на баку кліента наконт SYN або запыту DNS падчас адключэння і за журналам сервера наконт адхіленага або прынятага сеансу. Калі сервер адмаўляе, але кліент усё яшчэ спрабуе, правіла сервера працуе, а правіла кліента адсутнічае. Калі кліент не спрабуе, але сервер усё яшчэ прымае іншых кліентаў, мяжа менавіта там, дзе вы яе паставілі.

Запішыце ўладальніка прытрымлівання, адрас крыніцы, які сервер фактычна бачыць, і выкарыстаны тэставы ўліковы запіс. Наступная змена сеткі або проксі можа перамясціць гэтую крыніцу, і нататка з назвай назіранага значэння правяраецца хутчэй, чым яшчэ адзін круг здагадак.