VPN-gateway behöver IP-vidarebefordran: vad du bör kontrollera

Din klient kan pinga gatewayens adress medan alla resurser bakom den förblir oåtkomliga. Det paret av observationer beskriver en värd som talar med dig och en router som inte routar, vilket är olika roller på samma maskin. Vidarebefordran är omkopplaren mellan dem.

De två rollerna är oberoende, och det är de två adressfamiljerna också.

Att svara på sin egen adress bevisar ingenting

När ett paket är adresserat till gatewayen själv förbrukar den lokala stacken det och inget vidarebefordringsbeslut fattas. Därför berättar en lyckad ping till tunneladressen eller ett administrationsgränssnitt att daemonen lever och tunneln är uppe, utan att säga något om trafik avsedd för ett nätverk bakom lådan. Kärnan konsulterar bara sin vidarebefordringsväg för paket som inte är adresserade till den.

Läs kravet som en roll, inte en inställning: den här värden måste flytta paket mellan två gränssnitt. En bärbar dator som bara behöver nå ett fjärrnätverk tar aldrig den rollen, och en plats-till-plats-slutpunkt gör det alltid. Att läsa kravet så förklarar varför en fungerande klientkonfiguration misslyckas när den flyttas till en gateway.

Samma mening gäller brandväggen framför vidarebefordringsbeslutet, som har sin egen policy för vad som får vidarebefordras.

Kontrollera varje adressfamilj separat

IPv4-vidarebefordran är en omkopplare, och IPv6-vidarebefordran är en annan med sitt eget beteende per gränssnitt. Att slå på den första säger ingenting om den andra, och en dual-stack-klient kan nå halva ett nätverk medan resten förblir mörkt. Två klienter från olika familjer kan därför vara oense om samma gateway. Fråga vilken familj den felande klienten använde innan du redigerar någon av inställningarna. Bekräfta båda innan du drar slutsatsen att ruttdesignen är fel.

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

På många distributioner har värdet du läser vid körning lagts dit av en tjänst eller en konfigurationsfil, så en ändring gjord med ett engångskommando kan försvinna vid omstart. Hitta filen som äger inställningen innan du redigerar körningsvärdet.

Vidarebefordran är ett av fyra krav

Ett fungerande vidarebefordrat flöde behöver fyra saker samtidigt: klienten måste veta att målet ligger bakom tunneln, gatewayen måste ha en väg vidare, svar måste ha en väg tillbaka, och brandväggen måste tillåta trafiken. Källöversättning hör till den designen som ett alternativ och inte en regel, eftersom ett privat routat nätverk med symmetriska vägar inte behöver det och ett asymmetriskt vanligtvis gör det. Var och en av de fyra misslyckas oberoende, vilket är varför reparation av en sällan flyttar symptomet. Skriv ned alla fyra innan du ändrar någon av dem.

Molnplattformar lägger till en femte aspekt. Vissa tillämpar käll- och målkontroller på instanser, vilket släpper vidarebefordrade paket oavsett hur gästens kärna är konfigurerad. Plattformens egen nätverksdokumentation är auktoriteten där, inte sysctl-utdata i VM:en.

Testa från klienten, inte från gatewayen

Ett test som körs i gatewayens eget skal går inte genom någon del av vidarebefordringsvägen du just aktiverade. Generera trafiken från klienten som har problemet och bekräfta att den når något bakom gatewayen snarare än gatewayen själv. Det är det enda testet som utövar rollen du ändrade.

Håll lyssnarregler och vidarebefordringsregler åtskilda i huvudet och i ändringsloggen. Att öppna VPN-porten släpper in klienter till tjänsten; det ger dem ingenting på nätverket bakom, och de två ser identiska ut i en brandväggslista som vuxit i åratal.

Om paket anländer och tjänsten sedan avvisar användaren har du rört dig förbi nätverk. Fortsätt med applikationsauktorisering i stället för att bredda vidarebefordringspolicyn igen.