Hetzelfde subnet aan beide kanten: map het externe LAN naar een vrij bereik

Thuis en op kantoor draait allebei 192.168.1.0/24, dus een verzoek naar 192.168.1.1 heeft twee mogelijke antwoorden en de client kiest er één zonder te vragen. Een werkend kantoornetwerk hernummeren is zelden populair, en de routeradressen zitten vaak ingebakken in printers, camera's en documentatie. Adresmapping aan de clientzijde kan het externe netwerk in plaats daarvan onder een vrij bereik presenteren, en het hostdeel kan gelijk blijven zodat 192.168.1.20 als 10.203.41.20 verschijnt. De adder is dat alleen sommige clients het implementeren, en dat het niets doet voor het terugpad.

Twee weergaven van dezelfde host

De mapping behoudt het hostdeel en verandert alleen het netwerkdeel. Dezelfde machine antwoordt dan op twee adressen afhankelijk van waar je staat. Beide kolommen opschrijven voordat je iets configureert voorkomt later verkeerd lezen van logs en firewallregels.

Lokale apparaten thuis houden hun eigen 192.168.1.x-adressen, en dat is het punt van de oefening. De printer in de kamer ernaast blijft bereikbaar terwijl het kantoor onder een bereik verschijnt dat niet botst.

De argumentvolgorde is de hele truc

De optie neemt een richting, een netwerk en masker, en een alias: het eerste netwerk is wat de client ziet, de alias is wat de server ziet. Voor bronnen achter de externe gateway is de richting de bestemmingsvorm. De twee netwerken omdraaien omdat het laatste argument een alias heet, is de fout die een tunnel oplevert die verbindt en niets mapt.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

De route is wat de pakketten van de client voor het nieuwe bereik de tunnel in stuurt; de vertaling herschrijft de bestemming onderweg. Een antwoord van 192.168.1.20 wordt teruggeschreven naar 10.203.41.20 zodat de socket op de client consistent blijft. Een enkele host werkt hetzelfde met een masker van volledige lengte, zolang de route en de mapping hetzelfde adres beschrijven.

Dit is een adresmapping, geen portmapping. Twee diensten op één host zijn er niet mee te scheiden, en een protocol dat IP-adressen in zijn payload insluit, ziet nog steeds de echte.

De mapping maakt geen terugpad

De vertaling gebeurt bij de client, dus de server moet antwoorden nog steeds naar de tunnel routeren en zijn firewall moet ze nog steeds toestaan. Als de externe gateway niet weet hoe hij het tunnelsubnet bereikt, komt het verzoek aan en gaat het antwoord door de verkeerde deur naar buiten; de mapping laat de fout alleen op een clientprobleem lijken.

Regels aan de serverkant horen de adressen te beschrijven die na de vertaling op de server bestaan, niet het bereik dat de client ziet. De alias in een toestemmingsregel kopiëren kost een middag, want geen enkel pakket aan die kant draagt hem.

Kies een aliasbereik dat niet botst met iets anders dat de client routeert: een andere VPN, een containernetwerk, een tweede kantoor. Een botsing hier herintroduceert de oorspronkelijke dubbelzinnigheid onder een ander nummer en is moeilijker te zien omdat de adressen onbekend lijken.

Namen en payloads overleven de vertaling

Een hostnaam die naar de echte 192.168.1.20 resolveert, stuurt de browser naar het lokale apparaat in plaats van het externe, wat de routingtabel ook zegt. Het privé-DNS-antwoord moet naar het bereik wijzen dat de client ziet, terwijl het TLS-certificaat nog steeds de naam draagt die de toepassing verwacht. Test met de naam in plaats van met het adres, want het adres kan werken terwijl de naam stilletjes de verkeerde kant op resolveert. Wanneer de externe gateway die zone ook bedient, hebben zijn eigen records ook het bereik nodig dat de client ziet.

Redirects, ingesloten URL's en toepassingen die hun eigen adres in een payload geven, kunnen breken op manieren die geen pakketmapping kan repareren. Behandel ze als een toepassingsprobleem en begroot de inspanning daarnaar voordat je belooft dat hernummeren onnodig is.

Drie controles voordat je je vastlegt

Ten eerste, bevestig de clientimplementatie. Community OpenVPN ondersteunt deze optie; de OpenVPN 3-codebase noemt hem bij de niet-ondersteunde functies, dus een profiel dat naar een client in Connect-stijl wordt geduwd, kan hem gewoon negeren. Een richtlijn die wordt geaccepteerd en nooit wordt toegepast is erger dan een fout, omdat de tunnel gezond lijkt.

Ten tweede, verifieer de route en de vertaling apart met een kort diagnosevenster bij hoge verboseheid, en test daarna de echte dienst in plaats van een ping. Ten derde, bevestig dat de lokale router en de externe bron onderscheidbaar blijven vanaf de client, want dat was het oorspronkelijke doel.

Als de client de vertaling niet kan doen, vraag dan hulp aan de gatewaykant of accepteer een hernummering. Meer routes voor hetzelfde adres toevoegen is geen ontwerp.