Rutet eller broet VPN: velg ut fra hva klienten må nå

To saker kommer samme dag: én bruker trenger en intern webapp, og én ingeniør trenger at et benkinstrument oppfører seg som om det står på samme Ethernet-segment. Begge besvares med sett dem på VPN-en, og det er der trøbbelet begynner. En rutet tunnel og en broet tunnel spenner ulike relasjoner, og bare én av dem passer til hver forespørsel. Å velge topologi er en tilgangsbeslutning, ikke en kryptografiinnstilling.

To forespørsler som ser like ut i skranken

Kravet fra den ansatte er en tjeneste, nåbar over IP, fra en enhet du ikke kontrollerer. Kravet fra ingeniøren er på lenkenivå: instrumentet forventer å se Ethernet-rammer og broadcast-oppdagelse, og kanskje DHCP fra segmentet det tror det er på.

Dette er forskjellige spørsmål, og å svare på begge med en bro utvider den ansattes tilgang til hele kontorets LAN uten grunn.

Skriv kravet som en setning før du velger: hvilke mål, hvilke protokoller og hvilke parter som skal se lokale ut. Hvis svaret er en vert og en port, dekker ruting det. Hvis svaret er en relasjon på rammenivå med enheter som bare snakker broadcast, kan broen være det eneste alternativet. Alt imellom fortjener et testsegment i stedet for produksjons-LAN-et.

En rute er smalere enn LAN-medlemskap

En rutet klient får en adresse på et tunnelsubnett og ruter til prefiksene du velger. Den kan nå applikasjonsserveren og ingenting annet, hvis det er det policyen sier. Gatewayen blir håndhevingspunktet, forutsatt at hver relevant vei krysser den.

Ikke forveksle en rute med en tillatelse. Å fortelle en klient hvordan den når et subnett hindrer den ikke i å prøve en annen destinasjon.

Bruk tilgangskontroll der den faktisk kan håndheve flyten, og behold applikasjonens egne rettigheter. En bred videresendingsregel eller et glemt ekstra grensesnitt kan gi mer enn diagrammet antyder. Les de effektive reglene, ikke de tiltenkte. Test deretter en destinasjon som burde feile, for en policy ingen har prøvd å bryte er en hypotese.

En bro endrer adgangsspørsmålet

Broing kombinerer et fysisk grensesnitt og en TAP-enhet til en programvaresvitsj, slik at fjerntliggende enheter kobler seg til samme broadcast-domene. Det er en reell evne og en reell risiko: fjernenheten er ikke lenger en rutet gjest, den er deltaker.

Bestem hvilke enheter som får koble seg til, hvilke rammetyper som må krysse, og hvor uønsket samhandling blokkeres. Adressering og DHCP-autoritet blir en del av det delte nettet, og to DHCP-servere på ett segment lager nøyaktig det rotet du forventer.

For instrumentet passer et eget testsegment vanligvis bedre enn kontorets LAN. Hold administrasjonstilgangen utenfor eksperimentet, og definer hvordan den midlertidige deltakeren fjernes når arbeidet er ferdig.

Filtrering finnes i begge topologiene

En bro er ikke iboende ufiltrerbar, og en rute er ikke iboende sikker. Linux-brofiltrering har sine egne kroker og sin egen regelsyntaks, og en regel skrevet for rutet IP-videresending gjelder ikke automatisk for broede rammer.

Sjekk hva plattformen faktisk støtter før du lover en grense:

bridge link show
nft list ruleset

TUN og TAP beskriver grensesnittets trafikk, ikke chifferet. Å bytte grensesnitt fikser ingenting av dette: peer-autentisering, en stjålet nøkkel og en utdatert kryptografipolicy overlever alle endringen. Begge ender trenger fortsatt innstillinger som passer sammen og fortsatt støttes.

Bevis grensen med tre forsøk

Aksept er tre observasjoner, ikke en gjennomgang av diagrammet. Den påkrevde operasjonen må virke, en urelatert destinasjon må feile, og gatewayens egne administrasjonstjenester må holde seg utenfor rekkevidde.

Kjør den tillatte og den avviste veien fra samme klient, og noter begge:

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

For en bro legger du til lenkenivåkontrollene: om den tillatte oppdagelsestrafikken krysser, om adressering kommer fra den tiltenkte autoriteten, og om den midlertidige deltakeren er borte etter fjerning. Når vanlig rutet IP allerede oppfyller kravet, krever tilkobling til kontorets Ethernet-segment en egen begrunnelse, og den bør skrives ned før endringen.