Å opne VPN-porten gir ikkje klientane tilgang til LAN

Tunnelen kjem opp, klienten autentiserer seg, men LANet bak gatewayen blir verande usynleg. Regelen som skulle rette dette, slepp VPN-porten gjennom og verkar nøyaktig som skrive, fordi han gjeld pakkar som er adresserte til gatewayen sjølv. Klienttrafikk til ein vert bak gatewayen har ein annan destinasjon og ei anna kjede. Ei vellukka innlogging endrar ikkje kva av dei to kjedene kjernen ser på.

To kjeder, to ulike destinasjonar

Skjebnen til ein pakke blir avgjord av kvar han skal, ikkje av korleis han kom. Trafikk til ein adresse på gatewayen blir levert lokalt og vurdert mot inngangsreglar. Trafikk som gatewayen sender vidare, blir vurdert mot videresendingsreglar. Det same tunellgrensesnittet kan lage begge slaga pakkar, difor kan ein regel ikkje dekkje begge oppgåvene.

Heile myta i ei setning: å tillate lyttaren seier ingenting om å tillate nettet bak han. Det er to skilde avgjerder med skilt prov, og eit grensesnittnamn på begge gjer dei ikkje til eitt.

Kva lytterregelen faktisk tillèt

Lyttarpakkar endar i VPN-prosessen, og det er nettopp dette som gjer det mogleg å reise tunnelen. Administrasjonssida til gatewayen og eit lokalt diagnostisk svar nyttar òg den eigne inngangsvegen til verten, difor lukkast ein test mot gatewayen medan alt bak han sviktar. Begge resultata er riktige, og ingen av dei handlar om LANet.

Når prosessen dekapsulerer klienttrafikk for ein annan destinasjon, går pakken inn i videresendingsvegen og treng løyve der. Vellukka autentisering avgjer kven klienten er; ho avgjer ikkje kvar han kan gå. Dei to spørsmåla har ulike eigarar, ulike loggar og ulike feilmeldingar.

Test frå ein klient, aldri frå gatewayen

Ein test som blir laga på gatewayen, følgjer den eigne utgangsvegen til verten og kan lukkast medan den videresende vegen er stengd. Start testen frå klienten og sjå på begge endane av straumen.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Viss førespurnaden dukkar opp på tun0 og ingenting når destinasjonen, blir pakken kasta etter at han kom, noko som peikar på videresendingsreglar eller filtreringa til destinasjonen sjølv. Viss ingenting dukkar opp på tun0 i det heile, sender ikkje klienten han ein gong til tunnelen, og problemet er ruting på klienten, ikkje politikk på gatewayen. Samanlikn med ein førespurnad som går rett ut og ikkje kjem attende med noko, som er tilfellet med returvegen.

Videresending krev tre ting, ikkje éin

Videresending i kjernen må vere slått på, ein filterregel må godta straumen, og destinasjonen må vere nåbar med ein veg for svaret attende. Manglar éin av dei tre, er stilla den same frå ståstaden til klienten.

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

Les dei tre utdataa saman. Ein null i det fyrste gjer dei to andre irrelevante, og ein standard forkastingspolitikk i det andre kastar pakkane til klienten medan den eigne trafikken til gatewayen held fram med å verke. Det tredje utdataet viser kvifor lytterregelen aldri var problemet.

Hald dei to regelsetta skilde i dokumentasjonen

Skriv lytterregelen og regelen for den videresende tenesta på kvar si line, med kvar sin eigar og grunngjeving. Når VPN-porten blir endra eller ei ny teneste blir publisert, hindrar denne delinga at éi endring stille utvidar den andre.

I staden for å handsame kvar autentiserte part som eit klarert LAN-medlem, bruk smale reglar for dei klientområda og tenestene som treng dei. StrongSwan sine notat om videresending skildrar returveg- og omsetningssida av den same grensa, som igjen er ei tredje avgjerd.

Til slutt, hald laga rette når ein brukar blir avvist. Viss førespurnaden når verten og applikasjonen avviser kontoen, reparer løyvet til applikasjonen på det laget; å utvide videresendinga kan ikkje skaffe innloggingsdetaljar for fildeling og vil utvide tilgangen for alle andre som koplar seg til med hell.