Varför ett delat TAP VPN fortfarande behöver HTTPS på portalen
Ett TAP VPN autentiserar peer-en, inte tjänsten bakom den. Behåll värdnamnsvalideringen på portalen och isolera grannar du inte litar på.
Två enheter har giltiga VPN-inloggningsuppgifter och delar ett enda bryggat Ethernet-segment. Bara en av dem ska svara för kontorsportalen, och den andra kan fortfarande göra anspråk på portaladressen på det segmentet. Tunneln gjorde sitt jobb: den autentiserade båda peer-arna och krypterade varje väg till servern. Det den inte gjorde var att intyga vem av dem som äger ett tjänstenamn, och det gapet är anledningen till att portalen fortfarande behöver ett giltigt certifikat.
Vad VPN:et faktiskt autentiserar
En VPN-handskakning svarar på en fråga: vilken peer som slutförde den här tunneln, och med vilket nyckelmaterial. Svaret gäller per peer och per anslutning, och det säger ingenting om de tjänster som den peer-en sedan exponerar. På ett TAP-segment är peer-en inte ens en enda adress, eftersom den kan presentera vilken MAC som helst och vilken IP som helst som bryggan är villig att lära sig. Autentiseringen stannar vid tunnelns ändpunkt, inte vid applikationen.
Separera de tre frågorna i stället för att slå ihop dem till en. Var och en har sin egen mekanism och sitt eget felmod.
| 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 driftsättning kan ha en perfekt autentiserad tunnel och en helt oautentiserad tjänst bakom den. Den kan också ha ett validerat certifikat på en värd vars adress på lager två görs anspråk på av en annan peer, och därför hör båda kontrollerna hemma i designen i stället för att den ena ersätter den andra. Tabellen är hela argumentet i tre rader.
ARP på ett delat segment är inte en adressbok
ARP kopplar en IPv4-adress till en MAC på den lokala länken och accepterar svar från vem som helst på den länken. På ett eftergivligt bryggat segment kan en peer göra anspråk på en adress som tillhör en annan enhet, och bryggan vidarebefordrar ramar till den som svarade senast. Kryptering av varje klientväg till servern ändrar inte det, eftersom ramar dekrypteras innan de når bryggan. ARP:s förtroendegräns är segmentet, inte tunneln.
Titta på vad värden faktiskt lärde sig: ip neigh show visar aktuella mappningar och deras status, och en post som växlar mellan två MAC-adresser under normal drift är ett symptom som är värt att undersöka i stället för att avfärda. På ett sunt litet segment förblir sådana poster stabila länge.
Peer-isolering och bryggpolicy finns just för det här fallet. En routad design är oftast det bättre svaret när tjänsten bara är IP och enheterna inte har någon anledning att se varandras ramar alls.
Behåll certifikatvalideringen där tjänsten är
Applikationens TLS svarar på frågan som tunneln inte kan: är detta den tjänst jag ville nå. Webbläsaren kontrollerar värdnamnet mot certifikatet, och den kontrollen är den enda delen av kedjan som namnger portalen i stället för peer-en.
Undersök vad servern presenterar innan du avgör att varningen är kosmetisk. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal skriver ut kedjan och subjektets alternativa namn. Om namnet du skrev inte finns i listan är varningen korrekt och det är certifikatet som behöver åtgärdas. Att lära användare att klicka sig förbi gör en fungerande kontroll till dekoration.
OpenVPN:s bryggguide beskriver Ethernet-modellen och policyvalen runt den, och det är den rätta referensen för vad segmentet ska tillåta. Läs den innan du luckrar upp en bryggregel, eftersom modellen den beskriver är vad varje kontroll ovan förutsätter.
Avgör om dessa peer-ar överhuvudtaget ska dela ett segment
Den billigaste åtgärden är oftast att sluta dela lager två när kravet bara är IP-nåbarhet. Ett routat VPN ger varje klient sin egen adress, tar bort den delade broadcast-domänen och gör trafik mellan peer-ar till ett policybeslut i stället för en standard. Portalen har då en adress att skydda och inga grannar som kan göra anspråk på den.
Om segmentet måste vara kvar, kontrollera serverinställningen som låter klienter nå varandra: grep -n client-to-client /etc/openvpn/server.conf. När den är inaktiverad går klienttrafiken genom servern och kan filtreras där. När den är aktiverad utbyter peer-arna ramar direkt genom bryggan, och dina filterpunkter är bryggan och värdens brandvägg.
Skriv ned vilka skydd varje värd faktiskt förlitar sig på: tunnelautentisering, segmentisolering eller applikationens TLS. En värd som förlitar sig på alla tre är okej. En värd som förlitar sig på den första och antar att de andra två följde med är den som till slut levererar fel innehåll.