Gerouteerde of gebrugde VPN: kies op basis van wat de client moet bereiken

Op dezelfde dag komen er twee tickets binnen: één gebruiker heeft een interne webapp nodig, en één engineer heeft een meetinstrument nodig dat zich gedraagt alsof het op hetzelfde Ethernet-segment staat. Op beide wordt geantwoord met zet ze op de VPN, en daar begint de ellende. Een gerouteerde tunnel en een gebrugde tunnel spannen verschillende relaties op, en slechts één daarvan past bij elk verzoek. De topologie kiezen is een toegangsbeslissing, geen cryptografie-instelling.

Twee verzoeken die bij de balie hetzelfde lijken

De eis van de medewerker is een dienst, bereikbaar over IP, vanaf een apparaat dat je niet beheert. De eis van de engineer is op linkniveau: het instrument verwacht Ethernet-frames en broadcast-ontdekking te zien, en mogelijk DHCP uit het segment waarvan het denkt deel uit te maken.

Dat zijn verschillende vragen, en beide met een brug beantwoorden verbreedt de toegang van de medewerker zonder reden tot het hele kantoor-LAN.

Schrijf de eis als een zin voordat je kiest: welke bestemmingen, welke protocollen en welke peers lokaal moeten lijken. Als het antwoord een host en een poort is, dekt routering dat. Als het antwoord een relatie op frameniveau is met apparaten die alleen broadcast spreken, is de brug misschien de enige optie. Alles daartussen verdient een testsegment in plaats van het productie-LAN.

Een route is smaller dan LAN-lidmaatschap

Een gerouteerde client krijgt een adres op een tunnelsubnet en routes voor de prefixen die je kiest. Hij kan de applicatieserver bereiken en niets anders, als dat is wat het beleid zegt. De gateway wordt het handhavingspunt, mits elk relevant pad erdoorheen loopt.

Verwar een route niet met een toestemming. Een client vertellen hoe hij een subnet bereikt, weerhoudt hem er niet van een andere bestemming te proberen.

Pas toegangsbeheer toe waar het de stroom echt kan handhaven, en houd de eigen rechten van de applicatie in stand. Een brede doorstuurregel of een vergeten tweede interface kan meer verlenen dan het diagram suggereert. Lees de effectieve regels, niet de bedoelde. Test dan een bestemming die zou moeten falen, want beleid dat niemand heeft geprobeerd te schenden is een hypothese.

Een brug verandert de toelatingsvraag

Bridging combineert een fysieke interface en een TAP-apparaat tot een softwareswitch, zodat externe apparaten zich bij hetzelfde broadcast-domein aansluiten. Dat is een echte capaciteit en een echt risico: het externe apparaat is geen gerouteerde gast meer, het is een deelnemer.

Bepaal welke apparaten mogen aansluiten, welke frametypen moeten passeren en waar ongewenste interactie wordt geblokkeerd. Adressering en DHCP-autoriteit worden onderdeel van het gedeelde netwerk, en twee DHCP-servers op één segment produceren precies de rommel die je verwacht.

Voor het instrument past een toegewijd testsegment meestal beter dan het kantoor-LAN. Houd beheerstoegang buiten het experiment, en definieer hoe de tijdelijke deelnemer wordt verwijderd als het werk klaar is.

Filtering bestaat in beide topologieën

Een brug is niet inherent onfilterbaar, en een route is niet inherent veilig. Linux-bridgefiltering heeft zijn eigen haken en zijn eigen regelsyntaxis, en een regel die voor gerouteerde IP-doorsturing is geschreven, geldt niet automatisch voor gebrugde frames.

Controleer wat het platform echt ondersteunt voordat je een grens belooft:

bridge link show
nft list ruleset

TUN en TAP beschrijven het verkeer van de interface, niet het cijfer. Interfaces wisselen lost daar niets van op: peer-authenticatie, een gestolen sleutel en een verouderd cryptografiebeleid overleven allemaal de wijziging. Beide kanten hebben nog steeds instellingen nodig die overeenkomen en nog steeds worden ondersteund.

Bewijs de grens met drie pogingen

Acceptatie is drie waarnemingen, geen diagrambeoordeling. De vereiste handeling moet werken, een ongerelateerde bestemming moet falen, en de beheerdiensten van de gateway zelf moeten buiten bereik blijven.

Voer het toegestane en het geweigerde pad vanaf dezelfde client uit, en leg beide vast:

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

Voeg voor een brug de controles op linkniveau toe: of het toegestane ontdekkingsverkeer passeert, of de adressering van de bedoelde autoriteit komt en of de tijdelijke deelnemer na verwijdering weg is. Als gewone gerouteerde IP al aan de eis voldoet, vereist aansluiting bij het kantoor-Ethernet-segment een aparte rechtvaardiging, en die moet vóór de wijziging op papier staan.