Dieselfde subnet aan albei kante: karteer die afgeleë LAN na 'n vrye reeks
Kliëntkant-adreskartering kan 'n oorvleuelende afgeleë LAN onder 'n vrye reeks voorstel, maar net sommige kliënte pas dit toe en die terugpad moet in elk geval bestaan.
Die huis en die kantoor gebruik albei 192.168.1.0/24, so 'n versoek na 192.168.1.1 het twee moontlike antwoorde en die kliënt kies een sonder om te vra. Om 'n werkende kantoornetwerk te hernommer is selde gewild, en die routeradresse is dikwels in drukkers, kameras en dokumentasie ingebak. 'n Kliëntkant-adreskartering kan die afgeleë netwerk eerder onder 'n vrye reeks voorstel, en die gasheerdeel kan dieselfde bly sodat 192.168.1.20 as 10.203.41.20 verskyn. Die haakplek is dat net sommige kliënte dit implementeer, en dit doen niks vir die terugpad nie.
Twee sienings van dieselfde gasheer
Die kartering behou die gasheerdeel en verander net die netwerkdeel. Dieselfde masjien antwoord dan by twee adresse, afhangende van waar jy staan. Om albei kolomme neer te skryf voordat jy iets opstel, voorkom 'n latere verkeerde uitlees van logs en firewall-reëls.
| The application dials | The remote device is |
|---|---|
| 10.203.41.1 | 192.168.1.1 |
| 10.203.41.20 | 192.168.1.20 |
Plaaslike toestelle by die huis behou hul eie 192.168.1.x-adresse, en dit is die punt van die oefening. Die drukker in die volgende kamer bly bereikbaar terwyl die kantoor onder 'n reeks verskyn wat nie bots nie.
Die argumentorde is die hele truuk
Die opsie neem 'n rigting, 'n netwerk en masker, en 'n alias: die eerste netwerk is wat die kliënt sien, die alias is wat die bediener sien. Vir hulpbronne agter die afgeleë poort is die rigting die bestemmingsvorm. Om die twee netwerke om te draai omdat die laaste argument 'n alias genoem word, is die fout wat 'n tonnel lewer wat verbind en niks karteer nie.
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"Die roete is wat die kliënt se pakkette vir die nuwe reeks in die tonnel stuur; die vertaling herskryf die bestemming op pad deur. 'n Antwoord van 192.168.1.20 word teruggeskryf na 10.203.41.20 sodat die sok op die kliënt konsekwent bly. 'n Enkele gasheer werk dieselfde met 'n vollengte masker, solank die roete en die kartering dieselfde adres beskryf.
Dit is 'n adreskartering, nie 'n poortkartering nie. Twee dienste op een gasheer kan nie daarmee geskei word nie, en 'n protokol wat IP-adresse in sy vrag inbed, sal steeds die werklike adresse sien.
Die kartering skep nie 'n terugpad nie
Vertaling vind by die kliënt plaas, so die bediener moet steeds antwoorde na die tonnel roeteer en sy firewall moet hulle steeds toelaat. As die afgeleë poort nie weet hoe om die tonnel-subnet te bereik nie, kom die versoek aan en vertrek die antwoord deur die verkeerde deur; die kartering laat die mislukking bloot soos 'n kliëntprobleem lyk.
Bedienerkant-reëls moet die adresse beskryf wat ná vertaling op die bediener bestaan, nie die kliëntsigbare reeks nie. Om die alias in 'n toelaatreël te kopieer, mors 'n middag, want geen pakket aan daardie kant dra dit nie.
Kies 'n aliasreeks wat nie met enigiets anders bots wat die kliënt roeteer nie: 'n ander VPN, 'n houernetwerk, 'n tweede kantoor. 'n Botsing hier bring die oorspronklike dubbelsinnigheid onder 'n ander nommer terug en is moeiliker om raak te sien omdat die adresse onbekend lyk.
Name en vragte oorleef die vertaling
'n Gasheernaam wat na die werklike 192.168.1.20 oplos, stuur die blaaier na die plaaslike toestel eerder as die afgeleë een, maak nie saak wat die roetebeheer sê nie. Die private DNS-antwoord moet na die kliëntsigbare reeks wys, terwyl die TLS-sertifikaat steeds die naam dra wat die toepassing verwag. Toets met die naam eerder as met die adres, want die adres kan werk terwyl die naam stilweg verkeerd oplos. Wanneer die afgeleë poort ook daardie sone bedien, het sy eie rekords ook die kliëntsigbare reeks nodig.
Wysigings, ingebedde URL's en toepassings wat hul eie adres in 'n vrag uitdeel, kan breek op maniere wat geen pakketkartering kan herstel nie. Hanteer dit as 'n toepassingsprobleem en beplan die inspanning daarvolgens voordat jy belowe dat hernommering onnodig is.
Drie kontroles voordat jy dit deurvoer
Eerstens, bevestig die kliëntimplementering. Community OpenVPN ondersteun hierdie opsie; die OpenVPN 3-kodebasis lys dit onder onondersteunde kenmerke, so 'n profiel wat na 'n Connect-styl kliënt gestuur word, kan dit bloot ignoreer. 'n Direktief wat aanvaar en nooit toegepas word nie, is erger as 'n fout, want die tonnel lyk gesond.
Tweedens, verifieer die roete en die vertaling afsonderlik met 'n kort diagnostiese venster teen hoë breedsprakigheid, en toets dan die werklike diens eerder as 'n ping. Derdens, bevestig dat die plaaslike router en die afgeleë hulpbron van die kliënt onderskei kan word, want dit was die oorspronklike doel.
As die kliënt nie die vertaling kan doen nie, vra die poortkant om hulp of aanvaar 'n hernommering. Om meer roetes vir dieselfde adres by te voeg, is nie 'n ontwerp nie.