Miksi jaettu TAP VPN tarvitsee edelleen HTTPS:n portaalissa
TAP VPN todentaa vertaisensa, ei sen takana olevaa palvelua. Pidä isäntänimen vahvistus portaalissa ja eristä naapurit, joihin et luota.
Kahdella laitteella on kelvolliset VPN-tunnukset, ja ne jakavat yhden sillatun Ethernet-segmentin. Vain yhden niistä pitäisi vastata toimiston portaalista, ja toinen voi silti vaatia portaalin osoitetta kyseisessä segmentissä. Tunneli teki tehtävänsä: se todensi molemmat vertaiset ja salasi jokaisen reitin palvelimelle. Mitä se ei tehnyt, oli varmistaa, kumpi niistä omistaa palvelunimen, ja juuri tämä aukko on syy siihen, että portaali tarvitsee edelleen kelvollisen varmenteen.
Mikä on se, minkä VPN oikeastaan todentaa
VPN-kättely vastaa yhteen kysymykseen: mikä vertainen päätti tämän tunnelin ja millä avainmateriaalilla. Tämä vastaus koskee vertaista ja yhteyttä kohti eikä kerro mitään palveluista, joita kyseinen vertainen sen jälkeen tarjoaa. TAP-segmentissä vertainen ei ole edes yksi osoite, koska se voi esittää mitä tahansa MAC-osoitetta ja IP-osoitetta, jonka silta on valmis oppimaan. Todennus päättyy tunnelin päätepisteeseen, ei sovellukseen.
Erottele kolme kysymystä sen sijaan, että sulauttaisit ne yhdeksi. Jokaisella on oma mekanisminsa ja oma epäonnistumistapansa.
| 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 |
Käyttöönotossa voi olla täydellisesti todennettu tunneli ja sen takana täysin todentamaton palvelu. Siinä voi myös olla vahvistettu varmenne isännällä, jonka toisen kerroksen osoitetta toinen vertainen vaatii, ja siksi molemmat valvonnat kuuluvat suunnitteluun sen sijaan, että toinen korvaisi toisen. Taulukko on koko perustelu kolmessa rivissä.
ARP jaetussa segmentissä ei ole hakemisto
ARP yhdistää IPv4-osoitteen MAC-osoitteeseen paikallisella linkillä ja hyväksyy vastauksia keneltä tahansa sillä linkillä. Sallivassa sillatussa segmentissä vertainen voi vaatia osoitetta, joka kuuluu toiselle laitteelle, ja silta välittää kehykset sille, joka vastasi viimeksi. Jokaisen asiakasreitin salaus palvelimelle ei muuta tätä, koska kehykset puretaan ennen kuin ne saavuttavat sillan. ARP:n luottamusraja on segmentti, ei tunneli.
Katso, mitä isäntä todella oppi: ip neigh show luettelee nykyiset yhdistämiset ja niiden tilan, ja merkintä, joka vaihtuu normaalin toiminnan aikana kahden MAC-osoitteen välillä, on oire, joka kannattaa tutkia sen sijaan, että sen sivuuttaisi. Terveessä pienessä segmentissä tällaiset merkinnät pysyvät vakaina pitkiä aikoja.
Vertaisten eristäminen ja sillan käytäntö ovat olemassa juuri tätä tapausta varten. Reititetty suunnittelu on yleensä parempi vastaus, kun palvelu on vain IP ja laitteilla ei ole mitään syytä nähdä toistensa kehyksiä.
Pidä varmenteen vahvistus siellä, missä palvelu on
Sovelluksen TLS vastaa kysymykseen, johon tunneli ei pysty: onko tämä se palvelu, johon halusin päästä. Selain tarkistaa isäntänimen varmennetta vasten, ja tämä tarkistus on ainoa osa ketjua, joka nimeää portaalin eikä vertaista.
Tarkastele, mitä palvelin esittää, ennen kuin päätät, että varoitus on kosmeettinen. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal tulostaa ketjun ja subjektin vaihtoehtoiset nimet. Jos kirjoittamasi nimi puuttuu listalta, varoitus on oikea ja varmenne on se, joka pitää korjata. Käyttäjien opettaminen ohittamaan se muuttaa toimivan valvonnan koristeeksi.
OpenVPN:n sillanopas kuvaa Ethernet-mallin ja sen ympärillä olevat käytäntövaihtoehdot, ja se on oikea lähde sille, mitä segmentin on tarkoitus sallia. Lue se ennen sillan säännön löysäämistä, koska kuvattu malli on se, mitä jokainen yllä oleva tarkistus olettaa.
Päätä, pitäisikö näiden vertaisten ylipäätään jakaa segmentti
Halvin korjaus on yleensä lopettaa toisen kerroksen jakaminen, kun vaatimus on vain IP-tavoitettavuus. Reititetty VPN antaa jokaiselle asiakkaalle oman osoitteensa, poistaa jaetun lähetysverkkotunnuksen ja muuttaa vertaisten välisen liikenteen käytäntöpäätökseksi oletusarvon sijaan. Silloin portaalilla on yksi osoite suojattavana eikä naapureita, jotka voisivat vaatia sen.
Jos segmentin on jäätävä, tarkista palvelinpuolen asetus, joka sallii asiakkaiden tavoittaa toisensa: grep -n client-to-client /etc/openvpn/server.conf. Kun se on poistettu käytöstä, asiakasliikenne kulkee palvelimen kautta ja voidaan suodattaa siellä. Kun se on käytössä, vertaiset vaihtavat kehyksiä suoraan sillan kautta, ja suodatuspisteesi ovat silta ja isännän palomuuri.
Kirjoita muistiin, mihin suojauksiin kukin isäntä todella luottaa: tunnelin todennus, segmentin eristys vai sovelluksen TLS. Isäntä, joka luottaa kaikkiin kolmeen, on kunnossa. Isäntä, joka luottaa ensimmäiseen ja olettaa kahden muun tulleen sen mukana, on se, joka lopulta tarjoilee väärää sisältöä.