VPN-klienter ansluter men har inget internet: tre saknade delar

Klienten får en adress, servern svarar på ping, och ändå tar varje sida slut på tid. De flesta börjar redigera klientprofilen vid denna punkt, vilket oftast är bortkastat arbete: när tunneln är uppe måste servern bete sig som en router. Tre villkor måste gälla samtidigt innan ett paket lämnar och ett svar kommer tillbaka, och symtomet är detsamma vilket som än saknas.

Varför en fungerande tunnel fortfarande inte har någon väg ut

Kärnan måste vidarebefordra paket mellan gränssnitt, vilket är avstängt som standard på de flesta Linux-distributioner. Trafiken måste översättas till en adress som omvärlden kan svara på, såvida inte varje uppströmsrouter redan känner till returvägen till tunnelns subnät. Brandväggens vidarebefordringsväg måste tillåta trafiken i båda riktningarna, inklusive svaren.

Var och en av dessa kan åtgärdas separat, och det är fällan. Slår man på vidarebefordran utan en översättningsregel lämnar paketen med en privat källa och utan returväg. Lägger man till översättning utan en vidarebefordringsregel låter man kärnan släppa paketet ett steg senare.

Testa därför de tre lagren i stället för klienten, och ändra ett i taget så att resultatet betyder något.

Vidarebefordran är en kärnbrytare du måste göra beständig

Kontrollera det aktuella värdet innan du ändrar det, ställ sedan in det och bekräfta att ändringen trädde i kraft.

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

Det första kommandot rapporterar det aktuella värdet, det andra ställer in det vid körning och det tredje bevisar att skrivningen fungerade. Körningsvärdet försvinner vid nästa omstart, och därför kan en fungerande session gå sönder efter underhåll utan någon konfigurationsändring.

Gör det beständigt i en fil under /etc/sysctl.d/, och tillämpa sedan den filen i stället för att starta om för att ta reda på det. På FreeBSD är motsvarigheten net.inet.ip.forwarding, med gateway_enable=YES i rc.conf för beständighet. En enhet som rapporterar att vidarebefordran är avstängd förklarar en hel klass av rapporter om „paket kommer fram och ingenting kommer tillbaka”. Kontrollera inställningen även efter varje uppgradering, eftersom en ombyggd kärna eller en utbytt enhetsbild kan återställa den utan att berätta det för någon.

Välj masquerade eller en fast översättningsadress

Med en dynamisk yttre adress är masquerading den enklaste korrekta formen. Ange tunnelns subnät som källa och det yttre gränssnittet som utgång.

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

Med en statisk offentlig adress är källöversättning till just den adressen mer förutsägbar och lättare att granska.

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

Den andra formen bär en underhållsfälla: en hårdkodad adress som senare ändras håller tunneln igång medan internetåtkomsten tyst upphör. Använd antingen masquerade eller uppdatera regeln varje gång leverantören flyttar dig. Gränssnittet spelar också roll, eftersom en router som delar sin egen uppströmstunnel måste översätta ut genom den tunneln och inte genom det fysiska WAN:et.

Filtabellen är den tredje porten

Vidarebefordran och översättning kan båda vara korrekta medan paketet ändå dör i filtatabellen. ufw är en vanlig boven: dess vidarebefordringspolicy levereras som DROP, och resten av uppsättningen kan se helt korrekt ut medan den enda inställningen dödar trafiken. Att höja den är ett medvetet säkerhetsbeslut och inte en kryssruta.

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örsta regeln tillåter ny trafik från tunneln utåt, och den andra bara svar tillbaka. Begränsa båda till tunnelns subnät och den avsedda destinationen, eftersom ett generellt tillstånd på tunnelgränssnittet gör VPN:et till en öppen utgångspunkt för alla som kan autentisera sig.

En bryggad tunnel behöver ett annat svar. Adressen tillhör bryggan, inte den fysiska porten, så att göra gränssnittet till slav tar bort adressen det hade tidigare och värden verkar oåtkomlig tills bryggan själv får en, vilket dhclient br0 kan leverera. Det felet ser ut som ett VPN-problem och är ett problem på lager två. Kontrollera bryggans egen adress innan du rör brandväggen, eftersom en filterändring inte kan reparera en värd som inte längre har en adress att skicka från.

Var du ska titta när en sida aldrig laddas

Pinga serverns tunneladress för att bevisa att tunneln finns. Kör sedan en traceroute från klienten till en offentlig adress och läs var den stannar: vid servern kommer paketet fram men vidarebefordras eller översätts inte; bortom servern är problemet uppströms och utanför dina händer.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Det första kommandot bevisar att tunneln bär trafik till servern själv, och det andra visar hur långt ett paket kommer utåt. Ett spår som slutar på tunneladressen pekar på vidarebefordran eller översättning på servern, medan ett spår som stannar en hopp senare pekar på leverantören eller uppströmsrouterns returväg.

På servern, håll koll på det yttre gränssnittet medan en klient laddar en sida. Trafik som går ut med en privat källadress betyder att översättning saknas, och helt uteblivet svar betyder att vidarebefordringsvägen eller den uppströms returvägen släpper den.

Om fjärrklienter också måste nå värdar på serverns LAN, kom ihåg att LAN:et behöver en returväg till tunnelns subnät. Det är routing och inte översättning, och det är steget som oftast glöms bort när internetvägen äntligen fungerar.