Едно влизане във VPN на споделен компютър: кой друг получава маршрута?
Влизането във VPN удостоверява един човек; маршрутът, който то инсталира, е различен обхват. Сравнете тунели за целия хост, за потребител и за приложение на споделена машина.
Споделянето на работна станция повдига въпрос, на който еднопотребителският лаптоп никога не трябва да отговаря: след като един човек удостовери тунела, кой друг може да го използва? Влизането идентифицира субект, а маршрутът, който то инсталира, описва обхват и тези две неща не са един и същ обект. Между тях стоят операционната система, конфигурацията на клиента и това, което частната услуга изисква сама по себе си. Сравняването на точките на прилагане е единственият начин да се отговори на въпроса без догадки.
Едно влизане, няколко обхвата
Удостоверяването отговаря кой е допуснат. Маршрутът отговаря кои пакети могат да напуснат през тунела. Оторизацията отговаря коя услуга ще приеме получената връзка и нито едно от трите не предполага следващото.
Тунелът за целия хост е обичайната настройка по подразбиране и прави разликата очевидна. Маршрутът стои в таблицата на ядрото, така че всеки процес, който използва тази таблица, може да достигне частната мрежа, включително такъв, стартиран от потребител, който никога не е виждал диалога за VPN. Това не е дефект в тунела; това означава маршрут за цялата система. Частната услуга все още може да откаже връзката, затова достижимостта и разрешението изискват отделни отговори.
Записването на четирите въпроса преди тестване не позволява прегледът да се срине в един от тях.
Къде всъщност стои границата
Четири подредби покриват повечето машини: тунел за целия хост, връзка за потребител, списък за разрешени приложения и отделно мрежово пространство от имена или виртуална машина.
Всяка поставя точката на прилагане на различно място и разликите са по-важни от етикетите. Връзката за потребител се прилага от разрешенията на профила, а не от екрана за вход на работния плот. Списъкът за разрешени приложения се прилага вътре в клиента, който решава какво ще пренася. Пространството от имена или ВМ прилага на границата на интерфейса, така че процес отвътре изобщо не вижда маршрута на хоста. Броят на екраните за вход на машината не казва нищо за нито една от тях.
| Arrangement | Enforced by | Who can use the path |
|---|---|---|
| Host-wide tunnel | The routing table | Any local process using that table |
| Per-user connection | Profile permission list | Only the listed accounts |
| Per-app allowlist | The VPN client itself | Only the selected applications |
| Namespace or VM | The interface boundary | Only processes inside it |
Четенето на таблицата ред по ред показва, че истинският въпрос не е дали има изолация, а къде е реализирана.
Сравнете четири точки на прилагане
В Linux маршрутната таблица е първото, което трябва да се провери, защото тунелът за целия хост се появява там, а пространството от имена не. Изпълняването на търсенето като втория потребител е стъпката, която хората пропускат; отговорът се различава от този, който са получили като себе си, и това обяснява доклада.
Следващите две проверки гледат политиката, а не маршрутизацията. Правило на защитната стена, което съвпада с UID, се отнася за локално генериран трафик, така че може да раздели двама потребители на един хост, дори когато и двамата споделят маршрута. Профил на връзка с явен списък с разрешения се прилага от мрежовия мениджър при активиране. Нито една проверка не изисква тунелът да се промени, затова си струва да се направят, преди да се препроектира каквото и да е.
ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuidАко второто търсене показва маршрута на тунела, границата не е там, където проектирането е предполагало.
Правилата за едновременни сесии са отделен контрол
Шлюзовете често ограничават колко сесии може да поддържа един акаунт и това ограничение няма нищо общо с локалните потребители. То ограничава акаунта, така че втори човек, който влезе със същите данни, може да прекрати тунела на първия.
Прочетете отказа, преди да предположите локален проблем с изолацията. Ограничението на сесиите произвежда прекъсване на шлюза, докато проблемът с обхвата произвежда работещ тунел, който просто не пренася трафика на другия потребител. Тези два симптома водят до напълно различни поправки. Запазете точното съобщение на клиента, защото то обикновено назовава правилото. Поискайте от собственика на профила одобрения работен процес, вместо да заобикаляте ограничението.
Виртуалната машина не освобождава никого от това правило и добавя свой собствен дизайн на мрежата и идентификационните данни.
Тествайте контекста, който ви е важен
Тествайте предвидения потребител и приложение, след което тествайте контекст, който трябва да бъде отказан. Преглед, който доказва само, че първоначалната парола работи, е тествал удостоверяването и нищо друго.
sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'Запишете точката на прилагане до всеки резултат: маршрутната таблица, правило на UID, разрешение на профил или сесийната политика на шлюза. Този запис прави следващата промяна проверима. Той също спира същият въпрос да се отваря отново всеки път, когато някой забележи втори екран за вход. Достижимостта не е оторизация и нито едно от двете не е изолация.