VPN-kliënte maak verbinding maar het geen internet: drie ontbrekende stukke

Die kliënt kry ’n adres, die bediener beantwoord pings, en elke bladsy time steeds uit. Die meeste mense begin op hierdie punt die kliëntprofiel wysig, wat gewoonlik vermorsde moeite is: sodra die tonnel op is, moet die bediener soos ’n router optree. Drie voorwaardes moet gelyktydig geld voordat ’n pakket uitgaan en ’n antwoord terugkom, en die simptoom is dieselfde watter een ook al ontbreek.

Waarom ’n werkende tonnel steeds geen uitgang het nie

Die kern moet pakkette tussen koppelvlakke deurstuur, wat by die meeste Linux-verspreidings af is. Die verkeer moet na ’n adres vertaal word wat die buitewêreld kan beantwoord, tensy elke opstroom-router reeds die terugroete na die tonnel-subnet ken. Die brandmuur se deurstuurpad moet die verkeer in beide rigtings toelaat, insluitend die antwoorde.

Elkeen daarvan kan onafhanklik reggestel word, en dit is die lokval. Deurstuur aan te skakel sonder ’n vertaalreël laat pakkette uitgaan met ’n private bron en geen terugpad nie. Vertaling by te voeg sonder ’n deurstuur-reël laat die kern die pakket een stap later laat val.

Toets dus die drie lae eerder as die kliënt, en verander een op ’n slag sodat die resultaat iets beteken.

Deurstuur is ’n kernskakelaar wat jy blywend moet maak

Kyk na die huidige waarde voordat jy dit verander, stel dit dan en bevestig dat die verandering in werking getree het.

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

Die eerste opdrag gee die huidige waarde, die tweede stel dit tydens looptyd, en die derde bewys die skryf het gewerk. Die looptydwaarde verdwyn by die volgende herbegin, en daarom kan ’n werkende sessie ná onderhoud breek sonder enige konfigurasieverandering.

Maak dit blywend in ’n lêer onder /etc/sysctl.d/, en pas daardie lêer dan toe eerder as om te herbegin om uit te vind. Op FreeBSD is die ekwivalent net.inet.ip.forwarding, met gateway_enable=YES in rc.conf vir blywendheid. ’n Toestel wat deurstuur as gedeaktiveer rapporteer, verklaar ’n hele klas verslae van „pakkette kom aan en niks kom terug nie”. Kyk ook ná elke opgradering na die instelling, want ’n herboude kern of ’n vervangingstoestelbeeld kan dit terugstel sonder om iemand te vertel.

Kies masquerade of een vaste vertaaladres

Met ’n dinamiese buiteadres is masquerading die eenvoudigste korrekte vorm. Noem die tonnel-subnet as die bron en die buitenste koppelvlak as die uitgang.

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

Met ’n statiese openbare adres is brontranslasie na daardie presiese adres meer voorspelbaar en makliker om te oudit.

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

Die tweede vorm dra ’n onderhoudslokval: ’n hardgekodeerde adres wat later verander, hou die tonnel aan die werk terwyl internettoegang stilweg stop. Gebruik óf masquerade óf werk die reël by wanneer die verskaffer jou skuif. Die koppelvlak maak ook saak, want ’n router wat sy eie opstroom-tonnel deel moet deur daardie tonnel vertaal eerder as deur die fisiese WAN.

Die filtertabel is die derde hek

Deurstuur en vertaling kan albei korrek wees terwyl die pakket steeds in die filtertabel sterf. ufw is ’n gereelde oortreder: sy deurstuurbeleid word as DROP verskeep, en die res van die opstelling kan heeltemal korrek lyk terwyl daardie een instelling die verkeer doodmaak. Om dit te verhoog is ’n doelbewuste sekuriteitsbesluit eerder as ’n merkblokkie.

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

Die eerste reël laat nuwe verkeer van die tonnel na die buitekant toe, en die tweede laat net antwoorde terug. Vernou albei tot die tonnel-subnet en die bestemming wat jy bedoel, want ’n algemene toelating op die tonnel-koppelvlak maak die VPN ’n oop uitgangspunt vir elkeen wat kan authentiseer.

’n Oorbrugde tonnel vra ’n ander antwoord. Die adres behoort aan die brug, nie aan die fisiese poort nie, so om die koppelvlak in te span verwyder die adres wat dit vroeër gehad het en die gasheer lyk onbereikbaar totdat die brug self een kry, wat dhclient br0 kan verskaf. Daardie faling lyk soos ’n VPN-probleem en is ’n laag-twee-probleem. Kyk na die brug se eie adres voordat jy aan die brandmuur raak, want ’n filterverandering kan nie ’n gasheer regstel wat nie meer ’n adres het om van te stuur nie.

Waar om te kyk wanneer ’n bladsy nooit laai nie

Ping die bediener se tonneladres om te bewys die tonnel bestaan. Hardloop dan ’n traceroute van die kliënt na ’n openbare adres en lees waar dit stop: by die bediener kom die pakket aan maar word nie deurgestuur of vertaal nie; anderkant die bediener is die probleem opstroom en buite jou hande.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Die eerste opdrag bewys die tonnel dra verkeer na die bediener self, en die tweede wys hoe ver ’n pakket na die buitekant kom. ’n Spoor wat by die tonneladres eindig, wys na deurstuur of vertaling op die bediener, terwyl ’n spoor wat een hop later stop, wys na die verskaffer of die opstroom-router se terugroete.

Kyk op die bediener na die buitenste koppelvlak terwyl ’n kliënt ’n bladsy laai. Verkeer wat met ’n private bronadres uitgaan, beteken vertaling ontbreek, en glad geen antwoord beteken die deurstuurpad of die opstroom-terugroete laat dit val.

As afgeleë kliënte ook gashere op die bediener se LAN moet bereik, onthou dat die LAN ’n terugroete na die tonnel-subnet nodig het. Dit is roetering eerder as vertaling, en dit is die stap wat die meeste vergeet word nadat die internetpad uiteindelik werk.