Hvorfor en delt TAP VPN fortsatt trenger HTTPS på portalen
En TAP VPN autentiserer peer-en, ikke tjenesten bak den. Behold vertsnavnvalidering på portalen og isoler naboer du ikke stoler på.
To enheter har gyldige VPN-påloggingsdata og deler ett broet Ethernet-segment. Bare én av dem skal svare for kontorportalen, og den andre kan fortsatt gjøre krav på portaladressen på det segmentet. Tunnelen gjorde jobben sin: den autentiserte begge peer-ene og krypterte hver vei til serveren. Det den ikke gjorde, var å bekrefte hvem av dem som eier et tjenestenavn, og det gapet er grunnen til at portalen fortsatt trenger et gyldig sertifikat.
Hva VPN-en faktisk autentiserer
En VPN-håndtrykk svarer på ett spørsmål: hvilken peer fullførte denne tunnelen, og med hvilket nøkkelmateriale. Svaret gjelder per peer og per tilkobling, og det sier ingenting om tjenestene som den peer-en eksponerer etterpå. På et TAP-segment er peer-en ikke engang én adresse, fordi den kan presentere hvilken som helst MAC og hvilken som helst IP som broen er villig til å lære. Autentiseringen stopper ved tunnelens endepunkt, ikke ved applikasjonen.
Skille de tre spørsmålene i stedet for å slå dem sammen til ett. Hvert har sin egen mekanisme og sin egen 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 |
En utrulling kan ha en perfekt autentisert tunnel og en helt uautentisert tjeneste bak den. Den kan også ha et validert sertifikat på en vert der adressen på lag to gjøres krav på av en annen peer, og derfor hører begge kontrollene hjemme i designet i stedet for at den ene erstatter den andre. Tabellen er hele argumentet i tre rader.
ARP på et delt segment er ikke en adressebok
ARP kobler en IPv4-adresse til en MAC på den lokale lenken og godtar svar fra hvem som helst på den lenken. På et ettergivende broet segment kan en peer gjøre krav på en adresse som tilhører en annen enhet, og broen videresender rammer til den som svarte sist. Kryptering av hver klientvei til serveren endrer ikke dette, fordi rammene dekrypteres før de når broen. ARPs tillitsgrense er segmentet, ikke tunnelen.
Se på hva verten faktisk lærte: ip neigh show viser gjeldende tilordninger og tilstanden deres, og en oppføring som bytter mellom to MAC-adresser under normal drift, er et symptom som er verdt å undersøke i stedet for å avvise. På et sunt lite segment holder slike oppføringer seg stabile lenge.
Peer-isolasjon og bro-policy finnes nettopp for dette tilfellet. Et rutet design er vanligvis det bedre svaret når tjenesten bare er IP, og enhetene ikke har noen grunn til å se hverandres rammer i det hele tatt.
Behold sertifikatvalideringen der tjenesten er
Applikasjonens TLS svarer på spørsmålet tunnelen ikke kan: er dette tjenesten jeg ville nå. Nettleseren kontrollerer vertsnavnet mot sertifikatet, og den kontrollen er den eneste delen av kjeden som navngir portalen i stedet for peer-en.
Undersøk hva serveren presenterer før du bestemmer at advarselen er kosmetisk. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal skriver ut kjeden og subjektets alternative navn. Hvis navnet du skrev inn, mangler på listen, er advarselen riktig, og det er sertifikatet som må rettes. Å lære brukere å klikke seg forbi gjør en fungerende kontroll til dekorasjon.
OpenVPN-broveiledningen beskriver Ethernet-modellen og policyvalgene rundt den, og det er den riktige referansen for hva segmentet skal tillate. Les den før du lemper på en broregel, fordi modellen den beskriver, er det hver kontroll ovenfor forutsetter.
Bestem om disse peer-ene i det hele tatt skal dele et segment
Den billigste løsningen er vanligvis å slutte å dele lag to når kravet bare er IP-tilgjengelighet. En rutet VPN gir hver klient sin egen adresse, fjerner det delte kringkastingsdomenet og gjør trafikk mellom peer-er til en policybeslutning i stedet for en standard. Portalen har da én adresse å beskytte og ingen naboer som kan gjøre krav på den.
Hvis segmentet må bli, sjekk serverinnstillingen som lar klienter nå hverandre: grep -n client-to-client /etc/openvpn/server.conf. Når den er deaktivert, går klienttrafikk gjennom serveren og kan filtreres der. Når den er aktivert, utveksler peer-er rammer direkte gjennom broen, og filtrepunktene dine er broen og vertens brannmur.
Skriv ned hvilke beskyttelser hver vert faktisk er avhengig av: tunnelautentisering, segmentisolering eller applikasjonens TLS. En vert som er avhengig av alle tre, er greit. En vert som er avhengig av den første og antar at de to andre fulgte med, er den som ender opp med å levere feil innhold.