Nedstrømsklienter bak en oppstrøms-VPN: rute eller NAT?

Én gateway kjører WireGuard for dine egne enheter og en OpenVPN-klient mot noen andres nettverk. Videresending mellom de to indre grensesnittene virker, og det er lett å konkludere med at nedstrøms-subnettet nå er en del av oppstrømstjenesten. Det er det ikke. En rute klienten henter forteller gatewayen din hvor forespørsler skal sendes; den sier ingenting om hvordan det fjerne nettverket returnerer trafikk til enheter det aldri har hørt om. Velg en returmodell oppstrøms faktisk støtter før du legger til én eneste regel.

Bestem returmodellen før du rører rutingen

I denne gjennomgangen bruker nedstrømsklienter 10.90.0.0/24, oppstrømstunneladressen som er tildelt gatewayen er 10.80.0.6, og den godkjente fjerne ressursen er 172.20.0.30. To modeller passer til den formen: beholde nedstrømskilden og få den fjerne siden til å rute den, eller oversette kilden til gatewayens egen tunneladresse. Alt etter denne beslutningen er mekanisk, og beslutningen selv krever tjenestens eier. Den ene raden over er en ruteavtale med den fjerne siden; den andre er en lokal policyendring du kan gjøre alene. Å blande de to er det som gjør en endring på ti minutter til en forhandling.

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

Velg én rad og hold deg til den. Radene er alternativer, ikke trinn, og å blande dem gir et design ingen kan forklare i gjennomgangen.

Rutet kildebevaring

Den fjerne siden mottar en forespørsel fra en nedstrømsadresse, så den trenger en støttet rute og peer-eierskap for det subnettet, i tillegg til autorisasjon til å akseptere den. Det er fjerninnstillinger, og ingen lokal Linux-rute lager dem. Be om dem eksplisitt og skriftlig, med prefikset og den tunnel-peeren som skal bære det, og forvent at svaret avhenger av om tjenesten i det hele tatt støtter site-til-site-ordninger.

Er svaret ja, er den lokale konfigurasjonen liten: videresending aktivert, WireGuard-peerenes allowed-ips som dekker nedstrømsområdet, og en brannmurpolicy som tillater kryssingen i begge retninger.

Bevisst kildeoversettelse

Hvis tjenesten bare returnerer trafikk til den tilkoblede klientadressen, oversett kilden til den adressen på vei ut og behold conntrack-tilstanden som snur den for svar. Begrens regelen til de tiltenkte nedstrømskildene, de tiltenkte fjerne destinasjonene og oppstrømsgrensesnittet. En regel som oversetter alt som forlater hvert grensesnitt, er en mye større policy enn dette kravet, og den vil overraske deg senere.

IPv6 trenger sitt eget design; å kopiere en IPv4-masquerade-linje er ikke arkitektur. Test den oversatte veien med en ny tilkobling i stedet for en bufret.

Den lokale databanen må fortsatt virke

Oversettelse fjerner ikke det lokale arbeidet: gatewayen trenger fortsatt en rute til nedstrømsdestinasjoner, riktig WireGuard-peer-kildeeierskap, aktivert videresending og en smal brannmurpolicy mellom grensesnittene. En forespørsel som oppstår på gatewayen selv, prøver ingen av disse tillatelsene, og derfor består lokale tester på gatewayen mens nedstrømsenheter fortsatt feiler.

Test fra en faktisk nedstrømsenhet, ikke fra gatewayen. Kildeadressen er hele poenget med øvelsen.

Én kilde betyr én sesjonsidentitet

Fjerntjenesten ser gatewayens autentiserte sesjon og dens oversatte adresse, ikke uavhengig autentisering for hver nedstrømsenhet. Hold tillatelser per enhet og applikasjonsidentiteter eksplisitte, og bekreft med tjenestens eier at en gateway som handler for flere enheter i det hele tatt er tillatt. Oversettelse er ikke en måte å omgå et krav om påmelding per enhet; hvis tjenesten krever at hver enhet melder seg på, bruk den modellen eller forhandle frem en site-til-site-ordning.

Skriv den bekreftelsen i runbooken ved siden av regelen, for neste gjennomgang vil spørre om designet ble godkjent eller bare var bekvemt.

Definer den frakoblede tilstanden, og test deretter tre forespørsler

Bestem hva som skjer når oppstrømstunnelen faller. Autorisert fjern trafikk bør ikke stille følge en vanlig WAN-reservevei der det er forbudt, så brannmurpolicyen som tillater kryssingen bør også feile lukket. Test deretter tre tilfeller fra en ekte nedstrømsenhet: en tillatt forespørsel som virker, en forbudt forespørsel som feiler, og en oppstrømsfeil som stopper den tillatte.

Noter tilbakerullingen på én linje per regel, slik at endringen kan angres uten å gjenoppbygge intensjonen.