Miért van szüksége egy megosztott TAP VPN-nek továbbra is HTTPS-re a portálon
A TAP VPN a partnert hitelesíti, nem a mögötte lévő szolgáltatást. Tartsa meg a hosztnév-ellenőrzést a portálon, és izolálja azokat a szomszédokat, amelyekben nem bízik.
Két eszköz érvényes VPN-hitelesítő adatokkal rendelkezik, és egyetlen áthidalt Ethernet-szegmenst oszt meg. Csak az egyiküknek kellene a portál nevében válaszolnia, a másik azonban továbbra is igényt tarthat a portál címére ezen a szegmensen. Az alagút elvégezte a dolgát: hitelesítette mindkét partnert, és titkosította az egyes útvonalakat a szerver felé. Amit nem tett meg: nem igazolta, hogy melyikük birtokol egy szolgáltatásnevet, és éppen ez a hiány az oka annak, hogy a portálnak továbbra is érvényes tanúsítványra van szüksége.
Mit hitelesít valójában a VPN
A VPN-kézfogás egyetlen kérdésre válaszol: melyik partner fejezte be ezt az alagutat, és milyen kulcsanyaggal. Ez a válasz partnernként és kapcsolatonként szól, és semmit sem mond azokról a szolgáltatásokról, amelyeket ez a partner ezután közzétesz. Egy TAP-szegmensen a partner még csak nem is egyetlen cím, mert bármilyen MAC-ot és bármilyen IP-t bemutathat, amelyet a híd hajlandó megtanulni. A hitelesítés az alagút végpontjánál áll meg, nem az alkalmazásnál.
Válassza külön a három kérdést, ahelyett hogy egybe olvasztaná őket. Mindegyiknek megvan a maga mechanizmusa és a maga meghibásodási módja.
| 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 |
Egy telepítésben lehet tökéletesen hitelesített alagút és teljesen hitelesítetlen szolgáltatás mögötte. Lehet érvényesített tanúsítvány olyan hoszton is, amelynek második rétegbeli címére egy másik partner tart igényt, és ezért mindkét ellenőrzésnek helye van a tervezésben, nem pedig az egyiknek a másik helyett. A táblázat három sorban a teljes érv.
Az ARP egy megosztott szegmensen nem címtár
Az ARP egy IPv4-címet MAC-címhez rendel a helyi kapcsolaton, és bárkitől elfogad válaszokat azon a kapcsolaton. Egy engedékeny áthidalt szegmensen egy partner igényt tarthat egy másik eszközhöz tartozó címre, és a híd azoknak továbbítja a kereteket, akik legutóbb válaszoltak. Az egyes kliensútvonalak titkosítása a szerver felé ezen nem változtat, mert a keretek visszafejtése a híd elérése előtt megtörténik. Az ARP bizalmi határa a szegmens, nem az alagút.
Nézze meg, mit tanult valójában a hoszt: a ip neigh show listázza az aktuális leképezéseket és állapotukat, és az a bejegyzés, amely normál működés közben két MAC-cím között vált, olyan tünet, amelyet érdemes kivizsgálni, nem pedig figyelmen kívül hagyni. Egy egészséges kis szegmensen ezek a bejegyzések hosszú ideig stabilak maradnak.
A partnerizoláció és a híd házirendje pontosan erre az esetre létezik. A route-olt kialakítás általában jobb válasz, ha a szolgáltatás csak IP, és az eszközöknek semmi okuk arra, hogy lássák egymás kereteit.
Tartsa a tanúsítvány-ellenőrzést ott, ahol a szolgáltatás van
Az alkalmazás TLS-e arra a kérdésre válaszol, amelyre az alagút nem tud: ez az a szolgáltatás, amelyet el akartam érni. A böngésző a hosztnevet a tanúsítványhoz hasonlítja, és ez az ellenőrzés a lánc egyetlen része, amely a portált nevezi meg, nem a partnert.
Vizsgálja meg, mit mutat be a szerver, mielőtt úgy dönt, hogy a figyelmeztetés kozmetikai. A openssl s_client -connect portal.example.internal:443 -servername portal.example.internal kinyomtatja a láncot és a tárgy alternatív neveit. Ha a beírt név nincs ezen a listán, a figyelmeztetés helyes, és a tanúsítványt kell rendbe tenni. A felhasználók arra tanítása, hogy kattintsanak át rajta, működő ellenőrzést változtat díszítéssé.
Az OpenVPN áthidalási útmutatója leírja az Ethernet-modellt és a körülötte lévő házirend-lehetőségeket, és ez a megfelelő forrás arra, hogy a szegmensnek mit kell engedélyeznie. Olvassa el, mielőtt lazít egy híd-szabályt, mert a leírt modell az, amit a fenti ellenőrzések mindegyike feltételez.
Döntse el, hogy ezeknek a partnereknek egyáltalán meg kell-e osztaniuk egy szegmenst
A legolcsóbb megoldás általában az, hogy felhagy a második réteg megosztásával, amikor a követelmény csak az IP-elérhetőség. A route-olt VPN minden kliensnek saját címet ad, eltávolítja a megosztott broadcast-tartományt, és a partnerek közötti forgalmat házirend-döntéssé teszi az alapértelmezett helyett. Ekkor a portálnak egyetlen védendő címe van, és nincsenek szomszédok, amelyek igényt tarthatnának rá.
Ha a szegmensnek maradnia kell, ellenőrizze a kiszolgálóoldali beállítást, amely engedi, hogy a kliensek elérjék egymást: grep -n client-to-client /etc/openvpn/server.conf. Ha le van tiltva, a kliensforgalom a szerveren keresztül halad, és ott szűrhető. Ha be van kapcsolva, a partnerek közvetlenül a hídon keresztül cserélnek kereteket, és a szűrési pontok a híd és a hoszt tűzfala.
Írja le, mely védelmi intézkedésekre támaszkodik valójában az egyes hosztok: alagút-hitelesítés, szegmensizoláció vagy alkalmazás-TLS. Az a hoszt, amely mindháromra támaszkodik, rendben van. Az a hoszt, amely az elsőre támaszkodik, és feltételezi, hogy a másik kettő vele jött, az szolgálja ki végül a rossz tartalmat.