Ці выкарыстоўвае ваша VM VPN хаста? Праверце знутры гасцявой сістэмы

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

Тэст павінен выконвацца ўнутры госця, і ён павінен называць тое, што вымераў.

Пачынайце ўнутры госця, а не ў браўзеры хаста

Спачатку запішыце рэжым сеткі гіпервізара: NAT, bridged, host-only або macvtap. У рэжыме NAT хаст маршрутызуе трафік госця, таму тунель хаста можа прымяняцца або не прымяняцца ў залежнасці ад таго, як кліент усталёўвае маршруты. У рэжыме bridged госць з'яўляецца роўным на фізічнай LAN, і тунель хаста не мае значэння. Гэтыя два рэжымы даюць процілеглыя адказы пры адной і той жа канфігурацыі хаста.

Запішыце рэжым да таго, як нешта зменіце, бо ён вызначае, што можа азначаць вынік.

Зрабіце адзін запыт, прызначэнне якога вы ведаеце

Выкарыстайце бясшкодны запыт да сэрвісу, які паведамляе адрас крыніцы, што ён убачыў. Затым праверце ўласнае рашэнне госця аб маршруце для гэтага прызначэння: ip route get 203.0.113.5 друкуе інтэрфейс і шлюз, якія выкарыстае госць.

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

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

Праверце рэзалвер асобна

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

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

На хаспе з systemd resolvectl query называе інтэрфейс і DNS-сервер за адказам. Старэйшыя налады паказваюць сервер у вывадзе dig — а мэта ў любым выпадку ўбачыць, які сервер адказаў, а не проста ці прыйшоў адказ.

Тэстуйце палітыку адмовы, а не толькі поспех

Калі патрабаванне ў тым, каб ніякі трафік не выходзіў па-за тунель, паспяховы запыт нічога не даказвае. Выкарыстайце падтрыманы кліентам кантраляваны тэст адмовы: спыніце тунель падтрыманым спосабам і паглядзіце, ці блакуецца новы запыт госця. Не мяркуйце, што kill switch кліента хаста ахоплівае ўсякую віртуальную схему перанакіравання. Яго дакументаваная сфера — адзінае, на што можна спадзявацца.

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

Запішыце рэжым і сферу

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

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