VPN-klienter opretter forbindelse, men har intet internet: tre manglende dele

Klienten får en adresse, serveren svarer på ping, og hver side timer stadig ud. De fleste begynder på dette punkt at redigere klientprofilen, hvilket som regel er spildt arbejde: når tunnelen er oppe, skal serveren opføre sig som en router. Tre betingelser skal gælde samtidig, før en pakke forlader noget og et svar kommer tilbage, og symptomet er det samme, uanset hvilken der mangler.

Hvorfor en fungerende tunnel stadig ikke har nogen vej ud

Kernen skal videresende pakker mellem grænseflader, og det er slået fra som standard på de fleste Linux-distributioner. Trafikken skal oversættes til en adresse, som omverdenen kan svare på, medmindre hver opstrømsrouter allerede kender returvejen til tunnelens undernet. Firewallens videresendelsesvej skal tillade trafikken i begge retninger, inklusive svarene.

Hver af dem kan rettes uafhængigt, og det er fælden. Slås videresendelse til uden en oversættelsesregel, forlader pakkerne med en privat kilde og uden returvej. Tilføjes oversættelse uden en videresendelsesregel, lader kernen pakken falde et skridt senere.

Test derfor de tre lag i stedet for klienten, og ændr ét ad gangen, så resultatet betyder noget.

Videresendelse er en kernel-kontakt, du skal gøre varig

Kontroller den aktuelle værdi, før du ændrer den, sæt den derefter, og bekræft, at ændringen trådte i kraft.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Den første kommando viser den aktuelle værdi, den anden sætter den ved kørsel, og den tredje beviser, at skrivningen virkede. Kørselsværdien forsvinder ved næste genstart, og derfor kan en fungerende session gå i stykker efter vedligeholdelse uden nogen konfigurationsændring.

Gør den varig i en fil under /etc/sysctl.d/, og anvend derefter den fil i stedet for at genstarte for at finde ud af det. På FreeBSD er ækvivalenten net.inet.ip.forwarding, med gateway_enable=YES i rc.conf for varighed. En enhed, der rapporterer videresendelse deaktiveret, forklarer en hel klasse af rapporter om „pakker ankommer, og intet kommer tilbage”. Kontroller indstillingen efter hver opgradering også, for en genopbygget kerne eller et udskiftet enhedsbillede kan nulstille den uden at fortælle nogen det.

Vælg masquerade eller én fast oversættelsesadresse

Med en dynamisk udvendig adresse er masquerading den enkleste korrekte form. Angiv tunnelens undernet som kilde og den udvendige grænseflade som udgang.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Med en statisk offentlig adresse er kildeoversættelse til netop den adresse mere forudsigelig og lettere at revidere.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Den anden form bærer en vedligeholdelsesfælde: en hårdkodet adresse, der senere ændres, holder tunnelen kørende, mens internetadgangen stille stopper. Brug enten masquerade, eller opdater reglen, når udbyderen flytter dig. Grænsefladen betyder også noget, fordi en router, der deler sin egen opstrømstunnel, skal oversætte ud gennem den tunnel og ikke gennem det fysiske WAN.

Filtertabellen er den tredje port

Videresendelse og oversættelse kan begge være korrekte, mens pakken stadig dør i filtertabellen. ufw er en hyppig synder: dens videresendelsespolitik leveres som DROP, og resten af opsætningen kan se helt korrekt ud, mens den ene indstilling dræber trafikken. At hæve den er en bevidst sikkerhedsbeslutning og ikke en afkrydsningsboks.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Den første regel tillader ny trafik fra tunnelen mod det udvendige, og den anden tillader kun svar tilbage. Indsnævr begge til tunnelens undernet og den tilsigtede destination, fordi en blanket tilladelse på tunnelgrænsefladen gør VPN’en til et åbent udgangspunkt for enhver, der kan autentificere sig.

En broet tunnel kræver et andet svar. Adressen tilhører broen, ikke den fysiske port, så at gøre grænsefladen til slave fjerner den adresse, den før havde, og værten virker uopnåelig, indtil broen selv får en, hvilket dhclient br0 kan levere. Den fejl ser ud som et VPN-problem og er et lag-to-problem. Kontroller broens egen adresse, før du rører ved firefallen, fordi en filterændring ikke kan rette en vært, der ikke længere har en adresse at sende fra.

Hvor du skal kigge, når en side aldrig indlæses

Ping serverens tunneladresse for at bevise, at tunnelen findes. Kør derefter en traceroute fra klienten til en offentlig adresse, og læs, hvor den stopper: ved serveren ankommer pakken, men videresendes eller oversættes ikke; bag serveren er problemet opstrøms og uden for din kontrol.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Den første kommando beviser, at tunnelen bærer trafik til serveren selv, og den anden viser, hvor langt en pakke når udad. Et spor, der ender på tunneladressen, peger på videresendelse eller oversættelse på serveren, mens et spor, der stopper et hop senere, peger på udbyderen eller opstrømsrouterens returvej.

På serveren skal du holde øje med den udvendige grænseflade, mens en klient indlæser en side. Trafik, der forlader med en privat kildeadresse, betyder, at oversættelse mangler, og slet intet svar betyder, at videresendelsesvejen eller den opstrøms returrute dropper den.

Hvis fjernklienter også skal nå værter på serverens LAN, skal du huske, at LAN’et har brug for en returrute til tunnelens undernet. Det er routing og ikke oversættelse, og det er det skridt, der oftest glemmes, når internetvejen endelig virker.