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

Паспяховы ўваход кажа, што тунель падняты; ён нічога не кажа пра тое, куды вядзе пэўны адрас.

Адзін адрас, дзве машыны

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

ip route get 192.168.1.20

Гэты пошук называе інтэрфейс і наступны хоп, якія абрала ядро, — гэта другая праверка ў спісе. Параўнайце лакальны і далёкі прэфіксы, перш чым рабіць што-небудзь яшчэ. Калі лакальная LAN — 192.168.1.0/24 і далёкі сайт таксама 192.168.1.0/24, то перакрыццё і ёсць знаходкай, і ніякая опцыя кліента гэтага не выправіць.

Перанумаруйце бок, які вы кантралюеце

Асабісты маршрутызатар звычайна прасцей перанесці. Выберыце дыяпазон, які не сутыкаецца з далёкімі сеткамі, якія вы фактычна выкарыстоўваеце, і ўлічыце, што 10.x.x.x таксама не аўтаматычна свабодны, бо шмат сайтаў яго ўжывае. Сплануйце змену: арэнды DHCP, зарэзерваваныя адрасы, чэргі друку і ўсё з жорстка зашытым адрасам патрабуюць увагі. Рабіце перанумарацыю ў акне, калі можаце аднавіць маршрутызатар без VPN.

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

Калі ні адзін бок не можа змяніцца

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

Прыватныя дыяпазоны адрасоў застаюцца прыватнымі; праблема ў паўторным выкарыстанні, а не ў саміх дыяпазонах.

Дакажыце, якая машына адказала

openssl s_client -connect 192.168.1.20:443 -servername office.example 2>/dev/null | openssl x509 -noout -subject

Пасля любой змены праверце офісны рэсурс і лакальныя прылады разам. Калі знаёмая хатняя прылада адказвае там, дзе павінен быць офісны сервер, або сертыфікат TLS указвае няправільны хост, спыніцеся і вызначце прызначэнне, перш чым працягваць. Атрыманне адказу з гэтага адраса не ўстанаўлівае, якая машына яго адправіла. Праверка суб'екта сертыфіката — адзін з нешматлікіх надзейных сігналаў, даступных у гэты момант.

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

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

Падобныя артыкулы