VPN-rutt eller brandväggsregel: vilken släpper paketet?

Två oberoende beslut fattas om samma paket, och vilket som helst av dem kan avsluta förfrågan i tysthet. Ruttuppslaget väljer ett gränssnitt och ett nästa hopp, sedan avgör paketfiltret om kombinationen är tillåten. En timeout berättar att en av de två nekade, inte vilken. Gå igenom stegen i ordning och reparationen slutar oftast vara en gissning.

Två beslut, ett paket, två ägare

Ruttuppslaget rådfrågar först policyreglerna, sedan tabellen de pekar på, och väljer det mest specifika prefixet som matchar destinationen. En klient som har installerat en tunnelrutt äger det beslutet, och inget i en brandväggsregel kan ersätta det. När uppslaget pekar på en oväntad plats arbetar varje senare steg med fel paket.

Filtreringen är separat. På en Linux-värd delar netfilter-krokarna upp trafiken efter vem paketet är till för: utgående lämnar maskinen, inkommande avslutas på den, vidarebefordran passerar genom den. En gateway som tar emot VPN-klienter och routar dem till ett LAN behöver vidarebefordringsvägen, och det är just den kedja som de flesta standardkonfigurationer lämnar tom.

Källvalet hör till samma beslut, och det är där de flesta avvikelserna gömmer sig. Kärnan väljer en källadress från det utgående gränssnittet om inte rutten namnger en, så en filterregel skriven för LAN-subnätet matchar aldrig ett paket som går ut med tunneladressen.

Läs vad uppslaget faktiskt valde

Skriv ut beslutet i stället för att härleda det. Kommandot nedan löser den rutt som kärnan skulle använda för destinationen, inklusive gränssnittet och den källa den skulle välja:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN-klienter installerar ofta policyregler på prioriteter under huvudtabellen, så en ren huvudtabell bevisar ingenting i sig själv. Jämför regelprioriteterna med tabellerna de väljer, och kontrollera om tunnelrutten överlever en återanslutning i stället för att läggas till manuellt en gång.

Policybaserad IPsec lägger till ett tredje matchningssteg som routingen inte täcker, som strongSwans vidarebefordringsanteckningar beskriver för tunnel- och transportuppsättningar. Säkerhetspolicyn väljer trafik efter prefix och protokoll, medan rutten bara avgör vart ett oskyddat paket skulle ta vägen. Ett subnät som routas men saknar matchande selektor förblir antingen oskyddat eller släpps, beroende på konfigurationen, och ingen av utgångarna ser ut som ett brandväggsproblem. Skriv ut policyn och jämför dess selektorer med de prefix du förväntade dig att tunneln skulle bära.

Filtrering gäller vid en krok, inte vid en rutt

En regel som tillåter VPN-lyssnaren är en regel om trafik adresserad till gatewayen själv. Den säger ingenting om klienter som når värdar bakom den gatewayen, eftersom vidarebefordrad trafik passerar en annan kedja. Att läsa regelverket som en enda platt lista är det vanliga skälet till att en korrekt utseende regel aldrig utlöses.

Räknarna avgör frågan snabbt. En regel med noll paketräknare nåddes aldrig, vilket pekar på fel kedja, fel gränssnitt eller en tidigare släppning. En regel med växande räknare under en släppolicy är gränsen du letade efter, och paketet kastas i stället för att routas fel.

Skicka en sond genom den väg klienten använder

Tester som körs på gatewayen själv går genom utgående och inkommande, med gatewayens egen källadress. Det är en annan väg än en klients vidarebefordrade begäran, så en lyckad lokal curl bevisar mindre än det ser ut som. Testa från maskinen som misslyckas, eller fäst gränssnittet och källan explicit.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

En avlyssning i båda ändar skiljer de återstående fallen. En SYN som lämnar klienten och aldrig anländer betyder routing, kryptering eller en åtkomstlista uppströms. En SYN som anländer och inte får svar betyder tjänsten eller dess värdilter, och tunneln var aldrig problemet.

Returtrafik förtjänar en egen titt. Asymmetrisk routing plus reverse path-filtrering kastar svar som anländer på fel gränssnitt, vilket visar sig som en enkelriktad anslutning i stället för en blockerad port. Kontrollera sysctl-värdet innan du skyller brandväggen för ett symptom den inte orsakade.

Loggning fungerar som en andra åsikt, inte som ett första steg. Ett tillfälligt loggutdrag på vidarebefordringskedjan namnger gränssnittet och adresserna som träffade det, och det är lätt att ta bort efteråt. Låt det stå permanent och du har byggt ett loggvolymproblem i stället för ett svar.

Placera varje ändring där den överlever en återanslutning

En rutt som läggs till med ip route add lever tills gränssnittet går ner. Spara den i anslutningsprofilen i stället: NetworkManager accepterar extra rutter på anslutningen, och netplan behåller dem mellan starter. Samma regel gäller för ett brandväggsundantag på klientsidan, som är borta efter nästa omladdning.

Regler på serversidan hör till konfigurationsfilen som tjänsten läser in vid start, inte till en interaktiv session som slutar när du stänger den. Skriv regeln, ladda om och bekräfta att räknaren flyttades, eftersom en omladdning som avvisade syntaxen i tysthet lämnar det gamla regelverket på plats.

Upprepa sedan den ursprungliga applikationsförfrågan från början till slut och notera vilket lager som ändrades. En ruttfix som också behövde en filterändring kommer fortfarande att misslyckas, och det andra misslyckandet läses mycket lättare när du vet att det första är borta. Notera datumet och klientversionen bredvid resultatet, eftersom standardvärden för routing och filtrering båda flyttar sig mellan versioner. Håll den anteckningen på ärendet så att nästa person börjar där du slutade i stället för att upprepa den tvåstegs vandringen.