En VPN-peer pingar andra gränssnitt eftersom de är lokala

En WireGuard-klient ansluter och pingar en adress på ett helt annat gränssnitt, och svaret kommer. Insamlingar visar begäran bara på tunneln. Inget är trasigt, och den noggrant avstängda vidarebefordringsinställningen har inget med saken att göra. Detta är en jämförelse mellan två vägar som ser likadana ut i ett diagram och är helt olika i kärnan.

Den ena vägen vidarebefordrar paket åt någon annan; den andra levererar dem till värden själv.

Ett paket adresserat till värden stannar i värden

Fjärrklienten skickar ett IP-paket till en adress som värden äger. Routingen ställer en fråga om det paketet: är denna destination lokal? Varje adress som värden har finns i den lokala routingtabellen, och den tabellen konsulteras före huvudtabellen, så paketet går till värdens egen stack i stället för ut genom ett annat gränssnitt. Svaret genereras lokalt, och det färdas tillbaka genom tunneln eftersom det var där frågan kom ifrån.

Det är hela mekanismen. Ingen vidarebefordran sker, ingen ändring av gränssnittstillstånd är inblandad, och adressen i fråga behöver inte vara nåbar från någon annanstans.

Varför ip_forward inte gäller

Vidarebefordran styr paket som måste lämna genom ett annat gränssnitt än det de kom in på. En ping till värden själv tar aldrig den vägen: paketet förbrukas lokalt och svaret genereras lokalt. Därför ändrar inställningen net.ipv4.ip_forward=0 ingenting här, och en regel i vidarebefordringskedjan ser aldrig trafiken. Rätt kontroll sitter på ingångsvägen, avgränsad av inkommande gränssnitt eller källa.

Därför skapar det en falsk trygghet att stänga av vidarebefordran och anta att värden är isolerad.

Läs den lokala tabellen som avgjorde

ip rule show rapporterar vanligtvis en regel med prioritet noll som skickar alla uppslagningar till den lokala tabellen först, och ip route show table local listar värdens egna adresser med lokal omfattning. Den tabellen omfattar adresser på gränssnitt som är administrativt nedstängda men fortfarande konfigurerade. IPv4-adresser som tilldelats statiskt överlever vanligtvis ett länkavbrott, och det är därför en ping till en nedsläckt brygga fortfarande kan lyckas och överraska operatören.

IPv6 är oense just på denna punkt. Dess adresser dras vanligtvis tillbaka när länken faller, om inte keep_addr_on_down är satt. Jämför familjerna i stället för att anta att en regel täcker båda.

Vad en peer faktiskt når

Ett svar från routerns egen adress på ett segment säger ingenting om maskinerna bakom det segmentet. Peeren kan inte nå en värd bakom det andra gränssnittet via denna väg; den når bara adresser som routern själv äger. Att testa en tjänst på en separat LAN-värd, i stället för att pinga routerns adress, är det som fastställer om vidarebefordran överhuvudtaget är tillåten.

Att begränsa en peer till tjänster som är bundna till tunneladressen är en fråga om ingångspolicy. Tillåt den önskade tjänsten på tunnelgränssnittet och begränsa de källor som får använda den, eftersom paketet faktiskt anländer där.

Kontrollera även adresser som du tänkte avveckla. Att ta bort en adress från ett gränssnitt är mer tillförlitligt än att stapla brandväggsregler ovanpå en inaktuell.