Reititetty vai siltaava VPN: valitse sen mukaan, mihin asiakkaan on päästävä
Reititetty pääsy toimittaa valitut palvelut; siltaava pääsy liittää segmenttiin. Päätä sen mukaan, mihin asiakkaan on päästävä, ja varmista sitten rakentamasi raja.
Samana päivänä saapuu kaksi tikettiä: yksi käyttäjä tarvitsee sisäisen verkkosovelluksen ja yksi insinööri tarvitsee penkkilaitteen käyttäytyvän kuin se seisoisi samassa Ethernet-segmentissä. Molempiin vastataan laittakaa ne VPN:ään, ja siitä ongelma alkaa. Reititetty tunneli ja siltaava tunneli luovat erilaisia suhteita, ja vain toinen niistä sopii kuhunkin pyyntöön. Topologian valinta on pääsypäätös, ei salausasetus.
Kaksi pyyntöä, jotka näyttävät lipulla samalta
Työntekijän vaatimus on palvelu, joka on tavoitettavissa IP:n kautta laitteesta, jota et hallitse. Insinöörin vaatimus on linkkitasolla: laite odottaa näkevänsä Ethernet-kehyksiä ja broadcast-löytämistä, ja mahdollisesti DHCP:tä segmentistä, jossa se luulee olevansa.
Ne ovat eri kysymyksiä, ja molempiin sillalla vastaaminen laajentaa työntekijän pääsyn koko toimiston LAN:iin ilman syytä.
Kirjoita vaatimus lauseena ennen valintaa: mitkä kohteet, mitkä protokollat ja mitkä vastapuolet näyttävät paikallisilta. Jos vastaus on isäntä ja portti, reititys kattaa sen. Jos vastaus on kehystason suhde laitteisiin, jotka puhuvat vain broadcastia, silta voi olla ainoa vaihtoehto. Kaikki siltä väliltä ansaitsee testisegmentin tuotannon LAN:n sijaan.
Reitti on kapeampi kuin LAN-jäsenyys
Reititetty asiakas saa osoitteen tunnelin aliverkossa ja reitit valitsemillesi prefikseille. Se voi tavoittaa sovelluspalvelimen eikä mitään muuta, jos politiikka niin sanoo. Yhdyskäytävästä tulee toimeenpanopiste, edellyttäen että jokainen olennainen polku kulkee sen kautta.
Älä sekoita reittiä lupaan. Sen kertominen asiakkaalle, miten aliverkkoon päästään, ei estä sitä yrittämästä toista kohdetta.
Käytä pääsynvalvontaa siellä, missä se voi todella valvoa virtausta, ja pidä sovelluksen omat käyttöoikeudet paikallaan. Laaja edelleenlähetyssääntö tai unohdettu toinen liitäntä voi myöntää enemmän kuin kaavio antaa ymmärtää. Lue voimassa olevat säännöt, älä aiotut. Testaa sitten kohde, jonka pitäisi epäonnistua, sillä politiikka, jota kukaan ei ole yrittänyt rikkoa, on hypoteesi.
Silta muuttaa hyväksymiskysymystä
Sillaus yhdistää fyysisen liitännän ja TAP-laitteen ohjelmistokytkimeen, joten etälaitteet liittyvät samaan broadcast-verkkotunnukseen. Se on todellinen kyvykkyys ja todellinen riski: etälaite ei ole enää reititetty vieras, se on osallistuja.
Päätä, mitkä laitteet saavat liittyä, mitkä kehystyypit on läpäistävä ja missä ei-toivottu vuorovaikutus estetään. Osoitteistus ja DHCP-valtuus tulevat osaksi jaettua verkkoa, ja kaksi DHCP-palvelinta yhdessä segmentissä tuottaa juuri sen sotkun, jota odotat.
Laitteelle erillinen testisegmentti sopii yleensä paremmin kuin toimiston LAN. Pidä hallintapääsy kokeen ulkopuolella ja määritä, miten väliaikainen osallistuja poistetaan työn päätyttyä.
Suodatus on olemassa molemmissa topologioissa
Silta ei ole luonnostaan suodattamaton, eikä reitti ole luonnostaan turvallinen. Linuxin siltasuodatuksella on omat koukkunsa ja oma sääntösyntaksinsa, eikä reititetylle IP-edelleenlähetykselle kirjoitettu sääntö päde automaattisesti siltaaviin kehyksiin.
Tarkista, mitä alusta todella tukee, ennen kuin lupaat rajan:
bridge link show
nft list ruleset
TUN ja TAP kuvaavat liitännän liikennettä, eivät salausta. Liitäntöjen vaihtaminen ei korjaa siitä mitään: vastapuolen todennus, varastettu avain ja vanhentunut salauskäytäntö selviävät kaikki muutoksesta. Molemmat päät tarvitsevat edelleen asetukset, jotka täsmäävät ja joita edelleen tuetaan.
Todista raja kolmella yrityksellä
Hyväksyntä on kolme havaintoa, ei kaavion katselmus. Vaaditun toiminnon on toimittava, asiaankuulumattoman kohteen on epäonnistuttava ja yhdyskäytävän omien hallintapalvelujen on pysyttävä ulottumattomissa.
Aja sallittu ja estetty polku samasta asiakkaasta ja kirjaa molemmat:
curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5
Sillalle lisää linkkitason tarkistukset: kulkeeko sallittu löytämisliikenne, tuleeko osoitteistus aiotulta taholta ja onko väliaikainen osallistuja poistettu poistamisen jälkeen. Kun pelkkä reititetty IP jo täyttää vaatimuksen, toimiston Ethernet-segmenttiin liittyminen vaatii erillisen perustelun, ja se on kirjoitettava ennen muutosta.