Tunnelen oppe, ingen internett: der vidaresendinga stoppar

Klienten koplar til, tunnelen ber ping til gatewayen, og ingenting bak han svarar. Den tilstanden er normal for ein gateway som berre nokon gong var meint å gje tilgang til verna nett, og han er ein feil for ein som vert annonsert som fulltunnel-utgang. Stadfest kva teneste som vart lova før du endrar reglar. Følg deretter éi einsleg offentleg førespurnad gjennom dei fire stadene ho kan stoppa. Éi førespurnad og éi pakkefangst avgjer meir enn ei side med gjettingar.

Stadfest om internettutgang nokon gong var designet

Ein split-tunnel-profil ruter berre dei verna subnetta inn i VPN-et, så offentleg surfing held fram over den lokale lenkja og rører aldri gatewayen. Ein fulltunnel-profil installerer ei standardrute i tunnelen, noko som gjer gatewayen ansvarleg for heile vegen. Begge er legitime design, og å blanda dei gjev ein feilrapport der det ikkje finst nokon. Les dei annonserte rutene til klienten før du testar noko anna, for rutetabellen svarar på spørsmålet saka vanlegvis får feil.

Det klienten installerer, er ikkje alltid det profilen har tenkt. Ei pusha rute kan overstyrast av ei lokal rute med lågare metrikk, og ein klient som held på LAN-ruta medan han legg til ei standardrute, oppfører seg som ein split-tunnel for det subnettet.

Følg éi einsleg offentleg førespurnad

Vel éin einsleg destinasjon og følg han frå klienten og utover. Kontroller på klienten at pakken faktisk vel tunnelen, og kva lokal adresse han brukar som kjelde. Kontroller deretter gatewayen: kjem pakken fram, og forlèt han det offentlege grensesnittet. Kvart av desse svara fjernar ein heil 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

Viss gatewayen aldri ser pakken, er klientruta eller tunnelvalet feil. Viss han kjem fram og ikkje dreg vidare, ligg problemet på gatewayen, og dei tre gjenverande kontrollane gjeld.

Kontroller vidaresending, rute og omsetjing

Den vidaresendingsrettleiinga som følgjer med strongSwan, gjeld for ein gateway av kva tunneltype som helst: kjernen må få løyve til å flytta pakkar mellom grensesnitt, og ei brukbar rute må peika mot internett. Brannmurpolitikken må deretter tillata trafikken, og kjeldeadressa må vera ei den offentlege sida kan svara på. Ei privat klientadresse som vert vidaresend uendra til internett, får aldri noko 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

Kjeldeomsetjing er den vanlege manglande brikka. Med henne skriv gatewayen om klientkjelda til si offentlege adresse og følgjer straumen; utan henne har svaret ingen stad å gå. Skyplattformer legg til ei andre grense, der rutetabellen eller sikkerheitsgruppa til instansen kan sleppa trafikk som gjestebrannmuren tillèt. Den grensa er lett å oversjå fordi gjestesystemet ser rett konfigurert ut frå innsida.

Reverse-path-filtrering i ein asymmetrisk oppsett kan også forkasta gyldige pakkar. Les teljaren på den regelen i staden for å gå ut frå at han er i orden, for ei streng innstilling på det offentlege grensesnittet avviser trafikk som kjem via ein annan veg enn rutetabellen føreser.

Svarveg og resolver er to ulike svar

Følg også med på svaret, ikkje berre førespurnaden. Viss førespurnaden går ut omsett og svaret kjem tilbake til den omsette straumen, verkar vidaresendinga sjølv når applikasjonen framleis feilar, og neste gransking høyrer til applikasjonen eller til DNS.

Eit nettstad som returnerer ein HTTP-feil, er prov på at internettvidaresendinga verkar. Eit namn som ikkje let seg slå opp medan adressetilgang verkar, er eit resolverproblem, ikkje eit NAT-problem.

Test klienten på nytt etter ei smal retting, saman med kvar medvite avgrensa private ressurs. Å gje internettilgang må ikkje stille utvida tilgangen til kvart nett som heng på gatewayen.