Å åpne VPN-porten gir ikke klientene tilgang til LAN

Tunnelen kommer opp, klienten autentiserer seg, men LAN-et bak gatewayen forblir usynlig. Regelen som skulle rette dette, tillater VPN-porten og virker nøyaktig som skrevet, fordi den regelen gjelder pakker som er adressert til gatewayen selv. Klienttrafikk til en vert bak gatewayen har en annen destinasjon og en annen kjede. En vellykket innlogging endrer ikke hvilken av de to kjedene kjernen undersøker.

To kjeder, to forskjellige destinasjoner

En pakkes skjebne avgjøres av hvor den skal, ikke av hvordan den kom. Trafikk til en adresse på gatewayen leveres lokalt og vurderes mot inngangsregler. Trafikk som gatewayen videresender, vurderes mot videresendingsregler. Det samme tunellgrensesnittet kan produsere begge slags pakker, derfor kan én regel ikke dekke begge oppgavene.

Hele myten i én setning: å tillate lytteren sier ingenting om å tillate nettet bak den. Det er to separate beslutninger med separate bevis, og et grensesnittnavn på begge forener dem ikke.

Hva lytterregelen faktisk tillater

Lytterpakker ender i VPN-prosessen, og det er nettopp dette som gjør det mulig å etablere tunnelen. Administrasjonssiden til gatewayen og et lokalt diagnostisk svar bruker også vertens egen inngangsvei, derfor lykkes en test mot gatewayen mens alt bak den feiler. Begge resultatene er riktige, 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 kan gå. De to spørsmålene har ulike eiere, ulike logger og ulike feilmeldinger.

Test fra en klient, aldri fra gatewayen

En test som lages på gatewayen, følger vertens egen utgangsvei og kan lykkes mens den videresendte veien er stengt. Start testen fra klienten og se på begge endene 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 destinasjonen, blir pakken forkastet etter ankomst, noe som peker på 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 krever tre ting, ikke én

Videresending i kjernen må være slått på, en filterregel må godta strømmen, og destinasjonen må være nåbar med en vei for svaret tilbake. Mangler én av de tre, er stillheten den samme fra klientens ståsted.

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

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

Hold de to regelsettene atskilt i dokumentasjonen

Skriv lytterregelen og regelen for den videresendte tjenesten på hver sin linje, med hver sin eier og begrunnelse. Når VPN-porten endres eller en ny tjeneste publiseres, hindrer denne delingen 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. StrongSwans notater om videresending beskriver returvei- og oversettelsessiden av den samme grensen, 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.