Nedstrømsklienter bag en opstrøms-VPN: rute eller NAT?

Én gateway kører WireGuard til dine egne enheder og en OpenVPN-klient til en andens netværk. Videresendelse mellem de to indre interfaces virker, og det er let at konkludere, at nedstrømssubnettet nu er en del af opstrøms-tjenesten. Det er det ikke. En rute, som klienten trækker ned, fortæller din gateway, hvor den skal sende anmodninger; den siger intet om, hvordan det fjerne netværk sender trafik tilbage til enheder, det aldrig har hørt om. Vælg en returmodel, som opstrøms-tjenesten faktisk understøtter, før du tilføjer en enkelt regel.

Beslut returmodellen, før du rører ved routing

I denne gennemgang bruger nedstrømsklienter 10.90.0.0/24, gatewayens tildelte opstrøms-tunneladresse er 10.80.0.6, og den godkendte fjernressource er 172.20.0.30. To modeller passer til den form: bevar nedstrømskilden og få den fjerne side til at route den, eller oversæt kilden til gatewayens egen tunneladresse. Alt efter denne beslutning er mekanisk, og beslutningen selv kræver tjenestens ejer. Den ene række ovenfor er en routingaftale med den fjerne side; den anden er en lokal politikændring, du kan foretage alene. Forvekslingen af de to er det, der gør en ændring på ti minutter til en forhandling.

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

Vælg én række og hold fast ved den. Rækkerne er alternativer, ikke trin, og blandes de, giver det et design, ingen kan forklare ved gennemgang.

Routet bevarelse af kilden

Den fjerne side modtager en anmodning fra en nedstrømsadresse, så den har brug for en understøttet rute og peer-ejerskab for det subnet, plus tilladelse til at acceptere den. Det er fjernindstillinger, og ingen lokal Linux-rute skaber dem. Bed om dem udtrykkeligt og skriftligt, med præfikset og den tunnel-peer, der skal bære det, og forvent, at svaret afhænger af, om tjenesten overhovedet understøtter site-to-site-ordninger.

Er svaret ja, er den lokale konfiguration lille: videresendelse aktiveret, WireGuard-peerens allowed-ips, der dækker nedstrømsområdet, og en firewallpolitik, der tillader krydsningen i begge retninger.

Bevidst kildeoversættelse

Hvis tjenesten kun sender trafik tilbage til den tilsluttede klientadresse, skal du oversætte kilden til den adresse på vej ud og beholde den conntrack-tilstand, der vender den for svar. Afgræns reglen til de tilsigtede nedstrømskilder, de tilsigtede fjernmål og det opstrøms interface. En regel, der oversætter alt, hvad der forlader hvert interface, er en meget større politik end dette krav, og den vil overraske dig senere.

IPv6 kræver sit eget design; at kopiere en IPv4-masquerade-linje er ikke arkitektur. Test den oversatte vej med en ny forbindelse frem for en cachet.

Den lokale datasti skal stadig virke

Oversættelse fjerner ikke det lokale arbejde: gatewayen har stadig brug for en rute til nedstrømsmål, det korrekte WireGuard-peer-kildeejerskab, aktiveret videresendelse og en snæver firewallpolitik mellem interfaces. En anmodning, der opstår på gatewayen selv, udøver ingen af de tilladelser, og derfor består lokale tests på gatewayen, mens nedstrømsenheder stadig fejler.

Test fra en faktisk nedstrømsenhed, ikke fra gatewayen. Kildeadressen er hele pointen med øvelsen.

Én kilde betyder én sessionidentitet

Fjerntjenesten ser gatewayens autentificerede session og dens oversatte adresse, ikke uafhængig autentificering for hver nedstrømsenhed. Hold tilladelser pr. enhed og applikationsidentiteter eksplicitte, og bekræft med tjenestens ejer, at en gateway, der handler for flere enheder, overhovedet er tilladt. Oversættelse er ikke en måde at omgå et krav om tilmelding pr. enhed; hvis tjenesten kræver, at hver enhed tilmelder sig, brug den model eller forhandl en site-to-site-ordning.

Skriv den bekræftelse i runbooken ved siden af reglen, for den næste gennemgang vil spørge, om designet blev godkendt eller blot var bekvemt.

Definér den afbrudte tilstand, og test derefter tre anmodninger

Beslut, hvad der sker, når opstrøms-tunnelen falder. Autoriseret fjerntrafik bør ikke stille følge et almindeligt WAN-fallback, hvor det er forbudt, så firewallpolitikken, der tillader krydsningen, bør også fejle lukket. Test derefter tre tilfælde fra en rigtig nedstrømsenhed: en tilladt anmodning, der virker, en afvist anmodning, der fejler, og en opstrømsfejl, der stopper den tilladte.

Notér tilbagerulningen i én linje pr. regel, så ændringen kan fortrydes uden at rekonstruere hensigten.