At åbne VPN-porten giver ikke klienterne adgang til LAN

Tunnelen kommer op, klienten godkender sig, men LAN bag gatewayen forbliver usynligt. Reglen, der skulle rette det, tillader VPN-porten og virker præcis som skrevet, fordi den regel styrer pakker adresseret til gatewayen selv. Klienttrafik til en vært bag gatewayen har en anden destination og en anden kæde. Et vellykket login ændrer ikke, hvilken af de to kernerne konsulterer.

To kæder, to forskellige destinationer

En pakkes skæbne afgøres af, hvor den skal hen, ikke af, hvordan den kom. Trafik adresseret til en adresse på gatewayen leveres lokalt og vurderes mod inputregler. Trafik, som gatewayen videresender, vurderes mod videresendelsesregler. Den samme tunneglinterfase kan producere begge slags pakker, og derfor kan én regel ikke dække begge opgaver.

Hele myten i én sætning: at tillade lytteren siger intet om at tillade netværket bag den. Det er to separate beslutninger med separate beviser, og et interfacenavn på begge forener dem ikke.

Hvad lytterreglen faktisk tillader

Lytterpakker ender i VPN-processen, og det er netop det, der gør det muligt at etablere tunnelen. Gatewayens administrationsside og et lokalt diagnostisk svar bruger også værtens egen inputvej, og derfor lykkes en test mod gatewayen, mens alt bag den fejler. Begge resultater er korrekte, og ingen af dem handler om LAN.

Når processen afkapsler klienttrafik til en anden destination, går pakken ind på videresendelsesvejen og skal have tilladelse der. En vellykket godkendelse afgør, hvem klienten er; den afgør ikke, hvor klienten må tage hen. De to spørgsmål har forskellige ejere, forskellige logfiler og forskellige fejlmeddelelser.

Test fra en klient, aldrig fra gatewayen

En test, der genereres på gatewayen, følger værtens egen outputvej og kan lykkes, mens den videresendte vej er lukket. Start testen fra klienten, og overvåg begge ender af strømmen.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Hvis anmodningen dukker op på tun0, og intet når destinationen, kastes pakken efter ankomst, hvilket peger på videresendelsesregler eller destinationens egen filtrering. Hvis intet overhovedet dukker op på tun0, sender klienten den ikke engang til tunnelen, og problemet er routing på klienten snarere end politik på gatewayen. Sammenlign med en anmodning, der går korrekt ud og intet returnerer, hvilket er tilfældet med returvejen.

Videresendelse kræver tre ting, ikke én

Videresendelse i kernen skal være aktiveret, en filterregel skal acceptere strømmen, og destinationen skal kunne nås med en vej tilbage for svaret. Mangler én af de tre, er stilheden den samme fra klientens synspunkt.

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

Læs de tre output sammen. Et nul i det første gør de to andre irrelevante, og en standard-drop-politik i det andet kaster klientens pakker, mens gatewayens egen trafik fortsat virker. Det tredje output viser, hvorfor lytterreglen aldrig var problemet.

Hold de to regelsæt adskilt i dokumentationen

Skriv lytterreglen og reglen for den videresendte tjeneste på separate linjer med separate ejere og begrundelser. Når VPN-porten ændres, eller en ny tjeneste publiceres, forhindrer denne adskillelse, at én ændring stille udvider den anden.

I stedet for at behandle hver godkendt peer som et betroet LAN-medlem, brug snævre regler for de klientområder og tjenester, der har brug for dem. StrongSwan’s noter om videresendelse beskriver returrute- og oversættelsessiden af samme grænse, hvilket igen er en tredje beslutning.

Endelig, hold lagene lige, når en bruger afvises. Hvis anmodningen når værten, og applikationen afviser kontoen, skal du rette applikationens tilladelse på det lag; at udvide videresendelsen kan ikke levere en legitimationsoplysning til fildeling og vil udvide adgangen for alle andre, der forbinder med succes.