Fuld tunnel OpenVPN: tilføj en internetudgang på serversiden

En klient godkender sig, modtager en adresse fra puljen og når tjenester på VPN-værten, men hver offentlig destination løber ud i tid. Sådan ser en tunnel uden udgang ud, og sådan bliver det, indtil fire adskilte ting er opfyldt. Klienten skal acceptere en standardrute, serveren skal videresende, firewallen skal tillade gennemgangen, og svar har brug for en vej tilbage til puljen. Alle fire fejl deler ét symptom, så skift én ting ad gangen og notér resultatet.

Skub standardruten ud og bekræft, hvad klienten installerede

Linjen på serversiden er kort, og den påvirker kun klienter, der accepterer pushede valgmuligheder. def1-formen installerer to halve standardruter i stedet for at slette den eksisterende standard, hvilket holder den nuværende forbindelse i live, mens den stadig fanger hver destination.

push "redirect-gateway def1"

Når du har genoprettet forbindelsen, skal du læse klientens rutetabel i stedet for at stole på profilen. På Linux vises de to /1-poster ved siden af den oprindelige standardrute, og Windows viser det samme par som 0.0.0.0/1 og 128.0.0.0/1. En klient, der ignorerer pushede valgmuligheder, eller en der er konfigureret til at afvise dem, beholder sin gamle standardrute og sender aldrig internettrafik ind i tunnelen. Afgør det spørgsmål, før du ændrer noget på serveren, for ingen regel på serversiden kan kompensere.

Videresendelse er en serverindstilling, ikke en VPN-indstilling

Læs videresendelsesflaget, før du rører ved routingen. Et nul der betyder, at kernen modtager klientens pakke og afviser at sende den videre, hvilket ser præcis ud som en firewallblokering fra den anden ende. Sæt værdien via systemets konfigurationsmappe, så den overlever en genstart.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Bekræft derefter, at værten selv har en fungerende rute til internetudgangen. En anmodning fra serverens shell beviser, at den opstrøms vej er brugbar, og siger intet som helst om at videresende en klients pakke, så behandl dem som to separate tests. Hvis serveren ikke kan nå destinationen, hjælper ingen mængde videresendelseskonfiguration.

Tillad netop den gennemgang, du tilsigter, og intet andet

Videresendte pakker krydser forward-stien; trafik rettet mod VPN-værten selv krydser input. Det er forskellige beslutninger, og at åbne input-stien tillader ikke gennemgang gennem maskinen. At blande dem sammen er den mest almindelige grund til, at en firewall ser ud til at tillade alt, mens klienterne stadig går i tid.

En minimal politik accepterer nye forbindelser fra puljen mod udgangsgrænsefladen og accepterer svar, der hører til etablerede flows. Læg den i den regelsætsejer, din distribution bruger, i stedet for at tilføje en dubleret regel ved hver opstart; dublerede regler hober sig op, og tællerne holder op med at betyde noget.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

At skifte hver kæde til accept får testen til at bestå og fjerner grunden til, at firewallen findes. Hold omfanget til puljen og udgangsgrænsefladen, og lad uvedkommende videresendelse være.

Giv svarene et sted at gå hen

Puljeadresser er private, så en offentlig server kan ikke levere et svar direkte til dem. Enten oversætter VPN-værten kildeadressen på vej ud, eller også har en enhed opstrøms en rute tilbage til puljen.

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

Tilføj præcis ét oversættelseslag. En anden NAT længere opstrøms skjuler den første og gør begge logfiler næsten ubrugelige, når noget senere går i stykker. Hvis en router opstrøms allerede ruter puljen tilbage, er oversættelse på værten overflødig, og returvejen afhænger så af den routers konfiguration i stedet for din.

Cloud-instanser tilføjer endnu en port, fordi nogle platforme dropper pakker, hvis kildeadresse ikke er instansens egen, medmindre den kontrol lempes. Den indstilling ligger uden for gæsten og er let at glemme, når en lokal testmaskine virker.

Bevis det fra klienten, ikke fra serverens shell

Start med en numerisk IPv4-anmodning, derefter et navneopslag, derefter applikationen. En ping beviser videresendelse og oversættelse;den beviser intet om navneopløsning, fordi DNS-valgmuligheder først træder i kraft, når klientintegrationen installerer dem.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Notér ændringerne og fortrydelsestrinet undervejs, så udgangspolitikken kan rulles tilbage i én handling, når en test fejler. Denne opskrift dækker kun IPv4; kortlæg IPv6 separat, før du hævder, at implementeringen bærer al trafik.