Åpning av VPN-porten gir ikke klientene tilgang til LAN

Tunnelen kommer opp, klienten godkjennes, men LAN-et bak gatewayen er fortsatt usynlig. Regelen som skulle fikse dette, tillater VPN-porten og virker akkurat som skrevet, fordi den regelen gjelder pakker som er adressert til gatewayen selv. Klienttrafikk mot en vert bak gatewayen har en annen destinasjon og en annen kjede. En vellykket innlogging endrer ikke hvilken av de to kjedene kjernen ser på.

To kjeder, to ulike destinasjoner

Skjebnen til en pakke avgjøres av hvor den skal, ikke hvordan den ankom. Trafikk til en adresse på gatewayen leveres lokalt og vurderes mot inngangsreglene. Trafikk som gatewayen videresender, vurderes mot videresendingsreglene. Samme tunellgrensesnitt kan produsere begge typer pakker, derfor kan ikke én regel dekke begge oppgavene.

Hele myten i én setning: å tillate lytteren sier ingenting om å tillate nettverket bak den. Dette er to separate beslutninger med separat bevis, og et grensesnittnavn på begge slår dem ikke sammen.

Hva lytterregelen egentlig tillater

Lytterpakker termineres i VPN-prosessen, og det er dette som gjør tunnelen mulig i det hele tatt. Administrasjonssiden på gatewayen og et lokalt diagnosestatus-svar bruker også vertens egen inngangsvei, derfor lykkes en test mot gatewayen mens alt bak den feiler. Begge resultatene er korrekte, og ingen av dem handler om LAN.

Når prosessen dekapsulerer klienttrafikk for en annen destinasjon, går pakken inn i videresendingsveien og trenger tillatelse der. Vellykket autentisering avgjør hvem klienten er; den avgjør ikke hvor klienten har lov til å gå. De to spørsmålene har forskjellige eiere, forskjellige logger og forskjellige feilmeldinger.

Test fra en klient, aldri fra gatewayen

En test som genereres på gatewayen, følger vertens egen utgangsvei og kan lykkes mens den videresendte veien er lukket. Start testen fra klienten og følg med på begge ender av strømmen.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Hvis forespørselen dukker opp på tun0 og ingenting når frem til destinasjonen, forkastes pakken etter ankomst, noe som peker mot videresendingsregler eller destinasjonens egen filtrering. Hvis ingenting dukker opp på tun0 i det hele tatt, sender ikke klienten den engang til tunnelen, og problemet er ruting på klienten, ikke policy på gatewayen. Sammenlign med en forespørsel som går riktig ut og ikke returnerer noe, som er tilfellet med returveien.

Videresending trenger tre ting, ikke én

Videresending i kjernen må være aktivert, en filterregel må akseptere strømmen, og destinasjonen må være tilgjengelig med en vei for at svaret skal komme tilbake. Mangler én av de tre, er stillheten den samme sett fra klienten.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Les de tre utskriftene sammen. En null i den første gjør de to andre irrelevante, og en standard forkastelsespolitikk i den andre forkaster klientens pakker mens gatewayens egen trafikk fortsetter å virke. Den tredje utskriften viser hvorfor lytterregelen aldri var problemet.

Hold de to regelsettene atskilt i dokumentasjonen

Skriv lytterregelen og regelen for den videresendte tjenesten på separate linjer, med separate eiere og begrunnelser. Når VPN-porten endres eller en ny tjeneste publiseres, hindrer denne separasjonen at én endring stille utvider den andre.

I stedet for å behandle hver autentiserte peer som et klarert LAN-medlem, bruk smale regler for de klientområdene og tjenestene som trenger dem. StrongSwan sine notater om videresending beskriver returvei- og oversettelsessiden av samme grense, som igjen er en tredje beslutning.

Til slutt, hold lagene rette når en bruker avvises. Hvis forespørselen når verten og applikasjonen avviser kontoen, reparer applikasjonens tillatelse på det laget; å utvide videresendingen kan ikke skaffe påloggingsinformasjon for fildeling og vil utvide tilgangen for alle andre som kobler til med hell.