Same subnett i begge endar: kartlegg det eksterne LAN-et til eit ledig område

Heimen og kontoret køyrer begge 192.168.1.0/24, så ein førespurnad til 192.168.1.1 har to moglege svar, og klienten vel eitt utan å spørje. Det er sjeldan populært å omnummerere eit fungerande kontornettverk, og ruteradressene er ofte baka inn i skrivarar, kamera og dokumentasjon. Adressekartlegging på klientsida kan i staden presentere det eksterne nettet under eit ledig område, og vertsdelen kan halde fram lik, slik at 192.168.1.20 framstår som 10.203.41.20. Haken er at berre nokre klientar implementerer det, og at det ikkje gjer noko for returvegen.

To visningar av same vert

Kartlegginga held på vertsdelen og endrar berre nettverksdelen. Den same maskina svarar då på to adresser avhengig av kvar du står. Å skrive ned begge kolonnane før du konfigurerer noko, hindrar seinare feillesing av loggar og brannmurreglar.

Lokale einingar heime held på sine eigne 192.168.1.x-adresser, og det er poenget med øvinga. Skrivaren i naborommet er framleis tilgjengeleg medan kontoret viser seg under eit område som ikkje kolliderer.

Argumentrekkjefølgja er heile trikset

Alternativet tek ei retning, eit nettverk og ei maske, og eit alias: det første nettverket er det klienten ser, aliaset er det tenaren ser. For ressursar som ligg bak den eksterne gatewayen, er retninga destinasjonsforma. Å byte om dei to netta fordi det siste argumentet blir kalla eit alias, er feilen som gjev ein tunnel som koplar til og ikkje kartlegg noko.

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"

Ruta er det som sender pakkane til klienten for det nye området inn i tunnelen; omsetjinga skriv om destinasjonen undervegs. Eit svar frå 192.168.1.20 blir skrive tilbake til 10.203.41.20, slik at socketen på klienten held seg konsistent. Ein einaste vert fungerer på same måte med ei maske i full lengd, så lenge ruta og kartlegginga skildrar same adresse.

Dette er adressekartlegging, ikkje portkartlegging. To tenester på ein vert kan ikkje skiljast med henne, og ein protokoll som legg IP-adresser i nyttelasta vil framleis sjå dei verkelege.

Kartlegginga skaper ikkje ein returveg

Omsetjinga skjer på klienten, så tenaren må framleis rute svar til tunnelen, og brannmuren hans må framleis tillate dei. Viss den eksterne gatewayen ikkje veit korleis han når subnettet til tunnelen, kjem førespurnaden inn, og svaret går ut gjennom feil dør; kartlegginga får berre feilen til å sjå ut som eit klientproblem.

Reglar på tenarsida bør skildre adressene som finst på tenaren etter omsetjinga, ikkje området klienten ser. Å kopiere aliaset inn i ein tillatingsregel sløser bort ein ettermiddag, fordi ingen pakke på den sida ber det.

Vel eit aliasområde som ikkje kolliderer med noko anna klienten rutar: ein annan VPN, eit containernettverk, eit andre kontor. Ei kollisjon her gjeninnfører den opphavlege tvitydigheita under eit anna nummer og er vanskelegare å sjå fordi adressene verkar ukjende.

Namn og nyttelaster overlever omsetjinga

Eit vertsnamn som blir løyst til den ekte 192.168.1.20 sender nettlesaren til den lokale eininga i staden for den eksterne, uansett kva rutetabellen seier. Det private DNS-svaret må peike på området klienten ser, medan TLS-sertifikatet framleis ber namnet applikasjonen ventar. Test med namnet i staden for adressa, fordi adressa kan verke medan namnet stille blir løyst den gale vegen. Når den eksterne gatewayen også tener den sona, treng hans eigne oppføringar også området klienten ser.

Omdirigeringar, innebygde URL-ar og applikasjonar som gjev ut si eiga adresse i ei nyttelast kan bryte saman på måtar ingen pakkekartlegging kan reparere. Handsaminga er å sjå på dei som eit applikasjonsproblem og dimensjonere innsatsen deretter før du lovar at omnummerering er unødvendig.

Tre kontrollar før du forpliktar deg

Fyrst, stadfest klientimplementeringa. Community OpenVPN støttar dette alternativet; OpenVPN 3-kodebasen fører det opp blant funksjonane som ikkje er støtta, så ein profil som blir skyvd til ein klient i Connect-stil, kan rett og slett ignorere det. Eit direktiv som blir godteke og aldri brukt, er verre enn ein feil, fordi tunnelen ser sunn ut.

For det andre, stadfest ruta og omsetjinga kvar for seg med eit kort diagnostikkvindauge ved høg detaljering, og test deretter den faktiske tenesta i staden for ein ping. For det tredje, stadfest at den lokale ruteren og den eksterne ressursen held seg skilbare frå klienten, sidan det var det opphavlege målet.

Viss klienten ikkje kan gjere omsetjinga, be gateway-sida om hjelp eller godta ei omnummerering. Å leggje til fleire ruter for same adresse er ikkje eit design.