VPN-gateway treng IP-vidaresending: kva du bør sjekke

Klienten din kan pinge adressa til gatewayen medan alle ressursar bak han blir utilgjengelege. Det paret av observasjonar skildrar ein vert som snakkar med deg og ein ruter som ikkje rutar, som er ulike rollar på same maskin. Vidaresending er brytaren mellom dei.

Dei to rollane er uavhengige, og det er dei to adressefamiliane òg.

Å svare på si eiga adresse beviser ingenting

Når ein pakke er adressert til gatewayen sjølv, brukar den lokale stakken han opp, og inga vidaresendingsavgjerd blir teken. Difor fortel ein vellukka ping til tunneladressa eller eit administrasjonsgrensesnitt deg at daemonen lever og tunnelen er oppe, medan det ikkje seier noko om trafikk som er meint for eit nettverk bak boksen. Kjernen konsulterer berre vidaresendingsvegen sin for pakkar som ikkje er adresserte til han.

Les kravet som ein rolle, ikkje ei innstilling: denne verten må flytte pakkar mellom to grensesnitt. Ein berbar PC som berre treng å nå eit eksternt nettverk tek aldri den rolla, og eit nettstad-til-nettstad-endepunkt gjer det alltid. Å lese kravet slik forklarar kvifor ein fungerande klientkonfigurasjon feilar når han blir flytta til ein gateway.

Den same setninga gjeld brannmuren framfor vidaresendingsavgjerda, som har sin eigen politikk for kva som kan vidaresendast.

Sjekk kvar adressefamilie separat

IPv4-vidaresending er ein brytar, og IPv6-vidaresending er ein annan med si eiga åtferd per grensesnitt. Å slå på den fyrste seier ingenting om den andre, og ein dual-stack-klient kan nå halve eit nettverk medan resten blir mørkt. To klientar frå ulike familiar kan difor vere usamde om den same gatewayen. Spør kva familie den feilande klienten brukte før du redigerer nokon av innstillingane. Stadfest 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 distribusjonar er verdien du les ved køyring lagt der av ein teneste eller ei konfigurasjonsfil, så ei endring gjord med ein eingongskommando kan forsvinne ved omstart. Finn fila som eig innstillinga før du redigerer køyringsverdien.

Vidaresending er eitt av fire krav

Ein fungerande vidaresend flyt treng fire ting samstundes: klienten må vite at destinasjonen er bak tunnelen, gatewayen må ha ei rute vidare, svar må ha ein veg tilbake, og brannmuren må tillate trafikken. Kjeldeomsetjing høyrer til det designet som eit alternativ og ikkje ein regel, fordi eit privat ruta nettverk med symmetriske vegan ikkje treng det, og eit asymmetrisk vanlegvis gjer det. Kvar av dei fire feilar uavhengig, og difor flyttar reparasjon av éin sjeldan symptomet. Skriv ned alle fire før du endrar nokon av dei.

Skyplattformer legg til eit femte omsyn. Nokre handhevar kjelde- og destinasjonskontrollar på instansar, noko som slepp vidaresende pakkar uansett korleis kjernen til gjesten er konfigurert. Plattforma si eiga nettverksdokumentasjon er autoriteten der, ikkje sysctl-utdata inne i VM-en.

Test frå klienten, ikkje frå gatewayen

Ein test som blir køyrd i gatewayen sitt eige skal, går ikkje gjennom nokon del av vidaresendingsvegen du nettopp aktiverte. Generer trafikken frå klienten som har problemet, og stadfest at han når noko bak gatewayen snarare enn gatewayen sjølv. Det er den einaste testen som øver på rolla du endra.

Hald lyttarreglar og vidaresendingsreglar åtskilde i hovudet og i endringsloggen. Å opne VPN-porten slepp klientar inn til tenesta; det gir dei ingenting på nettverket bak henne, og dei to ser identiske ut i ei brannmurliste som har vakse i årevis.

Viss pakkar kjem og tenesta deretter avviser brukaren, har du flytta deg forbi nettverk. Fortset med applikasjonsautorisasjon i staden for å utvide vidaresendingspolitikken igjen.