Sama subreto ĉe ambaŭ finoj: mapu la malproksiman LAN al libera gamo

Hejmo kaj oficejo ambaŭ uzas 192.168.1.0/24, do peto al 192.168.1.1 havas du eblajn respondojn kaj la kliento elektas unu sen demandi. Renumerigi funkciantan oficejan reton malofte plaĉas, kaj la adresoj de la enkursigilo ofte estas enkorpigitaj en printiloj, fotiloj kaj dokumentaro. Klientflanka adresmapado povas anstataŭe prezenti la malproksiman reton sub libera gamo, kaj la gastiganta parto povas resti identa tiel ke 192.168.1.20 aperas kiel 10.203.41.20. La kaptilo estas ke nur kelkaj klientoj efektivigas ĝin, kaj ĝi faras nenion por la revena vojo.

Du vidpunktoj de la sama gastiganto

La mapado konservas la gastigantan parton kaj ŝanĝas nur la retan parton. La sama maŝino tiam respondas ĉe du adresoj laŭ tio, kie vi staras. Skribi ambaŭ kolumnojn antaŭ ol agordi ion ajn malhelpas postan misinterpretadon de protokoloj kaj fajroŝirmilaj reguloj.

Lokaj aparatoj hejme konservas siajn proprajn adresojn 192.168.1.x, kaj tio estas la senco de la ekzerco. La printilo en la apuda ĉambro restas atingebla dum la oficejo aperas sub gamo, kiu ne kolizias.

La ordo de la argumentoj estas la tuta artifiko

La opcio prenas direkton, reton kaj maskon, kaj kaŝnomon: la unua reto estas tio, kion vidas la kliento, la kaŝnomo estas tio, kion vidas la servilo. Por rimedoj, kiuj loĝas malantaŭ la malproksima enirejo, la direkto estas la cela formo. Inversigi la du retojn ĉar la lasta argumento nomiĝas kaŝnomo estas la eraro, kiu produktas tunelon, kiu konektiĝas kaj mapas nenion.

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"

La itinero estas tio, kio sendas la pakaĵojn de la kliento por la nova gamo en la tunelon; la traduko reskribas la celon survoje. Respondo de 192.168.1.20 reskribiĝas reen al 10.203.41.20 tiel ke la ingo ĉe la kliento restas konsekvenca. Unuopa gastiganto funkcias same kun plenlonga masko, kondiĉe ke la itinero kaj la mapado priskribas la saman adreson.

Ĉi tio estas adresmapado, ne pordmapado. Du servoj sur unu gastiganto ne povas esti apartigitaj per ĝi, kaj protokolo, kiu enkorpigas IP-adresojn en sia utilaĵo, ankoraŭ vidos la verajn.

La mapado ne kreas revenan vojon

La traduko okazas ĉe la kliento, do la servilo ankoraŭ devas enkursigi respondojn al la tunelo kaj ĝia fajroŝirmilo ankoraŭ devas permesi ilin. Se la malproksima enirejo ne scias, kiel atingi la subreton de la tunelo, la peto alvenas kaj la respondo eliras tra la malĝusta pordo; la mapado nur igas la malsukceson aspekti kiel klienta problemo.

Reguloj ĉe la servila flanko devus priskribi la adresojn, kiuj ekzistas sur la servilo post la traduko, ne la gamon videblan al la kliento. Kopii la kaŝnomon en permesan regulon malŝparas posttagmezon, ĉar neniu pakaĵo sur tiu flanko portas ĝin.

Elektu kaŝnomgamojn, kiuj ne kolizias kun io ajn alia, kion la kliento enkursigas: alia VPN, uja reto, dua oficejo. Kolizio ĉi tie reenkondukas la originan ambiguecon sub alia numero kaj estas pli malfacile videbla, ĉar la adresoj aspektas nekonataj.

Nomoj kaj utilaĵoj postvivas la tradukon

Gastignomo, kiu solviĝas al la vera 192.168.1.20, sendas la retumilon al la loka aparato anstataŭ al la malproksima, kion ajn diras la enkursiga tabelo. La respondo de la privata DNS devas montri al la gamo videbla al la kliento, dum la TLS-atestilo ankoraŭ portas la nomon, kiun la aplikaĵo atendas. Testu per la nomo anstataŭ per la adreso, ĉar la adreso povas funkcii dum la nomo silente solviĝas malĝustan direkton. Kiam la malproksima enirejo ankaŭ servas tiun zonon, ĝiaj propraj rikordoj ankaŭ bezonas la gamon videblan al la kliento.

Alidirektoj, enkorpigitaj URL-oj kaj aplikaĵoj, kiuj eldonas sian propran adreson en utilaĵo, povas rompiĝi tiel, ke neniu pakaĵmapado povas ripari. Traktu ilin kiel aplikaĵan problemon kaj taksu la penon konforme antaŭ ol promesi, ke renumerigo ne necesas.

Tri kontroloj antaŭ ol engaĝiĝi

Unue, konfirmu la klientan efektivigon. Community OpenVPN subtenas ĉi tiun opcion; la kodbazo de OpenVPN 3 listigas ĝin inter la nesubtenataj trajtoj, do profilo puŝita al kliento de stilo Connect eble simple ignoros ĝin. Direktivo, kiu estas akceptita kaj neniam aplikita, estas pli malbona ol eraro, ĉar la tunelo aspektas sana.

Due, kontrolu la itineron kaj la tradukon aparte per mallonga diagnoza fenestro ĉe alta detalo, poste testu la faktan servon anstataŭ ping. Trie, konfirmu, ke la loka enkursigilo kaj la malproksima rimedo restas distingeblaj de la kliento, ĉar tio estis la origina celo.

Se la kliento ne povas fari la tradukon, petu helpon de la enireja flanko aŭ akceptu renumerigon. Aldoni pli da itineroj por la sama adreso ne estas dezajno.