Праверыць, ці працуе падзелены тунель: аднаго выніку IP недастаткова

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

Міф: запыт адраса даказвае пакрыццё

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

Старонка адраса таксама не можа паказаць маршрут, рэзалвер або палітыку адмовы. Стаўцеся да яе як да аднаго назірання, а не як да выраку.

Праверце ўключаны і выключаны паток

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

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

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

Дадайце DNS і сцэнар адмовы

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

curl -s https://ifconfig.me
nslookup intranet.example

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

Паўтарыце пасля змены стану

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

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

Што павінен устанавіць вынік

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

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