Hvers vegna sameiginlegt TAP VPN þarf enn HTTPS á gáttinni
TAP VPN auðkennir jafningjann, ekki þjónustuna á bak við hann. Haldið hýsilnafnasannprófun á gáttinni og einangrið nágranna sem þið treystið ekki.
Tvö tæki hafa gild VPN-skírteini og deila einu brúaðu Ethernet-segmenti. Aðeins einu þeirra er ætlað að svara fyrir skrifstofugáttina, og hitt getur samt krafist gáttarfangsins á því segmenti. Göngin gerðu sitt: þau auðkenndu báða jafningjana og dulkóðuðu hverja leið til netþjónsins. Það sem þau gerðu ekki var að votta hvor þeirra á þjónustunafnið, og það bil er ástæðan fyrir því að gáttin þarf enn gilt skírteini.
Hvað VPN auðkennir í raun
VPN-handaband svarar einni spurningu: hvaða jafningi kláraði þessi göng og með hvaða lykilefni. Það svar er fyrir hvern jafningja og hverja tengingu, og það segir ekkert um þjónusturnar sem sá jafningi birtir síðan. Á TAP-segmenti er jafninginn ekki einu sinni eitt fang, því hann getur kynnt hvaða MAC sem er og hvaða IP sem brúin er reiðubúin að læra. Auðkenning stöðvast við enda ganganna, ekki við forritið.
Aðskiljið spurningarnar þrjár í stað þess að steypa þeim saman í eina. Hver hefur sitt ferli og sinn bilunarmáta.
| 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 |
Uppsetning getur haft fullkomlega auðkennd göng og algjörlega óauðkennda þjónustu á bak við þau. Hún getur líka haft staðfest skírteini á hýsli þar sem annar jafningi krefst annars lags fangsins, og þess vegna eiga báðar stýringarnar heima í hönnuninni í stað þess að önnur komi í staðinn fyrir hina. Taflan er öll röksemdin í þremur línum.
ARP á sameiginlegu segmenti er ekki skrá
ARP varpar IPv4-fangi yfir á MAC á staðbundnu hlekknum og tekur við svörum frá hverjum sem er á þeim hlekk. Á eftirlátssömu brúuðu segmenti getur jafningi krafist fangs sem tilheyrir öðru tæki, og brúin sendir ramma til þess sem svaraði síðast. Dulkóðun hverrar biðlaraleiðar til netþjónsins breytir því ekki, því rammarnir eru afkóðaðir áður en þeir ná brúnni. Traustmörk ARP eru segmentið, ekki göngin.
Skoðið hvað hýsillinn lærði í raun: ip neigh show listar núverandi varpanir og stöðu þeirra, og færsla sem skiptist á milli tveggja MAC-fanga í eðlilegri notkun er einkenni sem þess virði að rannsaka frekar en að hunsa. Á heilbrigðu litlu segmenti haldast þessar færslur stöðugar í langan tíma.
Einangrun jafningja og brúarstefna eru til fyrir einmitt þetta tilvik. Beitt hönnun er venjulega betra svar þegar þjónustan er aðeins IP og tækin hafa enga ástæðu til að sjá ramma hvors annars.
Haldið skírteinissannprófun þar sem þjónustan er
TLS forritsins svarar spurningunni sem göngin geta ekki: er þetta þjónustan sem ég vildi ná. Vafrinn ber saman hýsilnafnið við skírteinið, og sú sannprófun er eini hlutinn í keðjunni sem nefnir gáttina en ekki jafningjann.
Skoðið hvað netþjónninn kynnir áður en þið ákveðið að viðvörunin sé skrautleg. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal prentar keðjuna og varanöfn viðfangsins. Ef nafnið sem þið slegið inn er ekki á þeim lista er viðvörunin rétt og skírteinið það sem þarf að laga. Að kenna notendum að smella fram hjá henni gerir virka stýringu að skrauti.
Leiðarvísir OpenVPN um brúargerð lýsir Ethernet-líkaninu og stefnuvalkostunum í kring, og hann er rétta heimildin fyrir það sem segmentinu er ætlað að leyfa. Lesið hann áður en þið slakið á brúarreglu, því líkanið sem hann lýsir er það sem hver sannprófun hér að ofan gerir ráð fyrir.
Ákveðið hvort þessir jafningjar eigi yfirhöfuð að deila segmenti
Ódýrasta lagfæringin er venjulega að hætta að deila laginu tvö þegar krafan er aðeins IP-aðgengi. Beint VPN gefur hverjum biðlara eigið fang, fjarlægir sameiginlegt dreifisvæði og gerir umferð milli jafningja að stefnuákvörðun í stað sjálfgefins vals. Þá hefur gáttin eitt fang til að vernda og enga nágranna sem geta krafist þess.
Ef segmentið verður að vera, athugið stillinguna á netþjónshlið sem leyfir biðlurum að ná hvort öðru: grep -n client-to-client /etc/openvpn/server.conf. Þegar hún er óvirk fer biðlaraliðið um netþjóninn og hægt er að sía þar. Þegar hún er virk skiptast jafningjar á römmum beint í gegnum brúna, og síunarpunktarnir eru brúin og eldveggur hýsilsins.
Skrifið niður hvaða vörnum hver hýsill treystir í raun: auðkenningu ganga, einangrun segmentis eða TLS forritsins. Hýsill sem treystir öllum þremur er í lagi. Hýsill sem treystir þeirri fyrstu og gerir ráð fyrir að hinar tvær hafi komið með henni er sá sem endar á að þjóna röngu efni.