Samme subnett i begge ender: koble det eksterne LAN-et til et ledig område

Hjemmet og kontoret kjører begge 192.168.1.0/24, så en forespørsel til 192.168.1.1 har to mulige svar, og klienten velger ett uten å spørre. Det er sjelden populært å omnummerere et fungerende kontornettverk, og ruteradressene er ofte bakt inn i skrivere, kameraer og dokumentasjon. Adressemapping på klientsiden kan i stedet presentere det eksterne nettverket under et ledig område, og vertsdelen kan forbli lik, slik at 192.168.1.20 fremstår som 10.203.41.20. Haken er at bare noen klienter implementerer det, og at det ikke gjør noe for returveien.

To visninger av samme vert

Mappingen beholder vertsdelen og endrer bare nettverksdelen. Den samme maskinen svarer da på to adresser avhengig av hvor du står. Å skrive ned begge kolonnene før du konfigurerer noe, hindrer senere feillesing av logger og brannmurregler.

Lokale enheter hjemme beholder sine egne 192.168.1.x-adresser, og det er poenget med øvelsen. Skriveren i naborommet er fortsatt tilgjengelig mens kontoret vises under et område som ikke kolliderer.

Argumentrekkefølgen er hele trikset

Alternativet tar en retning, et nettverk og en maske, og et alias: det første nettverket er det klienten ser, aliaset er det serveren ser. For ressurser som ligger bak den eksterne gatewayen, er retningen destinasjonsformen. Å bytte om de to nettverkene fordi det siste argumentet kalles et alias, er feilen som gir en tunnel som kobler til og ikke mapper noe.

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 som sender klientens pakker for det nye området inn i tunnelen; oversettelsen skriver om destinasjonen underveis. Et svar fra 192.168.1.20 skrives tilbake til 10.203.41.20, slik at socketen på klienten forblir konsistent. En enkelt vert fungerer på samme måte med en maske i full lengde, så lenge ruten og mappingen beskriver samme adresse.

Dette er en adressemapping, ikke en portmapping. To tjenester på én vert kan ikke skilles med den, og en protokoll som legger IP-adresser i nyttelasten vil fortsatt se de virkelige.

Mappingen skaper ikke en returvei

Oversettelsen skjer på klienten, så serveren må fortsatt rute svar til tunnelen, og brannmuren må fortsatt tillate dem. Hvis den eksterne gatewayen ikke vet hvordan den når tunnelens subnett, kommer forespørselen inn, og svaret går ut gjennom feil dør; mappingen får bare feilen til å se ut som et klientproblem.

Regler på serversiden bør beskrive adressene som finnes på serveren etter oversettelsen, ikke området klienten ser. Å kopiere aliaset inn i en tillatelsesregel sløser bort en ettermiddag, fordi ingen pakke på den siden bærer det.

Velg et aliasområde som ikke kolliderer med noe annet klienten ruter: en annen VPN, et containernettverk, et andre kontor. En kollisjon her gjeninnfører den opprinnelige tvetydigheten under et annet nummer og er vanskeligere å se fordi adressene virker ukjente.

Navn og nyttelaster overlever oversettelsen

Et vertsnavn som løses til den ekte 192.168.1.20 sender nettleseren til den lokale enheten i stedet for den eksterne, uansett hva rutetabellen sier. Det private DNS-svaret må peke på området klienten ser, mens TLS-sertifikatet fortsatt bærer navnet applikasjonen forventer. Test med navnet i stedet for adressen, fordi adressen kan virke mens navnet stille løses den gale veien. Når den eksterne gatewayen også betjener den sonen, trenger dens egne oppføringer også området klienten ser.

Omdirigeringer, innebygde URL-er og applikasjoner som gir ut sin egen adresse i en nyttelast kan bryte på måter ingen pakkemapping kan reparere. Behandle dem som et applikasjonsproblem og dimensjoner innsatsen deretter før du lover at omnummerering er unødvendig.

Tre kontroller før du forplikter deg

For det første, bekreft klientimplementeringen. Community OpenVPN støtter dette alternativet; OpenVPN 3-kodebasen fører det opp blant funksjonene som ikke støttes, så en profil som skyves til en klient i Connect-stil, kan rett og slett ignorere det. Et direktiv som godtas og aldri brukes, er verre enn en feil, fordi tunnelen ser sunn ut.

For det andre, verifiser ruten og oversettelsen hver for seg med et kort diagnostikkvindu ved høy detaljering, og test deretter den faktiske tjenesten i stedet for en ping. For det tredje, bekreft at den lokale ruteren og den eksterne ressursen forblir skillbare fra klienten, siden det var det opprinnelige målet.

Hvis klienten ikke kan gjøre oversettelsen, be gateway-siden om hjelp eller godta en omnummerering. Å legge til flere ruter for samme adresse er ikke et design.