VPN-gateway trenger IP-videresending: hva du bør sjekke

Klienten din kan pinge gatewayens adresse mens alle ressurser bak den forblir utilgjengelige. Det paret av observasjoner beskriver en vert som snakker med deg og en ruter som ikke ruter, som er forskjellige roller på samme maskin. Videresending er bryteren mellom dem.

De to rollene er uavhengige, og det er de to adressefamiliene også.

Å svare på sin egen adresse beviser ingenting

Når en pakke er adressert til gatewayen selv, forbruker den lokale stakken den, og ingen videresendingsbeslutning tas. Derfor forteller en vellykket ping til tunneladressen eller et administrasjonsgrensesnitt deg at daemonen lever og tunnelen er oppe, mens det ikke sier noe om trafikk som er ment for et nettverk bak boksen. Kjernen konsulterer bare videresendingsveien sin for pakker som ikke er adressert til den.

Les kravet som en rolle, ikke en innstilling: denne verten må flytte pakker mellom to grensesnitt. En bærbar PC som bare trenger å nå et eksternt nettverk tar aldri den rollen, og et nettsted-til-nettsted-endepunkt gjør det alltid. Å lese kravet slik forklarer hvorfor en fungerende klientkonfigurasjon feiler når den flyttes til en gateway.

Den samme setningen gjelder brannmuren foran videresendingsbeslutningen, som har sin egen policy for hva som kan videresendes.

Sjekk hver adressefamilie separat

IPv4-videresending er én bryter, og IPv6-videresending er en annen med sin egen oppførsel per grensesnitt. Å slå på den første sier ingenting om den andre, og en dual-stack-klient kan nå halve et nettverk mens resten forblir mørkt. To klienter fra forskjellige familier kan derfor være uenige om den samme gatewayen. Spør hvilken familie den feilende klienten brukte før du redigerer noen av innstillingene. Bekreft begge før du konkluderer med at rutedesignet er feil.

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

På mange distribusjoner er verdien du leser ved kjøring lagt der av en tjeneste eller en konfigurasjonsfil, så en endring gjort med en engangskommando kan forsvinne ved omstart. Finn filen som eier innstillingen før du redigerer kjøringsverdien.

Videresending er ett av fire krav

En fungerende videresendt flyt trenger fire ting samtidig: klienten må vite at destinasjonen er bak tunnelen, gatewayen må ha en rute videre, svar må ha en vei tilbake, og brannmuren må tillate trafikken. Kildeoversettelse hører til det designet som et alternativ og ikke en regel, fordi et privat rutet nettverk med symmetriske veier ikke trenger det, og et asymmetrisk vanligvis gjør det. Hver av de fire feiler uavhengig, og derfor flytter reparasjon av én sjelden symptomet. Skriv ned alle fire før du endrer noen av dem.

Skyplattformer legger til en femte betraktning. Noen håndhever kilde- og destinasjonskontroller på instanser, noe som slipper videresendte pakker uansett hvordan gjestens kjerne er konfigurert. Plattformens egen nettverksdokumentasjon er autoriteten der, ikke sysctl-utdataene inne i VM-en.

Test fra klienten, ikke fra gatewayen

En test som kjøres i gatewayens eget skall, går ikke gjennom noen del av videresendingsveien du nettopp aktiverte. Generer trafikken fra klienten som har problemet, og bekreft at den når noe bak gatewayen snarere enn gatewayen selv. Det er den eneste testen som øver på rollen du endret.

Hold lytteregler og videresendingsregler atskilt i hodet og i endringsloggen. Å åpne VPN-porten slipper klienter inn til tjenesten; det gir dem ingenting på nettverket bak den, og de to ser identiske ut i en brannmurliste som har vokst i årevis.

Hvis pakker ankommer og tjenesten deretter avviser brukeren, har du beveget deg forbi nettverk. Fortsett med applikasjonsautorisasjon i stedet for å utvide videresendingspolicyen igjen.