Tunneln uppe, inget internet: där vidarebefordran stannar

Klienten ansluter, tunneln bär ping till gatewayen, och inget bortom den svarar. Det tillståndet är normalt för en gateway som bara någonsin var avsedd att ge åtkomst till skyddade nät, och det är ett fel för en som annonseras som fulltunnel-utgång. Bekräfta vilken tjänst som utlovades innan du ändrar regler. Följ sedan en enda offentlig begäran genom de fyra ställen där den kan stanna. En begäran och en paketinsamling avgör mer än en sida gissningar.

Bekräfta om internetutgång någonsin var designen

En split-tunnel-profil dirigerar bara de skyddade subnäten in i VPN:et, så offentligt surfande fortsätter över den lokala länken och når aldrig gatewayen. En fulltunnel-profil installerar en standardrutt i tunneln, vilket gör gatewayen ansvarig för hela vägen. Båda är legitima konstruktioner, och att blanda ihop dem ger en felrapport där det inte finns någon. Läs klientens annonserade rutter innan du testar något annat, för rutttabellen besvarar frågan som ärendet oftast får fel.

Det klienten installerar är inte alltid det profilen avser. En pushad rutt kan åsidosättas av en lokal rutt med lägre metrik, och en klient som behåller sin LAN-rutt medan den lägger till en standardrutt beter sig som en split-tunnel för det subnätet.

Följ en enda offentlig begäran

Välj en enda destination och följ den från klienten och utåt. Kontrollera på klienten att paketet verkligen väljer tunneln och vilken lokal adress det använder som källa. Kontrollera sedan gatewayen: kommer paketet fram, och lämnar det det offentliga gränssnittet. Vart och ett av svaren tar bort en hel orsakskategori.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Om gatewayen aldrig ser paketet är klientrutten eller tunnelvalet fel. Om det kommer fram och inte lämnar ligger problemet på gatewayen, och de återstående tre kontrollerna gäller.

Kontrollera vidarebefordran, rutt och översättning

Den vidarebefordringsguide som följer med strongSwan gäller för en gateway av vilken tunneltyp som helst: kärnan måste tillåtas flytta paket mellan gränssnitt, och en användbar rutt måste peka mot internet. Brandväggspolicyn måste sedan tillåta trafiken, och källadressen måste vara en som den offentliga sidan kan svara på. En privat klientadress som vidarebefordras oförändrad till internet får aldrig något svar.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Källöversättning är den vanliga saknade pusselbiten. Med den skriver gatewayen om klientens källa till sin offentliga adress och följer flödet; utan den har svaret ingenstans att ta vägen. Molnplattformar lägger till en andra gräns, där instansens rutttabell eller säkerhetsgrupp kan släppa trafik som gästens brandvägg tillåter. Den gränsen är lätt att missa eftersom gästsystemet ser korrekt konfigurerat ut inifrån.

Reverse-path-filtrering i en asymmetrisk uppsättning kan också kasta giltiga paket. Läs räknaren på den regeln i stället för att anta att den är i ordning, för en strikt inställning på det offentliga gränssnittet avvisar trafik som kommer via en annan väg än rutttabellen förutspår.

Svarsväg och resolver är två olika svar

Håll också utkik efter svaret, inte bara begäran. Om begäran går ut översatt och svaret återvänder till det översatta flödet fungerar vidarebefordran även när applikationen fortfarande misslyckas, och nästa undersökning hör till applikationen eller till DNS.

En webbplats som returnerar ett HTTP-fel är bevis på att internetvidarebefordran fungerar. Ett namn som inte löses upp medan adressåtkomst fungerar är ett resolverproblem, inte ett NAT-problem.

Testa klienten igen efter en snäv rättelse, tillsammans med varje avsiktligt begränsad privat resurs. Att bevilja internetåtkomst får inte tyst utöka åtkomsten till varje nät som hänger på gatewayen.