Stoppa VPN-klienter från att nå varandra i tunneln

Två klienter kan båda öppna hoppvärden och ändå inte ha något att göra med att öppna varandra. Att nå en tjänst är ett vidarebefordringsbeslut, medan att nå en peer är ett policybeslut, och de flesta VPN-stackar håller dem i separata objekt. Inget du konfigurerar för det första upprätthåller det andra. Uppgiften är därför inte att lägga till en regel, utan att hitta objektet som avgör peer-trafiken på den här servern, skriva nekandet där och bevisa det från en klient.

En rutt till den delade tjänsten är inte ett tillstånd mellan peers

Att annonsera klientnätet berättar för en peer hur den ska sätta ett paket på ledningen mot en annan klients adress. Om paketet levereras avgörs efteråt, av det som vidarebefordrar det. På en Linux-gateway är det FORWARD-kedjan; i en daemon i användarutrymmet är det tunnelns egen sessionstabell. En rutt svarar på nåbarhet och lämnar tillståndet orört.

Därför bevisar en isoleringskontroll som bara läser rutter ingenting. Ett /24 kan skickas till varje klient medan varje peer-till-peer-paket släpps vid vidarebefordringskroken. Det farliga fallet är det omvända: ingen uttrycklig regel, en tillåtande standard och isolering som bara finns för att ingen testade den.

Skriv kravet på en rad innan du öppnar en terminal. Nå tjänsteblocket och hoppvärden, nå inget annat inne i klientblocket.

Ta reda på vem som faktiskt vidarebefordrar peer-paketet

Två serverbeteenden ser likadana ut från klientsidan och kräver olika regler. Antingen vidarebefordrar kärnan paketet ut ur tunnelgränssnittet igen, eller kopierar daemonen det mellan sessioner och kärnan ser det aldrig.

WireGuard hör till den första gruppen: det har ingen peer-till-peer-brytare, så ett paket från 10.8.0.4 till 10.8.0.5 anländer på wg0, träffar vidarebefordringskroken och routas ut ur wg0 igen när AllowedIPs täcker båda adresserna. OpenVPN är den andra gruppen när client-to-client är satt i serverkonfigurationen, eftersom det direktivet lämnar över paketet mellan sessioner i användarutrymmet. Kontrollera den inlästa konfigurationen för det direktivet innan du skriver något. En kärnregel som aldrig ser trafik går inte att skilja från en regel som fungerar, och så slutar en utrullning helt utan isolering.

Läs den effektiva konfigurationen i stället för filen du antar är inläst, eftersom distributionspaket tar med egna inkluderingar. Om daemonen vidarebefordrar hör nekandet till dess egna per-klient-kontroller, och en värdbrandvägg filtrerar bara trafik adresserad till värden. Om kärnan vidarebefordrar är vidarebefordringskroken den enda plats som spelar roll.

Routade och översatta utrullningar behöver en kontroll till: källan som en avlägsen klient ser är kanske inte den du förväntar dig. Då matchar en regel som matchar klientnätet ingenting. Notera adressen som överlever översättningen innan du skriver matchningen, och föredra att matcha gränssnittsparet framför att gissa NAT-adresser.

Ge varje adress en identitet du kan återkalla ensam

Isoleringen kollapsar så snart två enheter delar en inloggningsuppgift. En regel knuten till den identiteten kan inte skilja dem, och återkallande av en förlorad bärbar dator återkallar hela gruppen. Certifikat per enhet eller nycklar per peer håller återkallandet lokalt och policyn läsbar, eftersom varje adress motsvarar exakt en person eller maskin. Där designen inte kan göra det, säg det i runbooken i stället för att beskriva regeln som finkornig.

Adresstilldelningen måste stämma med policyn. Reservera ett block för tjänster, ett block för klienter, och dela ut klientadresser från en pool du kontrollerar i stället för ett område efter först-till-kvarn. Om servern översätter eller bryggar, håll mappningstabellen bredvid konfigurationen, eftersom den tabellen är vad nästa läsare behöver för att härleda regeln igen.

Placera nekandet där paketet korsar tunneln

På en gateway som vidarebefordrar WireGuard-trafik täcker två regler fallet: tillåt tjänsteblocket och släpp sedan resten av klientblocket. Gränssnittsparet spelar lika stor roll som adresserna, eftersom matchning bara på destination också fångar trafik från LAN. Läs in dem i den ordningen så att tillståndet bedöms först.

Med nftables går paret in i en befintlig inet filter-tabell, tillstånd först och släpp sedan. Båda matchningarna fäster gränssnittsparet liksom adresserna.

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

Läs kedjan baklänges efter inläsning i stället för att lita på utgångsstatusen, och bekräfta att båda reglerna står i den ordning du avsåg. Lägg till matchande ip6-regler för IPv6-poolen, annars är v4-paret bara dekoration på en dual-stack-tunnel. Om servern redan har en tillåtande vidarebefordringspolicy, lägg till släppet i stället för att ersätta hela kedjan.

När client-to-client är aktiverat på OpenVPN matchar dessa vidarebefordringsregler aldrig peer-trafik och nekandet måste leva i daemonens egna kontroller. Behåll kärnreglerna för trafik adresserad till värden, men räkna dem inte som isoleringskontrollen.

Bevisa nekandet från en klient, inte från servern

Test från gatewayen bevisar ingenting, eftersom lokalt genererad trafik tar utgångsvägen och aldrig korsar vidarebefordringskroken. Använd två riktiga klienter: en som ska nå tjänsten, en som ska nekas. Kör tillståndsfallet först, så att en trasig tunnel inte tas för en fungerande policy.

Från den tillåtna klienten, bekräfta att tjänsten svarar på sin port. Från samma klient, prova peer-adressen och förvänta ett tyst släpp i stället för ett nekande:

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

Ett släppt paket och en offline-peer ser båda ut som en timeout, så kontrollera räknarna innan du drar någon slutsats. Bekräfta att släppregelns räknare ökar medan peeren bevisligen är uppe. Upprepa över IPv6, där en saknad ip6-regel får v4-nekandet att se effektivt ut. Notera de accepterade och nekade resultaten i runbooken med datum, eftersom nästa migrering kommer att härleda regeln igen.