Ta pati potinklis abiejuose galuose: susiekite nuotolinį LAN su laisvu diapazonu

Namai ir biuras abu naudoja 192.168.1.0/24, todėl užklausa į 192.168.1.1 turi du galimus atsakymus, o klientas vieną pasirenka nepaklausęs. Veikiančio biuro tinklo pernumeravimas retai būna populiarus, o maršrutizatoriaus adresai dažnai įrašyti į spausdintuvus, kameras ir dokumentaciją. Kliento pusės adresų susiejimas gali vietoje to pateikti nuotolinį tinklą po laisvu diapazonu, o mazgo dalis gali likti ta pati, todėl 192.168.1.20 atrodo kaip 10.203.41.20. Kabliukas tas, kad jį įgyvendina tik kai kurie klientai ir jis nieko nedaro grįžtamajam keliui.

Du to paties mazgo vaizdai

Susiejimas išsaugo mazgo dalį ir keičia tik tinklo dalį. Tada ta pati mašina atsako dviem adresais priklausomai nuo to, kur stovite. Abiejų stulpelių užsirašymas prieš ką nors konfigūruojant apsaugo nuo vėlesnio neteisingo žurnalų ir ugniasienės taisyklių skaitymo.

Namų vietiniai įrenginiai išsaugo savo 192.168.1.x adresus, ir tai yra pratimo esmė. Spausdintuvas gretimame kambaryje lieka pasiekiamas, o biuras rodomas diapazone, kuris nesikerta.

Argumentų tvarka yra visas triukas

Parinktis priima kryptį, tinklą ir kaukę bei slapyvardį: pirmasis tinklas yra tai, ką mato klientas, slapyvardis yra tai, ką mato serveris. Ištekliams, esantiems už nuotolinio šliuzo, kryptis yra paskirties forma. Dviejų tinklų apvertimas dėl to, kad paskutinis argumentas vadinamas slapyvardžiu, yra klaida, sukurianti tunelį, kuris prisijungia ir nieko nesieja.

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"

Maršrutas yra tai, kas siunčia kliento paketus naujam diapazonui į tunelį; vertimas perrašo paskirtį pakeliui. Atsakymas iš 192.168.1.20 perrašomas atgal į 10.203.41.20, kad lizdas kliente išliktų nuoseklus. Vienas mazgas veikia taip pat su viso ilgio kauke, jei tik maršrutas ir susiejimas aprašo tą patį adresą.

Tai adresų susiejimas, o ne prievadų susiejimas. Dviejų paslaugų viename mazge juo atskirti negalima, o protokolas, kuris į savo naudingąją apkrovą įterpia IP adresus, vis tiek matys tikruosius.

Susiejimas nesukuria grįžtamojo kelio

Vertimas vyksta kliente, todėl serveris vis tiek turi maršrutizuoti atsakymus į tunelį, o jo ugniasienė vis tiek turi juos leisti. Jei nuotolinis šliuzas nežino, kaip pasiekti tunelio potinklį, užklausa atvyksta, o atsakymas išeina ne pro tas duris; susiejimas tik leidžia gedimui atrodyti kaip kliento problema.

Serverio pusės taisyklės turėtų aprašyti adresus, kurie serveryje egzistuoja po vertimo, o ne klientui matomą diapazoną. Slapyvardžio kopijavimas į leidimo taisyklę praranda popietę, nes joks paketas toje pusėje jo nenešioja.

Pasirinkite slapyvardžio diapazoną, kuris nesikerta su niekuo kitu, ką klientas maršrutizuoja: kita VPN, konteinerių tinklas, antras biuras. Susidūrimas čia vėl įveda pirminį dviprasmiškumą kitu numeriu ir jį sunkiau pastebėti, nes adresai atrodo nepažįstami.

Vardai ir naudingosios apkrovos išgyvena vertimą

Mazgo vardas, kuris išsprendžiamas į tikrąjį 192.168.1.20, siunčia naršyklę į vietinį įrenginį, o ne į nuotolinį, kad ir ką sako maršrutizavimo lentelė. Privataus DNS atsakymas turi rodyti į klientui matomą diapazoną, o TLS sertifikatas vis dar neša vardą, kurio tikisi programa. Tikrinkite vardu, o ne adresu, nes adresas gali veikti, kol vardas tyliai sprendžiamas neteisinga kryptimi. Kai nuotolinis šliuzas taip pat aptarnauja tą zoną, jo paties įrašams taip pat reikia klientui matomo diapazono.

Peradresavimai, įterpti URL ir programos, kurios savo adresą atiduoda naudingojoje apkrovoje, gali sugesti taip, kad joks paketų susiejimas nesutaisys. Traktuokite juos kaip programos problemą ir atitinkamai įvertinkite pastangas prieš žadėdami, kad pernumeravimas nereikalingas.

Trys patikros prieš įsipareigojant

Pirma, patvirtinkite kliento įgyvendinimą. Community OpenVPN palaiko šią parinktį; OpenVPN 3 kodų bazė ją įtraukia į nepalaikomų funkcijų sąrašą, todėl profilis, nustumtas Connect stiliaus klientui, gali ją tiesiog ignoruoti. Priimta ir niekada nepritaikyta direktyva yra blogiau nei klaida, nes tunelis atrodo sveikas.

Antra, patikrinkite maršrutą ir vertimą atskirai trumpu diagnostikos langu su dideliu išsamumu, tada išbandykite tikrąją paslaugą, o ne ping. Trečia, patvirtinkite, kad vietinis maršrutizatorius ir nuotolinis išteklius lieka atskiriami nuo kliento, nes tai buvo pirminis tikslas.

Jei klientas negali atlikti vertimo, paprašykite pagalbos šliuzo pusėje arba priimkite pernumeravimą. Daugiau maršrutų tam pačiam adresui pridėti nėra dizainas.