VPN-rute eller firewallregel: hvilken dropper pakken?

Der sker to uafhængige beslutninger med den samme pakke, og enhver af dem kan afslutte anmodningen i stilhed. Ruteopslaget vælger en grænseflade og et næste hop, og derefter afgør pakkefilteret, om den kombination er tilladt. En timeout fortæller dig, at en af de to afviste, ikke hvilken. Gennemgå faserne i rækkefølge, og reparationen holder normalt op med at være et gæt.

To beslutninger, én pakke, to ejere

Ruteopslaget konsulterer først politikreglerne, derefter tabellen, de peger på, og vælger det mest specifikke præfiks, der matcher destinationen. En klient, der har installeret en tunnelrute, ejer den beslutning, og intet i en firewallregel kan erstatte den. Når opslaget peger et uventet sted hen, arbejder hvert senere trin på den forkerte pakke.

Filtrering er adskilt. På en Linux-vært opdeler netfilter-krogene trafik efter, hvem pakken er til: output forlader maskinen, input afsluttes på den, forward passerer igennem. En gateway, der accepterer VPN-klienter og router dem til et LAN, har brug for forward-stien, og det er netop den kæde, som de fleste standardkonfigurationer lader stå tom.

Kildevalg hører til samme beslutning, og det er her, de fleste afvigelser skjuler sig. Kernen vælger en kildeadresse fra den udgående grænseflade, medmindre ruten angiver en, så en filterregel skrevet til LAN-undernettet matcher aldrig en pakke, der forlader med tunneladressen.

Læs, hvad opslaget faktisk valgte

Udskriv beslutningen i stedet for at udlede den. Kommandoen nedenfor opløser den rute, kernen ville bruge til destinationen, inklusive grænsefladen og den kilde, den ville vælge:

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 installerer ofte politikregler ved prioriteter under hovedtabellen, så en ren hovedtabel beviser intet i sig selv. Sammenlign regelprioriteterne med de tabeller, de vælger, og tjek, om tunnelruten overlever en genopkobling i stedet for at blive tilføjet manuelt én gang.

Politikbaseret IPsec tilføjer et tredje matchtrin, som routing ikke dækker, som strongSwans videresendelsesnoter beskriver for tunnel- og transportopsætninger. Sikkerhedspolitikken vælger trafik efter præfiks og protokol, mens ruten kun afgør, hvor en ubeskyttet pakke ville gå hen. Et undernet, der routes, men ikke har nogen matchende selector, forbliver enten ubeskyttet eller bliver droppet, afhængigt af konfigurationen, og ingen af udfaldene ligner et firewallproblem. Udskriv politikken, og sammenlign dens selectors med de præfikser, du forventede, tunnelen skulle bære.

Filtrering gælder ved en krog, ikke ved en rute

En regel, der tillader VPN-lytteren, er en regel om trafik rettet mod gatewayen selv. Den siger intet om klienter, der når værter bag den gateway, fordi videresendt trafik passerer en anden kæde. At læse regelsættet som én flad liste er den sædvanlige grund til, at en korrekt udseende regel aldrig udløses.

Tællere afgør spørgsmålet hurtigt. En regel med nul pakketælling blev aldrig nået, hvilket peger på den forkerte kæde, den forkerte grænseflade eller en tidligere drop. En regel med stigende tælling under en drop-politik er den grænse, du ledte efter, og pakken kasseres i stedet for at blive fejlrutet.

Send en sonde ad den vej, klienten bruger

Test, der køres på gatewayen selv, går gennem output og input med gatewayens egen kildeadresse. Det er en anden vej end en klients videresendte anmodning, så et vellykket lokalt curl beviser mindre, end det ser ud til. Test fra maskinen, der fejler, eller fastgør grænsefladen og kilden eksplicit.

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 optagelse i begge ender adskiller de resterende tilfælde. Et SYN, der forlader klienten og aldrig ankommer, betyder routing, kryptering eller en adgangsliste længere oppe. Et SYN, der ankommer og ikke får svar, betyder tjenesten eller dens værtsfilter, og tunnelen var aldrig problemet.

Returtrafik fortjener sit eget kig. Asymmetrisk routing plus reverse path-filtrering dropper svar, der ankommer på den forkerte grænseflade, hvilket viser sig som en envejsforbindelse i stedet for en blokeret port. Tjek sysctl-værdien, før du giver firewalls skylden for et symptom, den ikke forårsagede.

Logning fungerer som en anden mening, ikke et første skridt. En midlertidig logerklæring på forward-kæden navngiver grænsefladen og de adresser, der ramte den, og den er nem at fjerne bagefter. Lad den blive permanent, og du har bygget et logvolumenproblem i stedet for et svar.

Placer hver ændring, hvor den overlever en genopkobling

En rute tilføjet med ip route add lever, indtil grænsefladen går ned. Gem den i forbindelsesprofilen i stedet: NetworkManager accepterer ekstra ruter på forbindelsen, og netplan bevarer dem på tværs af opstarter. Den samme regel gælder for en firewallundtagelse på klientsiden, som er væk efter den næste genindlæsning.

Regler på serversiden hører i den konfigurationsfil, tjenesten indlæser ved start, ikke i en interaktiv session, der slutter, når du lukker den. Skriv reglen, genindlæs, og bekræft, at tælleren flyttede sig, fordi en genindlæsning, der afviste syntaksen, i stilhed efterlader det gamle regelsæt på plads.

Gentag derefter den oprindelige anmodning fra applikationen fra ende til ende, og noter, hvilket lag der ændrede sig. En rutereparation, der også behøvede en filterændring, vil stadig fejle, og den anden fejl læses meget lettere, når du ved, at den første er væk. Noter datoen og klientversionen ved siden af resultatet, da standardindstillinger for routing og filtrering begge flytter sig mellem versioner. Behold noten på billetten, så den næste person starter, hvor du stoppede, i stedet for at gentage den to-trins vandring.