Nedströmsklienter bakom en uppströms-VPN: rutt eller NAT?

En gateway kör WireGuard för dina egna enheter och en OpenVPN-klient mot någon annans nätverk. Vidarebefordran mellan de två inre gränssnitten fungerar, och det är lätt att dra slutsatsen att nedströms-subnätet nu är en del av uppströmstjänsten. Det är det inte. En rutt som klienten hämtar talar om för din gateway vart förfrågningar ska skickas; den säger ingenting om hur det avlägsna nätverket returnerar trafik till enheter det aldrig har hört talas om. Välj en returmodell som uppströmmen faktiskt stöder innan du lägger till en enda regel.

Bestäm returmodellen innan du rör routningen

I den här genomgången använder nedströmsklienter 10.90.0.0/24, den till gatewayen tilldelade uppströmstunneladressen är 10.80.0.6, och den godkända fjärrresursen är 172.20.0.30. Två modeller passar den formen: behåll nedströmskällan och få den avlägsna sidan att routa den, eller översätt källan till gatewayens egen tunneladress. Allt efter detta beslut är mekaniskt, och beslutet självt kräver tjänstens ägare. Den ena raden ovan är en routingöverenskommelse med den avlägsna sidan; den andra är en lokal policyändring du kan göra själv. Att blanda ihop de två är det som gör en ändring på tio minuter till en förhandling.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Välj en rad och håll dig till den. Raderna är alternativ, inte steg, och att blanda dem ger en design ingen kan förklara vid granskningen.

Routad källbevarande

Den avlägsna sidan tar emot en förfrågan från en nedströmsadress, så den behöver en stödd rutt och peer-ägarskap för det subnätet, plus behörighet att acceptera den. Det är fjärrinställningar, och ingen lokal Linux-rutt skapar dem. Begär dem uttryckligen och skriftligen, med prefixet och den tunnel-peer som ska bära den, och räkna med att svaret beror på om tjänsten alls stöder site-till-site-upplägg.

Om svaret är ja är den lokala konfigurationen liten: vidarebefordran aktiverad, WireGuard-peerns allowed-ips som täcker nedströmsintervallet, och en brandväggspolicy som tillåter övergången i båda riktningarna.

Medveten källöversättning

Om tjänsten bara returnerar trafik till den anslutna klientadressen, översätt källan till den adressen på vägen ut och behåll conntrack-tillståndet som vänder den för svar. Begränsa regeln till de avsedda nedströmskällorna, de avsedda fjärrmålen och uppströmsgränssnittet. En regel som översätter allt som lämnar varje gränssnitt är en mycket större policy än detta krav, och den kommer att överraska dig senare.

IPv6 behöver en egen design; att kopiera en IPv4 masquerade-rad är inte arkitektur. Testa den översatta vägen med en ny anslutning i stället för en cachad.

Den lokala datavägen måste fortfarande fungera

Översättning tar inte bort det lokala arbetet: gatewayen behöver fortfarande en rutt till nedströmsmålen, rätt WireGuard-peer-källägarskap, aktiverad vidarebefordran och en smal brandväggspolicy mellan gränssnitten. En förfrågan som skapas på gatewayen själv utövar inget av dessa tillstånd, och därför går lokala tester på gatewayen igenom medan nedströmsenheter fortfarande misslyckas.

Testa från en faktisk nedströmsenhet, inte från gatewayen. Källadressen är hela poängen med övningen.

En källa betyder en sessionsidentitet

Fjärrtjänsten ser gatewayens autentiserade session och dess översatta adress, inte en oberoende autentisering för varje nedströmsenhet. Håll behörigheter per enhet och applikationsidentiteter explicita, och bekräfta med tjänstens ägare att en gateway som agerar för flera enheter alls är tillåten. Översättning är inte ett sätt att kringgå ett krav på registrering per enhet; om tjänsten kräver att varje enhet registrerar sig, använd den modellen eller förhandla fram ett site-till-site-upplägg.

Skriv den bekräftelsen i runbooken bredvid regeln, för nästa granskare kommer att fråga om designen godkändes eller bara var bekväm.

Definiera det frånkopplade tillståndet och testa sedan tre förfrågningar

Bestäm vad som händer när uppströmstunneln faller. Auktoriserad fjärrtrafik bör inte tyst följa en vanlig WAN-reservväg där det är förbjudet, så brandväggspolicyn som tillåter övergången bör också misslyckas stängd. Testa sedan tre fall från en verklig nedströmsenhet: en tillåten förfrågan som fungerar, en otillåten förfrågan som misslyckas, och ett uppströmsfel som stoppar den tillåtna.

Anteckna återställningen på en rad per regel, så att ändringen kan ångras utan att avsikten byggs upp igen.