VPN-klientar koplar til, men har ikkje internett: tre manglande delar

Klienten får ein adresse, serveren svarar på ping, og kvar side går likevel ut på tid. Dei fleste byrjar på dette punktet å redigere klientprofilen, noko som vanlegvis er bortkasta arbeid: når tunnelen er oppe, må serveren oppføre seg som ein ruter. Tre vilkår må gjelde samtidig før ein pakke forlèt noko og eit svar kjem tilbake, og symptomet er det same kva ein som manglar.

Kvifor ein fungerande tunnel framleis ikkje har nokon veg ut

Kjernen må videresende pakkar mellom grensesnitt, noko som er slått av som standard på dei fleste Linux-distribusjonar. Trafikken må omsetjast til ei adresse som omverda kan svare på, med mindre kvar oppstraumsruter allereie kjenner returvegen til subnettet til tunnelen. Videresendingsvegen til brannmuren må tillate trafikken i begge retningar, inkludert svara.

Kvar av desse kan rettast uavhengig, og det er fella. Slår du på videresending utan ein omsetjingsregel, forlèt pakkane med ein privat kjelde og utan returveg. Legg du til omsetjing utan ein videresendingsregel, lèt kjernen pakken falle eitt steg seinare.

Test difor dei tre laga i staden for klienten, og endre éin om gongen slik at resultatet betyr noko.

Videresending er ein kjernebrytar du må gjere varig

Kontroller gjeldande verdi før du endrar han, set han deretter og stadfest at endringa tredde i kraft.

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

Den første kommandoen rapporterer gjeldande verdi, den andre set han ved køyring, og den tredje beviser at skrivinga verka. Køyringsverdien forsvinn ved neste omstart, og difor kan ein fungerande sesjon bryte saman etter vedlikehald utan noka konfigurasjonsendring.

Gjer han varig i ei fil under /etc/sysctl.d/, og bruk deretter den fila i staden for å starte på nytt for å finne det ut. På FreeBSD er ekvivalenten net.inet.ip.forwarding, med gateway_enable=YES i rc.conf for varigheit. Eining som rapporterer videresending deaktivert, forklarer ein heil klasse rapportar om „pakkar kjem og ingenting kjem tilbake”. Kontroller innstillinga også etter kvar oppgradering, for ein gjenoppbygd kjerne eller eit erstatta einingbilde kan nullstille henne utan å fortelje nokon det.

Vel masquerade eller éi fast omsetjingsadresse

Med ei dynamisk utvendig adresse er masquerading den enklaste korrekte forma. Angi subnettet til tunnelen som kjelde og det utvendige grensesnittet som utgang.

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

Med ei statisk offentleg adresse er kjeldeomsetjing til nettopp den adressa meir føreseieleg og lettare å revidere.

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

Den andre forma ber ei vedlikehaldsfelle: ei hardkoda adresse som seinare vert endra held tunnelen i gang medan internettilgangen stille stoppar. Bruk anten masquerade eller oppdater regelen kvar gong leverandøren flyttar deg. Grensesnittet betyr også noko, fordi ein ruter som deler sin eigen oppstraumstunnel må omsetje ut gjennom den tunnelen og ikkje gjennom det fysiske WAN-et.

Filtertabellen er den tredje porten

Videresending og omsetjing kan begge vere riktige medan pakken likevel døyr i filtertabellen. ufw er ein hyppig syndar: videresendingspolicyen vert levert som DROP, og resten av oppsettet kan sjå heilt riktig ut medan den eine innstillinga drep trafikken. Å heve henne er eit medvite tryggleiksval og ikkje ein 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 tillèt ny trafikk frå tunnelen og ut, og den andre berre svar tilbake. Avgrense begge til subnettet til tunnelen og den tiltenkte destinasjonen, fordi ei generell løyve på tunnelgrensesnittet gjer VPN-en til eit ope utgangspunkt for alle som kan autentisere seg.

Ein brua tunnel treng eit anna svar. Adressa høyrer til brua, ikkje til den fysiske porten, så å gjere grensesnittet til slave fjernar adressa det hadde før, og verten verkar utilgjengeleg til brua sjølv får éi, noko dhclient br0 kan levere. Den feilen ser ut som eit VPN-problem og er eit problem på lag to. Kontroller den eiga adressa til brua før du rører brannmuren, fordi ei filterendring kan ikkje reparere ein vert som ikkje lenger har ei adresse å sende frå.

Kvar du skal sjå når ei side aldri blir lasta

Ping tunneladressa til serveren for å bevisa at tunnelen finst. Køyr deretter ein traceroute frå klienten til ei offentleg adresse og les kvar han stoppar: ved serveren kjem pakken fram, men vert ikkje videresend eller omsett; bak serveren er problemet oppstraums og utanfor hendene dine.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Den første kommandoen beviser at tunnelen ber trafikk til serveren sjølv, og den andre viser kor langt ein pakke kjem utover. Eit spor som endar på tunneladressa, peikar på videresending eller omsetjing på serveren, medan eit spor som stoppar ein hopp seinare, peikar på leverandøren eller returvegen til oppstraumsruteren.

På serveren, følg med på det utvendige grensesnittet medan ein klient lastar ei side. Trafikk som går ut med ei privat kjeldeadresse betyr at omsetjing manglar, og heilt manglande svar betyr at videresendingsvegen eller den oppstraums returruta slepp honom.

Viss fjernklientar også må nå vertar på LAN-et til serveren, hugs at LAN-et treng ein returveg til subnettet til tunnelen. Det er ruting og ikkje omsetjing, og det er steget som oftast vert gløymt når internettvegen endeleg verkar.