Downstream-clients achter een upstream-VPN: route of NAT?

Eén gateway draait WireGuard voor je eigen apparaten en een OpenVPN-client naar iemands anders netwerk. Doorsturen tussen de twee interne interfaces werkt, en het is makkelijk om te concluderen dat het downstream-subnet nu deel uitmaakt van de upstream-dienst. Dat is het niet. Een route die de client ophaalt, vertelt je gateway waar verzoeken heen moeten; hij zegt niets over hoe het externe netwerk verkeer terugstuurt naar apparaten waar het nooit van heeft gehoord. Kies een retourmodel dat de upstream echt ondersteunt voordat je één regel toevoegt.

Bepaal het retourmodel voordat je aan routing komt

In deze uitleg gebruiken downstream-clients 10.90.0.0/24, is het aan de gateway toegewezen upstream-tunneladres 10.80.0.6, en is de goedgekeurde externe bron 172.20.0.30. Twee modellen passen bij die vorm: de downstream-bron behouden en de verre kant zover krijgen dat hij die routeert, of de bron vertalen naar het eigen tunneladres van de gateway. Alles na deze beslissing is mechanisch, en de beslissing zelf vraagt de eigenaar van de dienst. De ene regel hierboven is een routingafspraak met de verre kant; de andere is een lokale beleidswijziging die je alleen kunt doen. Die twee verwarren is wat een wijziging van tien minuten in een onderhandeling verandert.

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

Kies één regel en houd daaraan vast. De regels zijn alternatieven, geen stappen, en ze mengen levert een ontwerp op dat niemand bij de review kan uitleggen.

Gerouteerd bronbehoud

De verre kant ontvangt een verzoek van een downstream-adres, dus heeft hij een ondersteunde route en peer-eigendom voor dat subnet nodig, plus toestemming om het te accepteren. Dat zijn externe instellingen, en geen enkele lokale Linux-route maakt ze. Vraag ze expliciet en schriftelijk aan, met de prefix en de tunnelpeer die hem zal dragen, en verwacht dat het antwoord ervan afhangt of de dienst site-naar-site-afspraken eigenlijk ondersteunt.

Is het antwoord ja, dan is de lokale configuratie klein: doorsturen aan, de allowed-ips van de WireGuard-peer die het downstream-bereik dekken, en een firewallbeleid dat de oversteek in beide richtingen toestaat.

Bewuste bronvertaling

Als de dienst verkeer alleen naar het verbonden clientadres terugstuurt, vertaal de bron dan op de uitweg naar dat adres en houd de conntrack-status bij die hem voor antwoorden omkeert. Beperk de regel tot de bedoelde downstream-bronnen, de bedoelde externe bestemmingen en de upstream-interface. Een regel die alles vertaalt wat elke interface verlaat, is een veel groter beleid dan deze eis, en hij zal je later verrassen.

IPv6 vraagt zijn eigen ontwerp; een IPv4-masquerade-regel kopiëren is geen architectuur. Test het vertaalde pad met een nieuwe verbinding in plaats van een gecachte.

Het lokale datapad moet nog steeds werken

Vertaling haalt het lokale werk niet weg: de gateway heeft nog steeds een route naar downstream-bestemmingen nodig, het juiste WireGuard-peer-broneigendom, ingeschakeld doorsturen en een smal firewallbeleid tussen interfaces. Een verzoek dat op de gateway zelf ontstaat, oefent geen van die rechten uit, en daarom slagen lokale tests op de gateway terwijl downstream-apparaten nog steeds falen.

Test vanaf een echt downstream-apparaat, niet vanaf de gateway. Het bronadres is het hele punt van de oefening.

Eén bron betekent één sessie-identiteit

De externe dienst ziet de geauthenticeerde sessie van de gateway en zijn vertaalde adres, niet een onafhankelijke authenticatie per downstream-apparaat. Houd rechten per apparaat en applicatie-identiteiten expliciet, en bevestig bij de eigenaar van de dienst dat een gateway die voor meerdere apparaten optreedt eigenlijk is toegestaan. Vertaling is geen manier om een inschrijvingsplicht per apparaat te omzeilen; als de dienst eist dat elk apparaat zich inschrijft, gebruik dat model of onderhandel een site-naar-site-afspraak.

Schrijf die bevestiging in de runbook naast de regel, want de volgende beoordelaar zal vragen of het ontwerp is goedgekeurd of alleen handig was.

Definieer de verbroken toestand en test dan drie verzoeken

Bepaal wat er gebeurt als de upstream-tunnel wegvalt. Geautoriseerd extern verkeer moet niet stil een gewone WAN-terugval volgen waar dat verboden is, dus het firewallbeleid dat de oversteek toestaat moet ook gesloten falen. Test daarna drie gevallen vanaf een echt downstream-apparaat: een toegestaan verzoek dat werkt, een niet-toegestaan verzoek dat faalt, en een upstream-storing die het toegestane stopt.

Leg de terugdraaiing vast in één regel per regel, zodat de wijziging ongedaan kan worden gemaakt zonder de bedoeling te reconstrueren.