VPN-klienter kobler til, men har ikke internett: tre manglende deler

Klienten får en adresse, serveren svarer på ping, og hver side timer likevel ut. De fleste begynner på dette punktet å redigere klientprofilen, noe som vanligvis er bortkastet arbeid: når tunnelen er oppe, må serveren oppføre seg som en ruter. Tre betingelser må gjelde samtidig før en pakke forlater noe og et svar kommer tilbake, og symptomet er det samme uansett hvilken som mangler.

Hvorfor en fungerende tunnel fortsatt ikke har noen vei ut

Kjernen må videresende pakker mellom grensesnitt, noe som er slått av som standard på de fleste Linux-distribusjoner. Trafikken må oversettes til en adresse som omverdenen kan svare på, med mindre hver oppstrømsruter allerede kjenner returveien til tunnelens subnett. Brannmurens videresendingsvei må tillate trafikken i begge retninger, inkludert svarene.

Hver av disse kan rettes uavhengig, og det er fellen. Slår du på videresending uten en oversettelsesregel, forlater pakkene med en privat kilde og uten returvei. Legger du til oversettelse uten en videresendingsregel, lar kjernen pakken falle ett steg senere.

Test derfor de tre lagene i stedet for klienten, og endre én om gangen slik at resultatet betyr noe.

Videresending er en kjernebryter du må gjøre varig

Kontroller gjeldende verdi før du endrer den, sett den deretter og bekreft at endringen trådte i kraft.

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

Den første kommandoen rapporterer gjeldende verdi, den andre setter den ved kjøring, og den tredje beviser at skrivingen virket. Kjøringsverdien forsvinner ved neste omstart, og derfor kan en fungerende sesjon bryte sammen etter vedlikehold uten noen konfigurasjonsendring.

Gjør den varig i en fil under /etc/sysctl.d/, og bruk deretter den filen i stedet for å starte på nytt for å finne det ut. På FreeBSD er ekvivalenten net.inet.ip.forwarding, med gateway_enable=YES i rc.conf for varighet. En enhet som rapporterer videresending deaktivert, forklarer en hel klasse rapporter om „pakker ankommer og ingenting kommer tilbake”. Kontroller innstillingen også etter hver oppgradering, for en gjenoppbygd kjerne eller et erstattet enhetsbilde kan tilbakestille den uten å fortelle noen det.

Velg masquerade eller én fast oversettelsesadresse

Med en dynamisk utvendig adresse er masquerading den enkleste korrekte formen. Angi tunnelens subnett som kilde og det utvendige grensesnittet som utgang.

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

Med en statisk offentlig adresse er kildeoversettelse til nettopp den adressen mer forutsigbar og lettere å revidere.

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

Den andre formen bærer en vedlikeholdsfelle: en hardkodet adresse som senere endres holder tunnelen i gang mens internettilgangen stille stopper. Bruk enten masquerade eller oppdater regelen hver gang leverandøren flytter deg. Grensesnittet betyr også noe, fordi en ruter som deler sin egen oppstrømstunnel må oversette ut gjennom den tunnelen og ikke gjennom det fysiske WAN-et.

Filtertabellen er den tredje porten

Videresending og oversettelse kan begge være riktige mens pakken likevel dør i filtertabellen. ufw er en hyppig synder: videresendingspolicyen leveres som DROP, og resten av oppsettet kan se helt riktig ut mens den ene innstillingen dreper trafikken. Å heve den er en bevisst sikkerhetsbeslutning og ikke en avkrysningsboks.

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 regelen tillater ny trafikk fra tunnelen og ut, og den andre bare svar tilbake. Begrens begge til tunnelens subnett og den tiltenkte destinasjonen, fordi en generell tillatelse på tunnelgrensesnittet gjør VPN-en til et åpent utgangspunkt for alle som kan autentisere seg.

En broet tunnel trenger et annet svar. Adressen tilhører broen, ikke den fysiske porten, så å gjøre grensesnittet til slave fjerner adressen den hadde før, og verten virker utilgjengelig til broen selv får en, noe dhclient br0 kan levere. Den feilen ser ut som et VPN-problem og er et problem på lag to. Kontroller broens egen adresse før du rører brannmuren, fordi en filterendring ikke kan reparere en vert som ikke lenger har en adresse å sende fra.

Hvor du skal se når en side aldri lastes

Ping serverens tunneladresse for å bevise at tunnelen finnes. Kjør deretter en traceroute fra klienten til en offentlig adresse og les hvor den stopper: ved serveren kommer pakken frem, men blir ikke videresendt eller oversatt; bak serveren er problemet oppstrøms og utenfor dine hender.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Den første kommandoen beviser at tunnelen bærer trafikk til serveren selv, og den andre viser hvor langt en pakke kommer utover. Et spor som ender på tunneladressen, peker på videresending eller oversettelse på serveren, mens et spor som stopper en hopp senere, peker på leverandøren eller oppstrømsruterens returvei.

På serveren, følg med på det utvendige grensesnittet mens en klient laster en side. Trafikk som forlater med en privat kildeadresse betyr at oversettelse mangler, og helt manglende svar betyr at videresendingsveien eller den oppstrøms returruten slipper den.

Hvis fjernklienter også må nå verter på serverens LAN, husk at LAN-et trenger en returrute til tunnelens subnett. Det er ruting og ikke oversettelse, og det er trinnet som oftest glemmes når internettveien endelig virker.