Att öppna VPN-porten ger inte klienterna åtkomst till LAN

Tunneln kommer upp, klienten autentiserar sig, men LAN bakom gatewayen förblir osynligt. Regeln som skulle fixa detta tillåter VPN-porten och fungerar precis som skriven, eftersom den regeln gäller paket som är adresserade till gatewayen själv. Klienttrafik till en värd bakom gatewayen har ett annat mål och en annan kedja. En lyckad inloggning ändrar inte vilken av de två kedjorna kärnan undersöker.

Två kedjor, två olika mål

Ett pakets öde avgörs av vart det ska, inte av hur det kom. Trafiken till en adress på gatewayen levereras lokalt och bedöms mot inreglerna. Trafik som gatewayen vidarebefordrar bedöms mot vidarebefordringsreglerna. Samma tunnelgränssnitt kan producera båda typerna av paket, därför kan en regel inte täcka båda uppgifterna.

Hela myten i en mening: att tillåta lyssnaren säger ingenting om att tillåta nätet bakom den. Det är två separata beslut med separata bevis, och ett gränssnittsnamn på båda förenar dem inte.

Vad lyssnarregeln faktiskt tillåter

Lyssnarpaket avslutas i VPN-processen, och det är just detta som gör tunneln möjlig. Gatewayens administrationssida och ett lokalt diagnostiksvar använder också värden egen inväg, därför lyckas ett test mot gatewayen medan allt bakom den misslyckas. Båda resultaten är korrekta och inget av dem handlar om LAN.

När processen dekapsulerar klienttrafik för ett annat mål går paketet in på vidarebefordringsvägen och behöver tillstånd där. Lyckad autentisering avgör vem klienten är; den avgör inte vart klienten får gå. De två frågorna har olika ägare, olika loggar och olika felmeddelanden.

Testa från en klient, aldrig från gatewayen

Ett test som skapas på gatewayen följer värden egen utgångsväg och kan lyckas medan den vidarebefordrade vägen är stängd. Börja testet från klienten och titta på båda ändarna av flödet.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Om begäran dyker upp på tun0 och inget når målet kastas paketet efter ankomst, vilket pekar på vidarebefordringsregler eller målets egen filtrering. Om inget alls dyker upp på tun0 skickar klienten den inte ens till tunneln, och problemet är routning på klienten och inte policy på gatewayen. Jämför med en begäran som går ut korrekt och inte returnerar något, vilket är fallet med returvägen.

Vidarebefordran kräver tre saker, inte en

Vidarebefordran i kärnan måste vara påslagen, en filterregel måste acceptera flödet, och målet måste vara nåbart med en väg för svaret att komma tillbaka. Saknas något av de tre är tystnaden densamma från klientens synpunkt.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Läs de tre utskrifterna tillsammans. En nolla i den första gör de andra två irrelevanta, och en standardkastningspolicy i den andra kastar klientens paket medan gatewayens egen trafik fortsätter att fungera. Den tredje utskriften visar varför lyssnarregeln aldrig var problemet.

Håll de två regeluppsättningarna åtskilda i dokumentationen

Skriv lyssnarregeln och regeln för den vidarebefordrade tjänsten på separata rader, med separata ägare och skäl. När VPN-porten ändras eller en ny tjänst publiceras hindrar den uppdelningen att en ändring tyst vidgar den andra.

I stället för att behandla varje autentiserad peer som en betrodd LAN-medlem, använd smala regler för de klientintervall och tjänster som behöver dem. StrongSwans anteckningar om vidarebefordran beskriver returvägs- och översättningssidan av samma gräns, vilket återigen är ett tredje beslut.

Slutligen, håll lagren raka när en användare avvisas. Om begäran når värden och applikationen avvisar kontot, reparera applikationens behörighet på det lagret; att vidga vidarebefordran kan inte ge inloggningsuppgifter för fildelning och kommer att vidga åtkomsten för alla andra som ansluter framgångsrikt.