VPN-gateway kræver IP-videresendelse: hvad du skal kontrollere

Din klient kan pinge gatewayens adresse, mens alle ressourcer bag den forbliver utilgængelige. Det par af observationer beskriver en vært, der taler med dig, og en router, der ikke router, hvilket er to forskellige roller på samme maskine. Videresendelse er kontakten mellem dem.

De to roller er uafhængige, og det er de to adressefamilier også.

At svare på sin egen adresse beviser intet

Når en pakke er adresseret til gatewayen selv, forbruger den lokale stak den, og der træffes ingen beslutning om videresendelse. Derfor fortæller et vellykket ping til tunneladressen eller en administrationsgrænseflade dig, at dæmonen lever, og at tunnelen er oppe, mens det ikke siger noget om trafik beregnet til et netværk bag boksen. Kernen konsulterer kun sin videresendelsesvej for pakker, der ikke er adresseret til den.

Læs kravet som en rolle, ikke en indstilling: denne vært skal flytte pakker mellem to grænseflader. En bærbar computer, der kun skal nå et fjernnetværk, påtager sig aldrig den rolle, og et site-til-site-endepunkt gør det altid. At læse kravet sådan forklarer, hvorfor en fungerende klientkonfiguration fejler, når den flyttes til en gateway.

Den samme sætning gælder for firewallen foran videresendelsesbeslutningen, som har sin egen politik for, hvad der må videresendes.

Kontrollér hver adressefamilie separat

IPv4-videresendelse er én kontakt, og IPv6-videresendelse er en anden med sin egen adfærd for hver grænseflade. Aktivering af den første siger intet om den anden, og en dual-stack-klient kan nå halvdelen af et netværk, mens resten forbliver mørk. To klienter fra forskellige familier kan derfor være uenige om den samme gateway. Spørg, hvilken familie den fejlende klient brugte, før du redigerer nogen af indstillingerne. Bekræft begge, før du konkluderer, at routingdesignet er forkert.

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

På mange distributioner er den værdi, du læser under kørsel, lagt der af en tjeneste eller en konfigurationsfil, så en ændring foretaget med en engangskommando kan forsvinde ved genstart. Find den fil, der ejer indstillingen, før du redigerer kørselsværdien.

Videresendelse er et af fire krav

Et fungerende videresendt flow kræver fire ting på én gang: klienten skal vide, at destinationen er bag tunnelen, gatewayen skal have en rute videre, svar skal have en vej tilbage, og firewallen skal tillade trafikken. Kildeoversættelse hører til det design som en mulighed snarere end en regel, fordi et privat routet netværk med symmetriske veje ikke har brug for det, og et asymmetrisk normalt har. Hver af de fire fejler uafhængigt, og derfor flytter reparation af én sjældent symptomet. Skriv alle fire ned, før du ændrer nogen af dem.

Cloudplatforme tilføjer en femte overvejelse. Nogle håndhæver kilde- og destinationskontroller på instanser, hvilket dropper videresendte pakker uanset, hvad gæstens kerne er konfigureret til at gøre. Platformens egen netværksdokumentation er autoriteten der, ikke sysctl-outputtet inde i VM'en.

Test fra klienten, ikke fra gatewayen

En test kørt i gatewayens eget shell gennemløber ingen del af den videresendelsesvej, du netop har aktiveret. Generér trafikken fra den klient, der har problemet, og bekræft, at den når noget bag gatewayen snarere end gatewayen selv. Det er den eneste test, der udøver den rolle, du ændrede.

Hold lytteregler og videresendelsesregler adskilt i hovedet og i ændringsloggen. Åbning af VPN-porten lukker klienter ind til tjenesten; den giver dem intet på netværket bag den, og de to ser identiske ud i en firewall-liste, der er vokset i årevis.

Hvis pakker ankommer, og tjenesten derefter afviser brugeren, er du kommet forbi netværket. Fortsæt med applikationsgodkendelse i stedet for at udvide videresendelsespolitikken igen.