Voorkom dat VPN-clients elkaar op de tunnel bereiken

Twee clients kunnen allebei de jumphost openen en toch niets te maken hebben met elkaar openen. Een dienst bereiken is een doorstuur-beslissing, terwijl een peer bereiken een beleidsbeslissing is, en de meeste VPN-stacks houden die in aparte objecten. Niets wat u voor het eerste configureert, handhaaft het tweede. De taak is dus niet een regel toevoegen, maar het object vinden dat op deze server het peerverkeer bepaalt, de weigering daar schrijven en die vanaf een client bewijzen.

Een route naar de gedeelde dienst is geen toestemming tussen peers

Het aankondigen van het client-subnet vertelt een peer hoe een pakket op de draad naar het adres van een andere client te zetten. Of dat pakket wordt afgeleverd, wordt daarna beslist door wat het doorstuurt. Op een Linux-gateway is dat de FORWARD-keten; in een daemon in gebruikersruimte is dat de eigen sessietabel van de tunnel. Een route beantwoordt de bereikbaarheid en laat de toestemming ongemoeid.

Daarom bewijst een isolatiecontrole die alleen routes leest niets. Een /24 kan naar elke client worden gestuurd terwijl elk peer-tot-peer-pakket bij de doorstuurdraad wordt weggegooid. Het gevaarlijke geval is het omgekeerde: geen expliciete regel, een toestemmende standaard en isolatie die alleen bestaat omdat niemand die heeft getest.

Schrijf de eis op één regel voordat u een terminal opent. Bereik het dienstenblok en de jumphost, bereik niets anders binnen het clientblok.

Ontdek wie het peerpakket werkelijk doorstuurt

Twee servergedragingen zien er vanaf de clientkant hetzelfde uit en vragen verschillende regels. Ofwel stuurt de kernel het pakket opnieuw uit de tunnelinterface, ofwel kopieert de daemon het tussen sessies en de kernel ziet het nooit.

WireGuard hoort bij de eerste groep: het heeft geen peer-tot-peer-schakelaar, dus een pakket van 10.8.0.4 naar 10.8.0.5 komt aan op wg0, raakt de doorstuurdraad en wordt weer uit wg0 gerouteerd wanneer AllowedIPs beide adressen dekt. OpenVPN is de tweede groep zodra client-to-client in de serverconfiguratie staat, omdat die richtlijn het pakket in gebruikersruimte tussen sessies overdraagt. Controleer de geladen configuratie op die richtlijn voordat u iets schrijft. Een kernelregel die nooit verkeer ziet, is niet te onderscheiden van een regel die werkt, en zo eindigt een uitrol helemaal zonder isolatie.

Lees de effectieve configuratie in plaats van het bestand waarvan u aanneemt dat het geladen is, omdat distributiepakketten hun eigen inclusies meebrengen. Als de daemon doorstuurt, hoort de weigering in zijn eigen per-client-besturingen, en een hostfirewall filtert alleen verkeer dat aan de host is gericht. Als de kernel doorstuurt, is de doorstuurdraad de enige plek die telt.

Gerouteerde en vertaalde uitrollingen vragen nog een controle: de bron die een verre client ziet is misschien niet degene die u verwacht. Dan komt een regel die op het client-subnet past met niets overeen. Noteer het adres dat de vertaling overleeft voordat u de overeenkomst schrijft, en geef er de voorkeur aan het interfacepaar te matchen boven het raden van NAT-adressen.

Geef elk adres een identiteit die u afzonderlijk kunt intrekken

Isolatie stort in zodra twee apparaten één inloggegeven delen. Een regel die aan die identiteit is gekoppeld kan ze niet scheiden, en het intrekken van een verloren laptop trekt de hele groep in. Certificaten per apparaat of sleutels per peer houden het intrekken lokaal en het beleid leesbaar, omdat elk adres precies één persoon of machine is. Waar het ontwerp dat niet kan, zeg dat in de runbook in plaats van de regel als fijnmazig te beschrijven.

Adrestoewijzing moet met het beleid overeenkomen. Reserveer een blok voor diensten, een blok voor clients, en deel clientadressen uit uit een pool die u beheert in plaats van een bereik van wie het eerst komt. Als de server vertaalt of overbrugt, houd de mappingtabel naast de configuratie, want die tabel is wat de volgende lezer nodig heeft om de regel opnieuw af te leiden.

Plaats de weigering waar het pakket de tunnel oversteekt

Op een gateway die WireGuard-verkeer doorstuurt, dekken twee regels het geval: sta het dienstenblok toe en gooi daarna de rest van het clientblok weg. Het interfacepaar is even belangrijk als de adressen, want alleen op bestemming matchen vangt ook verkeer van het LAN. Laad ze in die volgorde zodat de toestemming eerst wordt beoordeeld.

Met nftables gaat het paar in een bestaande inet filter-tabel, toestemming eerst en weggooien daarna. Beide matches zetten het interfacepaar en de adressen vast.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

Lees de keten terug na het laden in plaats van op de exitstatus te vertrouwen, en bevestig dat beide regels in de bedoelde volgorde staan. Voeg passende ip6-regels toe voor de IPv6-pool, anders is het v4-paar op een dual-stack-tunnel alleen versiering. Als de server al een toestemmend doorstuurbeleid heeft, voeg dan het weggooien toe in plaats van de keten helemaal te vervangen.

Wanneer client-to-client aan staat op OpenVPN, matchen deze doorstuurregels nooit peerverkeer en moet de weigering in de eigen besturing van de daemon leven. Houd de kernelregels voor verkeer naar de host, maar reken ze niet als de isolatiecontrole.

Bewijs de weigering vanaf een client, niet vanaf de server

Testen vanaf de gateway bewijst niets, omdat lokaal gegenereerd verkeer het uitgangspad neemt en de doorstuurdraad nooit oversteekt. Gebruik twee echte clients: een die de dienst zou moeten bereiken, een die geweigerd zou moeten worden. Voer eerst het toestemmingsgeval uit, zodat een kapotte tunnel niet voor werkend beleid wordt aangezien.

Vanaf de toegestane client, bevestig dat de dienst op zijn poort antwoordt. Vanaf dezelfde client, probeer het peeradres en verwacht een stille weggooiing in plaats van een weigering:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

Een weggegooid pakket en een offline peer lijken beide op een time-out, dus controleer de tellers voordat u iets concludeert. Bevestig dat de teller van de weigeringsregel stijgt terwijl de peer aantoonbaar actief is. Herhaal over IPv6, waar een ontbrekende ip6-regel de v4-weigering effectief laat lijken. Noteer de geaccepteerde en geweigerde resultaten in de runbook met de datum, omdat de volgende migratie de regel opnieuw zal afleiden.