VPN-rute eller brannmurregel: hvilken slipper pakken?

To uavhengige beslutninger skjer med samme pakke, og hver av dem kan avslutte forespørselen i stillhet. Ruteoppslaget velger et grensesnitt og et neste hopp, deretter avgjør pakkefilteret om kombinasjonen er tillatt. En tidsavbrudd forteller deg at en av de to avviste, ikke hvilken. Gå gjennom trinnene i rekkefølge, og reparasjonen slutter vanligvis å være en gjetning.

To beslutninger, én pakke, to eiere

Ruteoppslaget konsulterer først policyreglene, deretter tabellen de peker på, og velger det mest spesifikke prefikset som samsvarer med målet. En klient som har installert en tunnelrute eier den beslutningen, og ingenting i en brannmurregel kan erstatte den. Når oppslaget peker et uventet sted, arbeider hvert senere trinn med feil pakke.

Filtrering er separat. På en Linux-vert deler netfilter-krokene trafikken etter hvem pakken er for: utdata forlater maskinen, inndata avsluttes på den, videresending går gjennom. En gateway som tar imot VPN-klienter og ruter dem til et LAN trenger videresendingsveien, og det er nettopp kjeden de fleste standardkonfigurasjoner lar stå tom.

Kildevlaget hører til samme beslutning, og det er her de fleste avvikene gjemmer seg. Kjernen velger en kildeadresse fra det utgående grensesnittet med mindre ruten navngir en, så en filterregel skrevet for LAN-undernettet samsvarer aldri med en pakke som går ut med tunneladressen.

Les hva oppslaget faktisk valgte

Skriv ut beslutningen i stedet for å utlede den. Kommandoen nedenfor løser ruten kjernen ville brukt for målet, inkludert grensesnittet og kilden den ville valgt:

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 policyregler på prioriteter under hovedtabellen, så en ren hovedtabell beviser ingenting i seg selv. Sammenlign regelprioritetene med tabellene de velger, og sjekk om tunnelruten overlever en gjentilkobling i stedet for å bli lagt til manuelt én gang.

Policybasert IPsec legger til et tredje samsvarende trinn som ruting ikke dekker, slik strongSwans videresendingsnotater beskriver for tunnel- og transportoppsett. Sikkerhetspolicyen velger trafikk etter prefiks og protokoll, mens ruten bare avgjør hvor en ubeskyttet pakke ville gå. Et undernett som rutes men ikke har noen samsvarende selektor forblir enten ubeskyttet eller blir forkastet, avhengig av konfigurasjonen, og ingen av utfallene ser ut som et brannmurproblem. Skriv ut policyen og sammenlign selektorene med prefiksene du forventet at tunnelen skulle bære.

Filtrering gjelder ved en krok, ikke ved en rute

En regel som tillater VPN-lytteren er en regel om trafikk adressert til gatewayen selv. Den sier ingenting om klienter som når verter bak den gatewayen, fordi videresendt trafikk passerer en annen kjede. Å lese regelverket som én flat liste er den vanlige grunnen til at en riktig utseende regel aldri utløses.

Tellere avgjør spørsmålet raskt. En regel med null pakketelling ble aldri nådd, noe som peker på feil kjede, feil grensesnitt eller en tidligere forkastelse. En regel med økende telling under en forkastelsespolitikk er grensen du lette etter, og pakken forkastes i stedet for å bli feilrutet.

Send en sonde gjennom veien klienten bruker

Tester som kjøres på gatewayen selv, går gjennom utdata og inndata med gatewayens egen kildeadresse. Det er en annen vei enn en klients videresendte forespørsel, så en vellykket lokal curl beviser mindre enn det ser ut som. Test fra maskinen som feiler, eller fest grensesnittet og kilden eksplisitt.

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 opptak i begge ender skiller de gjenværende tilfellene. En SYN som forlater klienten og aldri ankommer, betyr ruting, kryptering eller en oppstrøms tilgangsliste. En SYN som ankommer og ikke får svar, betyr tjenesten eller dens vertsfilter, og tunnelen var aldri problemet.

Returtrafikk fortjener sitt eget blikk. Asymmetrisk ruting pluss reversert sti-filtrering forkaster svar som ankommer på feil grensesnitt, noe som vises som en enveis forbindelse i stedet for en blokkert port. Sjekk sysctl-verdien før du gir brannmuren skylden for et symptom den ikke forårsaket.

Logging fungerer som en annen mening, ikke et første steg. En midlertidig loggsetning på videresendingskjeden navngir grensesnittet og adressene som traff den, og den er lett å fjerne etterpå. La den bli permanent, og du har bygget et loggvolumproblem i stedet for et svar.

Plasser hver endring der den overlever en gjentilkobling

En rute lagt til med ip route add lever til grensesnittet går ned. Lagre den i tilkoblingsprofilen i stedet: NetworkManager godtar ekstra ruter på tilkoblingen, og netplan beholder dem mellom oppstarter. Den samme regelen gjelder for et brannmurunnntak på klientsiden, som er borte etter neste innlasting.

Regler på serversiden hører i konfigurasjonsfilen tjenesten laster ved oppstart, ikke i en interaktiv økt som slutter når du lukker den. Skriv regelen, last inn på nytt og bekreft at telleren flyttet seg, fordi en innlasting som avviste syntaksen i stillhet lar det gamle regelverket bli stående.

Gjenta deretter den opprinnelige applikasjonsforespørselen fra ende til ende og noter hvilket lag som endret seg. En rutereparasjon som også trengte en filterendring vil fortsatt feile, og den andre feilen leses mye lettere når du vet at den første er borte. Noter datoen og klientversjonen ved siden av resultatet, siden standardverdier for ruting og filtrering begge flytter seg mellom versjoner. Hold notatet på saken slik at neste person starter der du sluttet i stedet for å gjenta den totrinns vandringen.