Tunnelen oppe, ingen internett: der videresendingen stopper

Klienten kobler til, tunnelen bærer ping til gatewayen, og ingenting bak den svarer. Den tilstanden er normal for en gateway som bare noen gang var ment å gi tilgang til beskyttede nett, og den er en feil for en som annonseres som fulltunnel-utgang. Bekreft hvilken tjeneste som ble lovet før du endrer regler. Følg deretter én enkelt offentlig forespørsel gjennom de fire stedene den kan stoppe. Én forespørsel og én pakkefangst avgjør mer enn en side med gjetninger.

Bekreft om internettutgang noen gang var designet

En split-tunnel-profil ruter bare de beskyttede subnettene inn i VPN-et, så offentlig surfing fortsetter over den lokale lenken og berører aldri gatewayen. En fulltunnel-profil installerer en standardrute i tunnelen, noe som gjør gatewayen ansvarlig for hele veien. Begge er legitime design, og å forveksle dem gir en feilrapport der det ikke finnes noen. Les klientens annonserte ruter før du tester noe annet, for rutetabellen besvarer spørsmålet saken vanligvis får feil.

Det klienten installerer, er ikke alltid det profilen har tenkt. En pushet rute kan overstyres av en lokal rute med lavere metrikk, og en klient som beholder LAN-ruten mens den legger til en standardrute, oppfører seg som en split-tunnel for det subnettet.

Følg én enkelt offentlig forespørsel

Velg én enkelt destinasjon og følg den fra klienten og utover. Kontroller på klienten at pakken faktisk velger tunnelen, og hvilken lokal adresse den bruker som kilde. Kontroller deretter gatewayen: kommer pakken frem, og forlater den det offentlige grensesnittet. Hvert av disse svarene fjerner en hel kategori av årsaker.

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 aldri ser pakken, er klientruten eller tunnelvalget feil. Hvis den kommer frem og ikke drar videre, ligger problemet på gatewayen, og de tre gjenstående kontrollene gjelder.

Kontroller videresending, rute og oversettelse

Den videresendingsveiledningen som følger med strongSwan, gjelder for en gateway av enhver tunneltype: kjernen må få lov til å flytte pakker mellom grensesnitt, og en brukbar rute må peke mot internett. Brannmurpolicyen må deretter tillate trafikken, og kildeadressen må være en den offentlige siden kan svare på. En privat klientadresse som videresendes uendret til internett, får aldri noe 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

Kildeoversettelse er den vanlige manglende brikken. Med den skriver gatewayen om klientkilden til sin offentlige adresse og følger strømmen; uten den har svaret ingen steder å gå. Skyplattformer legger til en andre grense, der instansens rutetabell eller sikkerhetsgruppe kan droppe trafikk som gjestebrannmuren tillater. Den grensen er lett å overse fordi gjestesystemet ser riktig konfigurert ut fra innsiden.

Reverse-path-filtrering i en asymmetrisk oppsetning kan også forkaste gyldige pakker. Les telleren på den regelen i stedet for å anta at den er i orden, for en streng innstilling på det offentlige grensesnittet avviser trafikk som kommer via en annen vei enn rutetabellen forutsier.

Svarvei og resolver er to forskjellige svar

Følg også med på svaret, ikke bare forespørselen. Hvis forespørselen går ut oversatt og svaret kommer tilbake til den oversatte strømmen, virker videresendingen selv når applikasjonen fortsatt feiler, og neste undersøkelse hører til applikasjonen eller til DNS.

Et nettsted som returnerer en HTTP-feil, er bevis på at internettvideresendingen virker. Et navn som ikke lar seg slå opp mens adresstilgang virker, er et resolverproblem, ikke et NAT-problem.

Test klienten på nytt etter en smal rettelse, sammen med enhver bevisst begrenset privat ressurs. Å gi internettilgang må ikke stille utvide tilgangen til hvert nett som henger på gatewayen.