Routad eller bryggad VPN: välj efter vad klienten måste nå

Samma dag kommer två ärenden: en användare behöver en intern webbapp och en ingenjör behöver att ett bänkinstrument beter sig som om det stod på samma Ethernet-segment. Båda besvaras med sätt dem på VPN:et, och det är där trasslet börjar. En routad tunnel och en bryggad tunnel spänner upp olika relationer, och bara en av dem passar varje begäran. Att välja topologi är ett åtkomstbeslut, inte en kryptografiinställning.

Två ärenden som ser likadana ut i kassan

Användarens krav är en tjänst, nåbar över IP, från en enhet du inte kontrollerar. Ingenjörens krav är på länknivå: instrumentet förväntar sig att se Ethernet-ramar och broadcast-upptäckt, och kanske DHCP från segmentet det tror sig vara på.

Det är olika frågor, och att svara på båda med en brygga utökar användarens åtkomst till hela kontorets LAN utan anledning.

Skriv kravet som en mening innan du väljer: vilka mål, vilka protokoll och vilka parter som ska se lokala ut. Om svaret är en värd och en port täcker routning det. Om svaret är en relation på ramnivå med enheter som bara talar broadcast kan bryggan vara det enda alternativet. Allt däremellan förtjänar ett testsegment i stället för produktions-LAN:et.

En rutt är smalare än LAN-medlemskap

En routad klient får en adress på ett tunnelsubnät och rutter till de prefix du väljer. Den kan nå applikationsservern och ingenting annat, om det är vad policyn säger. Gatewayen blir tillämpningspunkten, förutsatt att varje relevant väg korsar den.

Blanda inte ihop en rutt med en behörighet. Att berätta för en klient hur den når ett subnät hindrar den inte från att prova en annan destination.

Tillämpa åtkomstkontroll där den faktiskt kan upprätthålla flödet, och behåll applikationens egna behörigheter. En bred vidarebefordringsregel eller ett glömt andra gränssnitt kan ge mer än diagrammet antyder. Läs de effektiva reglerna, inte de avsedda. Testa sedan en destination som borde misslyckas, för en policy som ingen har försökt bryta är en hypotes.

En brygga ändrar antagningsfrågan

Bryggning kombinerar ett fysiskt gränssnitt och en TAP-enhet till en mjukvaruswitch, så att fjärrenheter ansluter till samma broadcast-domän. Det är en verklig förmåga och en verklig risk: fjärrenheten är inte längre en routad gäst, den är deltagare.

Bestäm vilka enheter som får ansluta, vilka ramtyper som måste passera och var oönskad interaktion blockeras. Adressering och DHCP-auktoritet blir en del av det delade nätet, och två DHCP-servrar på ett segment skapar precis den röra du förväntar dig.

För instrumentet passar ett eget testsegment oftast bättre än kontorets LAN. Håll administrationstillträdet utanför experimentet och definiera hur den tillfälliga deltagaren tas bort när arbetet är klart.

Filtrering finns i båda topologierna

En brygga är inte i sig ofiltrerbar, och en rutt är inte i sig säker. Linux-bryggfiltrering har sina egna krokar och sin egen regelssyntax, och en regel skriven för routad IP-vidarebefordran gäller inte automatiskt för bryggade ramar.

Kontrollera vad plattformen faktiskt stöder innan du lovar en gräns:

bridge link show
nft list ruleset

TUN och TAP beskriver gränssnittets trafik, inte chiffret. Att byta gränssnitt fixar inget av det: peer-autentisering, en stulen nyckel och en föråldrad kryptografipolicy överlever alla ändringen. Båda ändar behöver fortfarande inställningar som matchar och fortfarande stöds.

Bevisa gränsen med tre försök

Acceptans är tre observationer, inte en genomgång av diagrammet. Den krävda operationen måste fungera, en orelaterad destination måste misslyckas, och gatewayens egna administrationstjänster måste hållas utom räckhåll.

Kör den tillåtna och den nekade vägen från samma klient och notera båda:

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

För en brygga lägger du till länknivåkontrollerna: om den tillåtna upptäcktstrafiken passerar, om adresseringen kommer från den avsedda auktoriteten och om den tillfälliga deltagaren är borta efter borttagning. När vanlig routad IP redan uppfyller kravet kräver anslutning till kontorets Ethernet-segment en separat motivering, och den bör skrivas ned före ändringen.