Wêrom't in dielde TAP VPN noch altyd HTTPS op it portaal nedich hat
In TAP VPN ferifiearret de peare, net de tsjinst derachter. Hâld hostnamferifikaasje op it portaal en isolearje buorlju dy't jo net fertrouwe.
Twa apparaten hawwe jildige VPN-legitimearjes en diele ien oerbrêge Ethernet-segment. Mar ien fan harren heart foar it kantoarportaal te antwurdzjen, en de oare kin de portaaladres op dat segment noch beskeie. De tunnel die syn wurk: hy ferifiearre beide pearen en fersifere elk paad nei de server. Wat er net die, wie befêstigje hokker fan harren in tsjinstnamme besit, en krekt dat gat is de reden dat it portaal noch altyd in jildich sertifikaat nedich hat.
Wat it VPN eins ferifiearret
In VPN-hânskodding beantwurdet ien fraach: hokker peare hat dizze tunnel mei hokker kaaimateriaal foltôge. Dat antwurd jildt per peare en per ferbining, en it seit neat oer de tsjinsten dy't dy peare dêrnei oanbiedt. Op in TAP-segment is de peare net iens ien adres, want hy kin elke MAC en elke IP presintearje dy't de brêge ree is om te learen. Ferifikaasje stoppet by it tunnel-einpunt, net by de applikaasje.
Skied de trije fragen yn stee fan se yn ien te smelten. Elk hat syn eigen meganisme en syn eigen wize fan mislearjen.
| 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 |
In útfiering kin in perfekt ferifiearre tunnel hawwe en in folslein net-ferifiearre tsjinst derachter. Hy kin ek in falidearre sertifikaat hawwe op in host waans twadde-laaachadres troch in oare peare beskeie wurdt, en dêrom hearre beide kontrôles yn it ûntwerp yn stee fan dat de iene de oare ferfangt. De tabel is it hiele argumint yn trije rigen.
ARP op in dield segment is gjin gids
ARP keppelt in IPv4-adres oan in MAC op de lokale keppeling en akseptearret antwurden fan elkenien op dy keppeling. Op in tolerâns oerbrêge segment kin in peare in adres beskeie dat ta in oar apparaat heart, en de brêge stjoert frames nei wa't it lêst antwurde. It fersiferjen fan elk klantpaad nei de server feroaret dat net, want frames wurde ûntsifere foardat se de brêge berikke. De fertrouwensgrins fan ARP is it segment, net de tunnel.
Sjoch wat de host eins leard hat: ip neigh show listet de aktuele keppelings en har tastân, en in yngong dy't by normaal bedriuw tusken twa MAC-adressen wikselet is in symptoom dat ûndersocht wurde moat yn stee fan negearre. Op in sûn lyts segment bliuwe sokke yngongen lang stabyl.
Isolearring fan pearen en brêgebelied besteane krekt foar dit gefal. In rûtearjend ûntwerp is meastentiids it bettere antwurd as de tsjinst allinnich IP is en de apparaten gjin reden hawwe om elkoars frames te sjen.
Hâld sertifikaatferifikaasje dêr't de tsjinst is
De TLS fan 'e applikaasje beantwurdet de fraach dy't de tunnel net kin: is dit de tsjinst dy't ik berikke woe. De browser kontrolearret de hostnamme tsjin it sertifikaat, en dy kontrôle is it iennige part fan 'e keatling dat it portaal neamt yn stee fan de peare.
Undersykje wat de server presintearret foardat jo beslute dat de warskôging kosmetysk is. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal prints it keatling en de alternative nammen fan it ûnderwerp. As de namme dy't jo typt hawwe net yn dy list stiet, is de warskôging korrekt en is it sertifikaat wat reparearre wurde moat. Brûkers leare om der troch te klikken makket fan in wurkjende kontrôle dekoraasje.
De OpenVPN-oerbrêgingsgids beskriuwt it Ethernet-model en de beliedsopsjes deromhinne, en it is de juste referinsje foar wat it segment tastean moat. Lês it foardat jo in brêgeregel fersoepje, want it model dat it beskriuwt is wat elke kontrôle hjirboppe ferûnderstelt.
Beslute oft dy pearen hielendal in segment diele moatte
De goedkeapste oplossing is meastentiids ophâlde mei it dielen fan 'e twadde laach as de eask allinnich IP-berikberens is. In rûtearjend VPN jout elke klant syn eigen adres, ferwideret it dielde broadcast-domein en makket ferkear tusken pearen in beliedsbeslút yn stee fan in standert. Dan hat it portaal ien adres te beskermjen en gjin buorlju dy't it beskeie kinne.
As it segment bliuwe moat, kontrolearje dan de server-side ynstelling dy't klanten elkoar berikke lit: grep -n client-to-client /etc/openvpn/server.conf. Mei dy útskeakele giet klantferkear troch de server en kin dêr filtere wurde. Mei dy ynskeakele wikselje pearen frames direkt troch de brêge, en jo filterpunten binne de brêge en de host-firewall.
Skriuw op op hokker beskermingen elke host eins fertrout: tunnelferifikaasje, segmintisolearring of applikaasje-TLS. In host dy't op alle trije fertrout is goed. In host dy't op de earste fertrout en oannimt dat de oare twa dermei kamen, is dejinge dy't úteinlik de ferkearde ynhâld tsjinnet.