Едно VPN најавување на споделен компјутер: кој друг ја добива рутата?
Најавувањето на VPN автентицира едно лице; рутата што ја инсталира е друг опфат. Споредете тунели за целиот домаќин, по корисник и по апликација на споделен компјутер.
Споделувањето работна станица покренува прашање на кое преносниот компјутер за еден корисник никогаш не мора да одговори: откако едно лице ќе го автентицира тунелот, кој друг може да го користи? Најавувањето идентификува субјект, а рутата што ја инсталира опишува опфат, и тие две работи не се истиот објект. Помеѓу нив стојат оперативниот систем, конфигурацијата на клиентот и она што приватната служба го бара сама по себе. Споредувањето на точките на спроведување е единствениот начин да се одговори без погодување.
Едно најавување, неколку опфати
Автентикацијата одговара кој е пуштен. Рутата одговара кои пакети смеат да излезат низ тунелот. Авторизацијата одговара која служба ќе ја прифати настанатата врска, и ниту една од трите не ја подразбира следната.
Тунелот за целиот домаќин е вообичаеното стандардно однесување и ја прави празнината очигледна. Рутата стои во табелата на јадрото, па секој процес што ја користи таа табела може да ја достигне приватната мрежа, вклучително и оној што го стартувал корисник што никогаш не го видел дијалогот за VPN. Тоа не е дефект во тунелот; тоа е значењето на рута за целиот систем. Приватната служба сепак може да ја одбие врската, затоа достапноста и дозволата бараат одделни одговори.
Пишувањето на четирите прашања пред тестирањето спречува прегледот да се сруши во едно од нив.
Каде всушност лежи границата
Четири поставки покриваат повеќето компјутери: тунел за целиот домаќин, врска по корисник, список за дозволени апликации и одделен мрежен именски простор или виртуелна машина.
Секоја ја поставува точката на спроведување на друго место, и разликите се поважни од етикетите. Врската по корисник се спроведува преку дозволите на профилот, а не преку екранот за најавување на работната површина. Списокот за дозволени апликации се спроведува внатре во клиентот, кој одлучува што ќе пренесува. Именскиот простор или VM спроведува на границата на интерфејсот, па процесот внатре воопшто не ја гледа рутата на домаќинот. Бројот на екрани за најавување на компјутерот не кажува ништо за ниту еден од нив.
| 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, дозвола на профил или сесиската политика на порталот. Тој запис го прави следниот чекор прегледен. Тој исто така спречува истото прашање повторно да се отвора секој пат кога некој ќе забележи втор екран за најавување. Достапноста не е авторизација, и ниту едно од двете не е изолација.