Försvinner Linux VPN-svaren? Kontrollera rp_filter och rutten

Förfrågningar lämnar maskinen, VPN-partnern svarar, och svaret når aldrig socketen. Tunneln är uppe, partnerns loggar visar att paketet skickas, och inget i applikationen förklarar tystnaden. På Linux är en av de vanliga misstänkta omvänd väg-filtrering: ett inkommande IPv4-paket kan avvisas när källvalideringen inte stämmer med den rutt som kärnan förväntar sig för den källan. Att gå igenom det i ordning berättar om det är orsaken eller en slump. Det hindrar dig också från att stänga av en säkerhetskontroll för att laga en saknad rutt.

Vad källvalideringen avgör

Kärnan kontrollerar om ett pakets källadress är rimlig för det gränssnitt det kom in på, genom att slå upp i routningstabellen efter en rutt tillbaka till den källan. Om den omvända rutten pekar någon annanstans kan paketet släppas innan någon brandväggsregel eller applikationssocket ser det. Den kontrollen finns för att göra vissa spoofingmönster svårare, och det är också därför asymmetriska och policy-routade konstruktioner stöter på den medan varje vanlig klient i samma nätverk fungerar bra. Vanliga klienter har symmetrisk routing, vilket är precis vad kontrollen förutsätter.

Det viktiga ordet är rimlig. Paketet kan vara helt legitimt och ändå misslyckas i kontrollen, eftersom det inte är legitimiteten som testas.

Läs det faktiska läget, inte ett fält

Det finns tre lägen: avstängt, strikt och löst. Strikt ställer ett annat ruttförväntan än löst, och den globala inställningen samverkar med dem per gränssnitt, så att läsa en enda fil kan beskriva fel vad som faktiskt gäller. Läs båda, och läs dem på det gränssnitt som tar emot svaret, inte på standardruttens gränssnitt.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

Ruttuppslagningen i den tredje raden är den del folk hoppar över. Den berättar vad kärnan tror om källan, och det är exakt kontrollens indata.

Hitta avvikelsen innan du ändrar kontrollen

Ta reda på varför svaret kommer in på det gränssnittet och om dess omvända rutt borde vara annorlunda. En policyregel som skickar förfrågningar ut en väg medan svar kommer tillbaka en annan är en legitim konstruktion, och det är också den konstruktion som strikt validering avvisar. Markeringar som används i policy-routing kan spela roll här också, eftersom de ändrar vad den omvända uppslagningen returnerar.

Om den omvända rutten helt enkelt saknas åtgärdar det att lägga till den orsaken i stället för att stänga av en kontroll. En saknad rutt, ett brandväggsavslag och en felaktig trafikväljare ger alla samma synliga symptom, och bara en av dem handlar om källvalidering.

Stäng inte av källkontroller globalt som första reaktion. Det byter en konkret diagnos mot en bred beteendeförändring som du måste komma ihåg senare.

En selektiv justering du kan försvara

Om en snäv justering verkligen behövs, begränsa den till det gränssnitt som behöver den, skriv ned varför, och lägg den i konfigurationen som äger det gränssnittet så att den överlever en omstart. Testa sedan om exakt det flöde som misslyckades, från samma källa till samma mål, i stället för en ping mot något bekvämt.

Inkludera ett fall som fortfarande borde avvisas. Om det fallet nu lyckas försvagade justeringen mer än den enda väg du ville reparera.

Håll IPv4 och IPv6 åtskilda

En bekant utseende sysctl är inte en policy för varje adressfamilj. IPv6 har sitt eget beteende och sina egna inställningar, och en maskin kan vara strikt på den ena familjen och eftergiven på den andra utan att någon märker det förrän en viss destination misslyckas. Kontrollera båda om arbetsbelastningen använder båda.

Anteckna läget, gränssnittet, utdata från ruttuppslagningen och skälet till ändringen på ett ställe. Nästa person hittar inställningen och ingen förklaring, och kommer antingen att ta bort den eller kopiera den någonstans där den inte hör hemma.