Jagatud VPN-konto: seadmepiirang ei ole klientide isoleerimine

Kaheksa samaaegset ühendust on arv litsentsilehelt ja see ei ütle midagi selle kohta, mida need kaheksa seadet üksteisele teha saavad. Jagatud sisselogimine võib eksisteerida koos seansipõhiste võtmetega ja ka koos lüüsiga, mis edastab hea meelega ühe kliendi liiklust teisele. Viga on pidada kontot turvapiiriks. Esitage selle asemel neli eraldi küsimust: mis osteti, mis kaitseb tunnelit, mis tohib partnerite vahel liikuda ja mis võib kohaliku lüli maha võtta.

Mida ühendusluba tegelikult lubab

Seadmepiirang loeb, mitu seanssi teenusepakkuja ühe tellimuse kohta vastu võtab. See on kaubanduslik ja operatiivne kontroll, mitte väide identiteedi ega isoleerimise kohta. Mõned pakkujad väljastavad ühe konto all igale seadmele eraldi sertifikaadi, teised kasutavad iga ühenduse jaoks uuesti ühte mandaati. Erinevus ilmneb tühistamisel, sest eraldi mandaadid lasevad teil ühe seadme ära lõigata, jagatud mandaat aga ei jäta teile sellist võimalust.

Lugege, kuidas pakkuja mandaate väljastab, enne kui eeldate midagi võtmete eraldamise kohta. Konto nimi ise ei paljasta sellest midagi.

Kontrollige, kas lüüs edastab klientide vahel

Jõudmine partnerite vahel on serveripoolne otsus. Jaotises OpenVPN puudub asjaomane lüliti, kui seda konfiguratsioonis pole, kuid kaasaegne andmetasandi mahalaadimine muudab, kus reeglit rakendatakse.

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Konfiguratsioon ilma selle direktiivita jätab partneritevahelise liikluse hosti tulemüüri hooleks, mis võib seda siiski lubada. Kui mahalaadimine on aktiivne, haldab tunneliliidest tuum, mitte kasutajaruumi protsess, seega kontrollige reeglilugejaid, selle asemel et faili usaldada. Tunneliaadresside vahel edastatava liikluse blokeerimine isoleerib kliendid, puutumata nende juurdepääsu lüüsile. Kinnitage seda ühest kliendist teise juures oleva teenuse poole tehtud prooviga, nii enne reeglit kui ka pärast.

Kaitske seanssi enne partnereid

Tunnelikaitse ja partnerijuurdepääs on erinevad omadused ning tugev šiffer ei tähenda isoleerimist. TLS-režiimis tuletab iga klient oma seansivõtmed, nii et üks klient ei saa teise liiklust lugeda ka siis, kui lüüs seda edastab. Vana staatilise võtmega lahendus jagab kõigi vahel ühte võtit, mistõttu on sisselogimise korduskasutusel seal palju hullemad tagajärjed. Uurige konfigureeritud režiimi, mitte turunduslehte, ja otsustage seejärel, kas konto jagamine sobib asjaomaste andmetega.

Teenuse autentimine igas hostis on endiselt oluline, sest tunnel tõestab vaid, et klient jõudis võrku, mitte seda, et ta peaks jõudma kindla deemonini.

Kohalikud Wi-Fi-tõrked ei ole VPN-i kompromiteerimine

Katkenud ühendus tõestab, et kohalik lüli ebaõnnestus, mitte et keegi murdis tunneli. Häired, kaotatud DHCP-rendileping ja rändlusega üleminek lõpetavad seansi, puutumata mandaate või šifriteksti. Käsitlege katkestust kättesaadavuse leiuna ja hoidke seda eraldi konfidentsiaalsuse ja partnerijuurdepääsu leidudest. Kus kohalik võrk ei ole usaldusväärne, kaitske liiklust otsast lõpuni, selle asemel et toetuda ainult tunnelile.

Kirjutage üles neli vastust: luba, võtmemudel, partneripoliitika ja sõltuvus kohalikust lülist. See kirje muudab ebamäärase mure jagatud konto pärast konkreetseteks kontrollideks.