Kvifor eit delt TAP VPN framleis treng HTTPS på portalen
Eit TAP VPN autentiserer peer-en, ikkje tenesta bak han. Hald vertsnamnvalidering på portalen og isoler naboar du ikkje stolar på.
To einingar har gyldige VPN-påloggingsdata og deler eitt brua Ethernet-segment. Berre éin av dei skal svara for kontorportalen, og den andre kan framleis gjere krav på portaladressa på det segmentet. Tunnelen gjorde jobben sin: han autentiserte begge peer-ane og krypterte kvar veg til serveren. Det han ikkje gjorde, var å stadfeste kven av dei som eig eit tenestenamn, og det gapet er grunnen til at portalen framleis treng eit gyldig sertifikat.
Kva VPN-en faktisk autentiserer
Eit VPN-handtrykk svarar på eitt spørsmål: kva peer som fullførte denne tunnelen, og med kva nøkkelmateriale. Svaret gjeld per peer og per tilkopling, og det seier ingenting om tenestene som den peer-en eksponerer etterpå. På eit TAP-segment er peer-en ikkje eingong éi adresse, fordi han kan presentere kva som helst MAC og kva som helst IP som brua er viljug til å lære. Autentiseringa stoppar ved endepunktet til tunnelen, ikkje ved applikasjonen.
Skil dei tre spørsmåla i staden for å slå dei saman til eitt. Kvart har sin eigen mekanisme og sin eigen feilmodus.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
Ei utrulling kan ha ein perfekt autentisert tunnel og ei heilt uautentisert teneste bak han. Ho kan òg ha eit validert sertifikat på ein vert der adressa på lag to blir gjort krav på av ein annan peer, og difor høyrer begge kontrollane heime i designet i staden for at den eine erstattar den andre. Tabellen er heile argumentet i tre radar.
ARP på eit delt segment er ikkje ei adressebok
ARP koplar ei IPv4-adresse til ein MAC på den lokale lenka og godtek svar frå kven som helst på den lenka. På eit ettergjevande brua segment kan ein peer gjere krav på ei adresse som høyrer til ei anna eining, og brua vidaresender rammer til den som svara sist. Kryptering av kvar klientveg til serveren endrar ikkje dette, fordi rammene blir dekrypterte før dei når brua. Tillitsgrensa til ARP er segmentet, ikkje tunnelen.
Sjå på kva verten faktisk lærte: ip neigh show viser gjeldande tilordningar og tilstanden deira, og ei oppføring som byter mellom to MAC-adresser under normal drift, er eit symptom som er verdt å undersøke i staden for å avvise. På eit sunt lite segment held slike oppføringar seg stabile lenge.
Peer-isolering og bru-policy finst nettopp for dette tilfellet. Eit ruta design er vanlegvis det betre svaret når tenesta berre er IP, og einingane ikkje har nokon grunn til å sjå kvarandre sine rammer i det heile.
Hald sertifikatvalideringa der tenesta er
TLS-en til applikasjonen svarar på spørsmålet tunnelen ikkje kan: er dette tenesta eg ville nå. Nettlesaren kontrollerer vertsnamnet mot sertifikatet, og den kontrollen er den einaste delen av kjeda som namngir portalen i staden for peer-en.
Undersøk kva serveren presenterer før du avgjer at åtvaringa er kosmetisk. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal skriv ut kjeda og dei alternative namna til subjektet. Viss namnet du skreiv inn, manglar på lista, er åtvaringa riktig, og det er sertifikatet som må rettast. Å lære brukarar å klikke seg forbi gjer ein fungerande kontroll til dekorasjon.
OpenVPN-bruveiledninga skildrar Ethernet-modellen og policyvala rundt han, og det er den riktige referansen for kva segmentet skal tillate. Les henne før du lempar på ei bru-regel, fordi modellen ho skildrar, er det kvar kontroll ovanfor føreset.
Avgjer om desse peer-ane i det heile skal dele eit segment
Den billegaste løysinga er vanlegvis å slutte å dele lag to når kravet berre er IP-tilgjenge. Eit ruta VPN gjev kvar klient si eiga adresse, fjernar det delte kringkastingsdomenet og gjer trafikk mellom peer-ar til ei policyavgjerd i staden for ein standard. Portalen har då éi adresse å verne og ingen naboar som kan gjere krav på henne.
Viss segmentet må bli, sjekk serverinnstillinga som lèt klientar nå kvarandre: grep -n client-to-client /etc/openvpn/server.conf. Når ho er deaktivert, går klienttrafikk gjennom serveren og kan filtrerast der. Når ho er aktivert, utvekslar peer-ar rammer direkte gjennom brua, og filtrepunkta dine er brua og brannmuren til verten.
Skriv ned kva vern kvar vert faktisk er avhengig av: tunnelautentisering, segmentisolering eller TLS-en til applikasjonen. Ein vert som er avhengig av alle tre, er greitt. Ein vert som er avhengig av den første og føreset at dei to andre følgde med, er den som endar opp med å levere feil innhald.