Samme undernet i begge ender: map det eksterne LAN til et frit område

Hjemmet og kontoret kører begge 192.168.1.0/24, så en anmodning til 192.168.1.1 har to mulige svar, og klienten vælger ét uden at spørge. Det er sjældent populært at omnummerere et velfungerende kontornetværk, og routeradresserne er ofte indbagt i printere, kameraer og dokumentation. Adressemapping på klientsiden kan i stedet præsentere det eksterne netværk under et frit område, og værtsdelen kan forblive identisk, så 192.168.1.20 fremstår som 10.203.41.20. Haken er, at kun nogle klienter implementerer det, og at det intet gør for returvejen.

To visninger af samme vært

Mapperingen beholder værtsdelen og ændrer kun netværksdelen. Den samme maskine svarer derefter på to adresser afhængigt af, hvor du står. At skrive begge kolonner ned, før du konfigurerer noget, forhindrer senere fejllæsning af logfiler og firewallregler.

Lokale enheder derhjemme beholder deres egne 192.168.1.x-adresser, og det er hele pointen. Printeren i naboværelset forbliver tilgængelig, mens kontoret optræder under et område, der ikke kolliderer.

Argumentrækkefølgen er hele tricket

Indstillingen tager en retning, et netværk og en maske samt et alias: det første netværk er det, klienten ser, aliaset er det, serveren ser. For ressourcer, der ligger bag den eksterne gateway, er retningen destinationsformen. At bytte om på de to netværk, fordi det sidste argument kaldes et alias, er fejlen, der giver en tunnel, som forbinder og ikke mapper noget.

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"

Ruten er det, der sender klientens pakker for det nye område ind i tunnelen; oversættelsen skriver destinationen om undervejs. Et svar fra 192.168.1.20 skrives tilbage til 10.203.41.20, så socket på klienten forbliver konsistent. En enkelt vært fungerer på samme måde med en maske i fuld længde, så længe ruten og mapperingen beskriver samme adresse.

Dette er en adressemapping, ikke en portmapping. To tjenester på én vært kan ikke adskilles med den, og en protokol, der indlejrer IP-adresser i sin payload, vil stadig se de rigtige.

Mapperingen skaber ikke en returvej

Oversættelsen sker på klienten, så serveren skal stadig rute svar til tunnelen, og dens firewall skal stadig tillade dem. Hvis den eksterne gateway ikke ved, hvordan den når tunnelundernettet, ankommer anmodningen, og svaret forlader gennem den forkerte dør; mapperingen får blot fejlen til at ligne et klientproblem.

Regler på serversiden bør beskrive de adresser, der findes på serveren efter oversættelsen, ikke det klientvisible område. At kopiere aliaset ind i en tilladelsesregel spilder en eftermiddag, fordi ingen pakke på den side bærer det.

Vælg et aliasområde, der ikke kolliderer med noget andet, klienten router: en anden VPN, et containernetværk, et andet kontor. En kollision her genindfører den oprindelige tvetydighed under et andet nummer og er sværere at se, fordi adresserne ser ukendte ud.

Navne og payloads overlever oversættelsen

Et værtsnavn, der opløses til den rigtige 192.168.1.20, sender browseren til den lokale enhed i stedet for den eksterne, uanset hvad routingtabellen siger. Det private DNS-svar skal pege på det klientvisible område, mens TLS-certifikatet stadig bærer det navn, applikationen forventer. Test med navnet i stedet for med adressen, fordi adressen kan virke, mens navnet stille opløses den forkerte vej. Når den eksterne gateway også betjener den zone, har dens egne poster også brug for det klientvisible område.

Omdirigeringer, indlejrede URL'er og applikationer, der udleverer deres egen adresse i en payload, kan gå i stykker på måder, som ingen pakkemapping kan reparere. Behandl dem som et applikationsproblem, og tilpas indsatsen derefter, før du lover, at omnummerering er unødvendig.

Tre kontroller, før du forpligter dig

For det første, bekræft klientimplementeringen. Community OpenVPN understøtter denne indstilling; OpenVPN 3-kodebasen opfører den blandt ikke-understøttede funktioner, så en profil, der sendes til en Connect-lignende klient, ignorerer den måske bare. En direktiv, der accepteres og aldrig anvendes, er værre end en fejl, fordi tunnelen ser sund ud.

For det andet, verificér ruten og oversættelsen hver for sig med et kort diagnostikvindue ved høj detaljering, og test derefter den faktiske tjeneste i stedet for en ping. For det tredje, bekræft, at den lokale router og den eksterne ressource forbliver til at skelne fra klienten, da det var det oprindelige mål.

Hvis klienten ikke kan udføre oversættelsen, så bed gateway-siden om hjælp eller accepter en omnummerering. At tilføje flere ruter til den samme adresse er ikke et design.