Hvorfor en delt TAP VPN stadig har brug for HTTPS på portalen
En TAP VPN autentificerer peer'en, ikke tjenesten bag den. Behold værtsnavnsvalidering på portalen, og isoler naboer, du ikke stoler på.
To enheder har gyldige VPN-legitimationsoplysninger og deler et enkelt broet Ethernet-segment. Kun én af dem skal svare for kontorportalen, og den anden kan stadig gøre krav på portalens adresse på det segment. Tunnelen gjorde sit arbejde: den autentificerede begge peers og krypterede hver vej til serveren. Det, den ikke gjorde, var at bekræfte, hvem af dem der ejer et tjenestenavn, og det hul er grunden til, at portalen stadig har brug for et gyldigt certifikat.
Hvad VPN'en faktisk autentificerer
Et VPN-håndtryk besvarer ét spørgsmål: hvilken peer gennemførte denne tunnel, og med hvilket nøglemateriale. Det svar er pr. peer og pr. forbindelse og siger intet om de tjenester, som den peer eksponerer bagefter. På et TAP-segment er peer'en ikke engang én adresse, fordi den kan præsentere enhver MAC og enhver IP, som broen er villig til at lære. Autentificering stopper ved tunnelens endepunkt, ikke ved applikationen.
Adskil de tre spørgsmål i stedet for at slå dem sammen til ét. Hvert har sin egen mekanisme og sin egen fejlmåde.
| 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 udrulning kan have en perfekt autentificeret tunnel og en helt uautentificeret tjeneste bag den. Den kan også have et valideret certifikat på en vært, hvis lag-to-adresse gøres krav på af en anden peer, og derfor hører begge kontroller hjemme i designet i stedet for at den ene erstatter den anden. Tabellen er hele argumentet i tre rækker.
ARP på et delt segment er ikke en adressebog
ARP mapper en IPv4-adresse til en MAC på det lokale link og accepterer svar fra enhver på det link. På et eftergivende broet segment kan en peer gøre krav på en adresse, der tilhører en anden enhed, og broen videresender rammer til den, der svarede senest. Kryptering af hver klientvej til serveren ændrer ikke det, fordi rammer dekrypteres, før de når broen. ARP's tillidsgrænse er segmentet, ikke tunnelen.
Se på, hvad værten faktisk har lært: ip neigh show viser aktuelle mappinger og deres tilstand, og en post, der skifter mellem to MAC-adresser under normal drift, er et symptom, der er værd at undersøge i stedet for at afvise. På et sundt lille segment forbliver disse poster stabile i lange perioder.
Peer-isolering og bro-politik findes netop til dette tilfælde. Et routet design er normalt det bedre svar, når tjenesten kun er IP, og enhederne ikke har nogen grund til at se hinandens rammer overhovedet.
Behold certifikatvalideringen der, hvor tjenesten er
Applikationens TLS besvarer det spørgsmål, tunnelen ikke kan: er dette den tjeneste, jeg ville nå. Browseren kontrollerer værtsnavnet mod certifikatet, og den kontrol er den eneste del af kæden, der navngiver portalen i stedet for peer'en.
Undersøg, hvad serveren præsenterer, før du beslutter, at advarslen er kosmetisk. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal udskriver kæden og subjektets alternative navne. Hvis det navn, du skrev, ikke findes på listen, er advarslen korrekt, og det er certifikatet, der skal rettes. At lære brugere at klikke igennem gør en fungerende kontrol til dekoration.
OpenVPN-broguiden beskriver Ethernet-modellen og politikindstillingerne omkring den, og det er den rigtige reference for, hvad segmentet skal tillade. Læs den, før du lemper en broregel, fordi den model, den beskriver, er det, enhver kontrol ovenfor forudsætter.
Beslut, om disse peers overhovedet skal dele et segment
Den billigste løsning er normalt at holde op med at dele lag to, når kravet kun er IP-rækkevidde. En routet VPN giver hver klient sin egen adresse, fjerner det delte broadcast-domæne og gør peer-til-peer-trafik til en politisk beslutning i stedet for en standard. Portalen har så én adresse at beskytte og ingen naboer, der kan gøre krav på den.
Hvis segmentet skal blive, skal du kontrollere serverindstillingen, der lader klienter nå hinanden: grep -n client-to-client /etc/openvpn/server.conf. Når den er deaktiveret, går klienttrafik gennem serveren og kan filtreres der. Når den er aktiveret, udveksler peers rammer direkte gennem broen, og dine filtreringspunkter er broen og værtens firewall.
Skriv ned, hvilke beskyttelser hver vært faktisk er afhængig af: tunnelautentificering, segmentisolering eller applikationens TLS. En vært, der afhænger af alle tre, er fin. En vært, der afhænger af den første og antager, at de to andre fulgte med, er den, der ender med at levere det forkerte indhold.