Tunnel oppe, ingen internet: hvor videresendelsen stopper

Klienten opretter forbindelse, tunnelen bærer ping til gatewayen, og intet bag den svarer. Den tilstand er normal for en gateway, der kun nogensinde var ment som adgang til beskyttede netværk, og den er en fejl for en, der annonceres som fuldtunnel-udgang. Bekræft, hvilken tjeneste der blev lovet, før du ændrer regler. Følg derefter én enkelt offentlig anmodning gennem de fire steder, hvor den kan stoppe. Én anmodning og én pakkeoptagelse afgør mere end en side fuld af gæt.

Bekræft, om internetudgang nogensinde var designet

En split-tunnel-profil sender kun de beskyttede undernet ind i VPN'et, så offentlig browsing fortsætter over det lokale link og rører aldrig gatewayen. En fuldtunnel-profil installerer en standardrute i tunnelen, hvilket gør gatewayen ansvarlig for hele vejen. Begge er legitime designs, og at forveksle dem giver en fejlrapport, hvor der ingen er. Læs klientens annoncerede ruter, før du tester noget andet, for rutetabellen besvarer det spørgsmål, som sagen normalt får forkert.

Det, klienten installerer, er ikke altid det, profilen tilsigter. En skubbet rute kan tilsidesættes af en lokal rute med lavere metrik, og en klient, der beholder sin LAN-rute, mens den tilføjer en standardrute, opfører sig som en split-tunnel for det undernet.

Følg én enkelt offentlig anmodning

Vælg én enkelt destination, og følg den fra klienten og udad. Kontroller på klienten, at pakken faktisk vælger tunnelen, og hvilken lokal adresse den bruger som kilde. Kontroller derefter gatewayen: ankommer pakken, og forlader den den offentlige grænseflade. Hvert af de svar fjerner en hel årsagskategori.

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

Hvis gatewayen aldrig ser pakken, er klientruten eller tunnelvalget forkert. Hvis den ankommer og ikke forlader, ligger problemet på gatewayen, og de resterende tre kontroller gælder.

Kontroller videresendelse, rute og oversættelse

Den videresendelsesvejledning, der følger med strongSwan, gælder for en gateway af enhver tunneltype: kernen skal have lov til at flytte pakker mellem grænseflader, og en brugbar rute skal pege mod internettet. Firewallpolitikken skal derefter tillade trafikken, og kildeadressen skal være en, som den offentlige side kan svare på. En privat klientadresse, der videresendes uændret til internettet, får aldrig et 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

Kildeoversættelse er det sædvanlige manglende stykke. Med den omskriver gatewayen klientkilden til sin offentlige adresse og følger strømmen; uden den har svaret ingen steder at gå hen. Cloudplatforme tilføjer en anden grænse, hvor instansens rutetabel eller sikkerhedsgruppe kan droppe trafik, som gæstens firewall tillader. Den grænse er let at overse, fordi gæstesystemet ser korrekt konfigureret ud indefra.

Reverse-path-filtrering på en asymmetrisk opsætning kan også kassere gyldige pakker. Læs tælleren på den regel i stedet for at antage, at den er i orden, for en streng indstilling på den offentlige grænseflade afviser trafik, der ankommer ad en anden vej, end rutetabellen forudsiger.

Svarvej og resolver er to forskellige svar

Hold også øje med svaret, ikke kun anmodningen. Hvis anmodningen går ud oversat, og svaret vender tilbage til den oversatte strøm, virker videresendelsen, selv når programmet stadig fejler, og den næste undersøgelse hører til programmet eller til DNS.

Et websted, der returnerer en HTTP-fejl, er bevis på, at internetvideresendelsen virker. Et navn, der ikke kan slås op, mens adresseadgang virker, er et resolverproblem, ikke et NAT-problem.

Test klienten igen efter en snæver rettelse, sammen med enhver bevidst begrænset privat ressource. At give internetadgang må ikke stille udvide adgangen til hvert netværk, der hænger på gatewayen.