Samma subnät i båda ändar: mappa det externa LAN-et till ett ledigt intervall

Hemmet och kontoret kör båda 192.168.1.0/24, så en begäran till 192.168.1.1 har två möjliga svar och klienten väljer ett utan att fråga. Att numrera om ett fungerande kontorsnät är sällan populärt, och routerns adresser är ofta inbakade i skrivare, kameror och dokumentation. Adressmappning på klientsidan kan i stället presentera det externa nätet under ett ledigt intervall, och värddelen kan förbli identisk så att 192.168.1.20 visas som 10.203.41.20. Haken är att bara vissa klienter implementerar den, och att den inte gör något för returvägen.

Två vyer av samma värd

Mappningen behåller värddelen och ändrar bara nätverksdelen. Samma maskin svarar då på två adresser beroende på var du står. Att skriva ned båda kolumnerna innan du konfigurerar något förhindrar senare felläsning av loggar och brandväggsregler.

Lokala enheter hemma behåller sina egna 192.168.1.x-adresser, och det är poängen med övningen. Skrivaren i rummet intill är fortfarande nåbar medan kontoret visas under ett intervall som inte krockar.

Argumentordningen är hela tricket

Alternativet tar en riktning, ett nätverk och en mask, och ett alias: det första nätverket är det klienten ser, aliaset är det servern ser. För resurser som ligger bakom den externa gatewayen är riktningen destinationsformen. Att byta plats på de två nätverken eftersom det sista argumentet kallas alias är felet som ger en tunnel som ansluter och inte mappar något.

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"

Rutten är det som skickar klientens paket för det nya intervallet in i tunneln; översättningen skriver om destinationen på vägen. Ett svar från 192.168.1.20 skrivs tillbaka till 10.203.41.20 så att socketen på klienten förblir konsekvent. En enskild värd fungerar på samma sätt med en mask av full längd, så länge rutten och mappningen beskriver samma adress.

Detta är en adressmappning, inte en portmappning. Två tjänster på en värd kan inte skiljas med den, och ett protokoll som bäddar in IP-adresser i sin nyttolast ser fortfarande de riktiga.

Mappningen skapar ingen returväg

Översättningen sker på klienten, så servern måste fortfarande routa svar till tunneln och dess brandvägg måste fortfarande tillåta dem. Om den externa gatewayen inte vet hur den når tunnelns subnät kommer begäran in och svaret går ut genom fel dörr; mappningen får bara felet att se ut som ett klientproblem.

Regler på serversidan bör beskriva de adresser som finns på servern efter översättningen, inte intervallet klienten ser. Att kopiera aliaset till en tillåtelseregel slösar bort en eftermiddag, eftersom inget paket på den sidan bär det.

Välj ett aliasintervall som inte krockar med något annat klienten routar: en annan VPN, ett containernätverk, ett andra kontor. En krock här återinför den ursprungliga tvetydigheten under ett annat nummer och är svårare att se eftersom adresserna verkar obekanta.

Namn och nyttolaster överlever översättningen

Ett värdnamn som löser ut till den riktiga 192.168.1.20 skickar webbläsaren till den lokala enheten i stället för den externa, vad routingtabellen än säger. Det privata DNS-svaret måste peka på intervallet klienten ser, medan TLS-certifikatet fortfarande bär namnet som programmet förväntar sig. Testa med namnet i stället för adressen, eftersom adressen kan fungera medan namnet tyst löser ut åt fel håll. När den externa gatewayen också betjänar den zonen behöver dess egna poster också intervallet klienten ser.

Omdirigeringar, inbäddade URL:er och program som lämnar ut sin egen adress i en nyttolast kan gå sönder på sätt som ingen paketmappning kan reparera. Behandla dem som ett programproblem och dimensionera arbetet därefter innan du lovar att omnumrering är onödig.

Tre kontroller innan du förbinder dig

För det första, bekräfta klientimplementeringen. Community OpenVPN stöder det här alternativet; OpenVPN 3-kodbasen listar det bland funktioner som inte stöds, så en profil som skickas till en klient i Connect-stil kan helt enkelt ignorera det. Ett direktiv som accepteras och aldrig tillämpas är värre än ett fel, eftersom tunneln ser frisk ut.

För det andra, verifiera rutten och översättningen var för sig med ett kort diagnostikfönster vid hög detaljnivå, och testa sedan den faktiska tjänsten i stället för ping. För det tredje, bekräfta att den lokala routern och den externa resursen förblir särskiljbara från klienten, eftersom det var det ursprungliga målet.

Om klienten inte kan göra översättningen, be gateway-sidan om hjälp eller acceptera en omnumrering. Att lägga till fler rutter för samma adress är inte en design.