VPN-rute eller brannmurregel: kva for ein slepp pakken?

To uavhengige avgjerder skjer med same pakke, og kvar av dei kan avslutte førespurnaden i stillheit. Ruteoppslaget vel eit grensesnitt og eit neste hopp, deretter avgjer pakkefilteret om kombinasjonen er tillaten. Ein tidsavbrot fortel deg at ein av dei to avviste, ikkje kven. Gå gjennom trinna i rekkjefølgje, og reparasjonen sluttar vanlegvis å vere ei gissing.

To avgjerder, éin pakke, to eigarar

Ruteoppslaget rådspør først policyreglane, deretter tabellen dei peikar på, og vel det mest spesifikke prefikset som passar med målet. Ein klient som har installert ei tunnelrute eig den avgjerda, og ingenting i ein brannmurregel kan erstatte ho. Når oppslaget peikar ein uventa stad, arbeider kvart seinare trinn med feil pakke.

Filtrering er separat. På ein Linux-vert deler netfilter-krokane trafikken etter kven pakken er for: utdata forlèt maskinen, inndata endar på han, vidaresending går gjennom. Ein gateway som tek imot VPN-klientar og ruter dei til eit LAN treng vidaresendingsvegen, og det er nettopp kjeda dei fleste standardkonfigurasjonar lèt stå tom.

Kjeldevalet høyrer til same avgjerd, og det er her dei fleste avvika gøymer seg. Kjernen vel ei kjeldeadresse frå det utgåande grensesnittet med mindre ruta nemner ei, så ein filterregel skriven for LAN-undernettet passar aldri med ein pakke som går ut med tunneladressa.

Les kva oppslaget faktisk valde

Skriv ut avgjerda i staden for å utleie ho. Kommandoen nedanfor løyser ruta kjernen ville brukt for målet, inkludert grensesnittet og kjelda han ville valt:

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-klientar installerer ofte policyreglar på prioriteringar under hovudtabellen, så ein rein hovudtabell provar ingenting i seg sjølv. Samanlikn regelprioriteringane med tabellane dei vel, og sjekk om tunnelruta overlever ein gjentilkopling i staden for å bli lagd til manuelt éin gong.

Policybasert IPsec legg til eit tredje samsvarande trinn som ruting ikkje dekkjer, slik vidaresendingsnotata til strongSwan skildrar for tunnel- og transportoppsett. Tryggingspolicyen vel trafikk etter prefiks og protokoll, medan ruta berre avgjer kvar ein ubeskytta pakke ville gå. Eit undernett som blir ruta men ikkje har nokon samsvarande selektor blir anten ubeskytta eller forkasta, avhengig av konfigurasjonen, og ingen av utfalla ser ut som eit brannmurproblem. Skriv ut policyen og samanlikn selektorane med prefiksa du venta at tunnelen skulle bere.

Filtrering gjeld ved ein krok, ikkje ved ei rute

Ein regel som tillèt VPN-lyttaren er ein regel om trafikk adressert til gatewayen sjølv. Han seier ingenting om klientar som når vertar bak den gatewayen, fordi vidaresendt trafikk passerer ei anna kjede. Å lese regelverket som éin flat liste er den vanlege grunnen til at ein riktig utsjåande regel aldri blir utløyst.

Teljarar avgjer spørsmålet raskt. Ein regel med null pakketeljing blei aldri nådd, noko som peikar på feil kjede, feil grensesnitt eller ei tidlegare forkasting. Ein regel med aukande teljing under ein forkastingspolicy er grensa du leita etter, og pakken blir forkasta i staden for å bli feilruta.

Send ein sonde gjennom vegen klienten brukar

Testar som blir køyrde på gatewayen sjølv, går gjennom utdata og inndata med gatewayen si eiga kjeldeadresse. Det er ein annan veg enn ein klient sin vidaresendte førespurnad, så ein vellukka lokal curl provar mindre enn det ser ut som. Test frå maskinen som feilar, eller fest grensesnittet og kjelda 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'

Eit opptak i begge endar skil dei attverande tilfella. Ein SYN som forlèt klienten og aldri kjem fram, tyder ruting, kryptering eller ei tilgangsliste oppstraums. Ein SYN som kjem fram og ikkje får svar, tyder tenesta eller vertsfilteret hennar, og tunnelen var aldri problemet.

Returtrafikk fortener sitt eige blikk. Asymmetrisk ruting pluss omvend sti-filtrering forkastar svar som kjem på feil grensesnitt, noko som viser seg som ei einvegs tilkopling i staden for ein blokkert port. Sjekk sysctl-verdien før du gir brannmuren skulda for eit symptom han ikkje årsaka.

Logging fungerer som ei anna meining, ikkje eit første steg. Ei mellombels loggsetning på vidaresendingskjeda nemner grensesnittet og adressene som trefte ho, og ho er lett å fjerna etterpå. Lèt du ho bli permanent, har du bygt eit loggvolumproblem i staden for eit svar.

Plasser kvar endring der ho overlever ein gjentilkopling

Ei rute lagd til med ip route add lever til grensesnittet går ned. Lagre ho i tilkoplingsprofilen i staden: NetworkManager godtek ekstra ruter på tilkoplinga, og netplan held på dei mellom oppstartar. Den same regelen gjeld for eit brannmurunnatak på klientsida, som er borte etter neste innlasting.

Reglar på serversida høyrer i konfigurasjonsfila tenesta lastar ved oppstart, ikkje i ei interaktiv økt som sluttar når du lukkar ho. Skriv regelen, last inn på nytt og stadfest at teljaren flytta seg, fordi ei innlasting som avviste syntaksen i stillheit lèt det gamle regelverket bli ståande.

Gjenta deretter den opphavlege applikasjonsførespurnaden frå ende til ende og noter kva lag som endra seg. Ein rutereparasjon som også trong ei filterendring vil framleis feile, og den andre feilen blir lesen mykje lettare når du veit at den første er borte. Noter datoen og klientversjonen ved sida av resultatet, sidan standardverdiar for ruting og filtrering begge flyttar seg mellom versjonar. Hald notatet på saka slik at neste person byrjar der du slutta i staden for å gjenta den totrinns vandringa.