Viens un tas pats apakštīkls abos galos: kartējiet attālo LAN uz brīvu diapazonu
Klienta puses adrešu kartēšana var parādīt pārklājošu attālo LAN zem brīva diapazona, bet to piemēro tikai daži klienti, un atgriešanās ceļam tomēr jābūt.
Mājas un birojs abi izmanto 192.168.1.0/24, tāpēc pieprasījumam uz 192.168.1.1 ir divas iespējamās atbildes, un klients izvēlas vienu, neprasot. Strādājoša biroja tīkla pārnumurēšana reti ir populāra, un maršrutētāja adreses bieži ir iestrādātas printeros, kamerās un dokumentācijā. Klienta puses adrešu kartēšana var tā vietā parādīt attālo tīklu zem brīva diapazona, un resursdatora daļa var palikt tāda pati, tāpēc 192.168.1.20 parādās kā 10.203.41.20. Āķis ir tāds, ka to ievieš tikai daži klienti un tas neko nedara atgriešanās ceļam.
Divi skati uz vienu un to pašu resursdatoru
Kartēšana saglabā resursdatora daļu un maina tikai tīkla daļu. Tā pati iekārta tad atbild uz divām adresēm atkarībā no tā, kur jūs stāvat. Abu kolonnu pierakstīšana pirms kaut kā konfigurēšanas novērš vēlāku nepareizu žurnālu un ugunsmūra noteikumu nolasīšanu.
| The application dials | The remote device is |
|---|---|
| 10.203.41.1 | 192.168.1.1 |
| 10.203.41.20 | 192.168.1.20 |
Mājas vietējās ierīces saglabā savas 192.168.1.x adreses, un tā ir vingrinājuma būtība. Printeris blakus telpā paliek sasniedzams, kamēr birojs parādās diapazonā, kas nesaskaras.
Argumentu secība ir viss triks
Opcija ņem virzienu, tīklu un masku, un aizstājvārdu: pirmais tīkls ir tas, ko redz klients, aizstājvārds ir tas, ko redz serveris. Resursiem, kas atrodas aiz attālās vārtejas, virziens ir galamērķa forma. Abu tīklu apvēršana tāpēc, ka pēdējais arguments tiek saukts par aizstājvārdu, ir kļūda, kas rada tuneli, kurš pieslēdzas un neko nekartē.
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šruts ir tas, kas klienta paketes jaunajam diapazonam sūta tunelī; tulkojums pārraksta galamērķi pa ceļam. Atbilde no 192.168.1.20 tiek pārrakstīta atpakaļ uz 10.203.41.20, lai ligzda klientā paliktu konsekventa. Viens resursdators darbojas tāpat ar pilna garuma masku, ja vien maršruts un kartēšana apraksta vienu un to pašu adresi.
Šī ir adrešu kartēšana, nevis portu kartēšana. Divus pakalpojumus vienā resursdatorā ar to nevar atdalīt, un protokols, kas savā kravā iestrādā IP adreses, joprojām redzēs īstās.
Kartēšana neizveido atgriešanās ceļu
Tulkojums notiek klientā, tāpēc serverim joprojām ir jāmaršrutē atbildes tunelī, un tā ugunsmūrim tās joprojām ir jāatļauj. Ja attālā vārteja nezina, kā sasniegt tuneļa apakštīklu, pieprasījums ierodas un atbilde iziet pa nepareizajām durvīm; kartēšana tikai liek atteicei izskatīties kā klienta problēmai.
Servera puses noteikumiem vajadzētu aprakstīt adreses, kas serverī pastāv pēc tulkojuma, nevis klientam redzamo diapazonu. Aizstājvārda kopēšana atļaujas noteikumā izšķiež pēcpusdienu, jo neviens pakets tajā pusē to nenes.
Izvēlieties aizstājvārda diapazonu, kas nesaskaras ar neko citu, ko klients maršrutē: cita VPN, konteineru tīkls, otra birojs. Sadursme šeit atkal ievieš sākotnējo neskaidrību citā numurā, un to ir grūtāk pamanīt, jo adreses izskatās nepazīstamas.
Vārdi un kravas pārdzīvo tulkojumu
Resursdatora vārds, kas atrisinās uz īsto 192.168.1.20, sūta pārlūku uz vietējo ierīci, nevis attālo, lai ko teiktu maršrutēšanas tabula. Privātā DNS atbildei jānorāda uz klientam redzamo diapazonu, kamēr TLS sertifikāts joprojām nes vārdu, kuru programma sagaida. Pārbaudiet ar vārdu, nevis ar adresi, jo adrese var darboties, kamēr vārds klusi atrisinās nepareizajā virzienā. Kad attālā vārteja apkalpo arī šo zonu, arī tās pašas ierakstiem vajag klientam redzamo diapazonu.
Pāradresācijas, iegultie URL un programmas, kas savu adresi atdod kravā, var salūzt tā, ka nekāda pakešu kartēšana to nesalabos. Uztveriet tās kā programmas problēmu un attiecīgi novērtējiet pūles, pirms apsolāt, ka pārnumurēšana nav nepieciešama.
Trīs pārbaudes pirms saistībām
Pirmkārt, apstipriniet klienta ieviešanu. Community OpenVPN atbalsta šo opciju; OpenVPN 3 kodu bāze to iekļauj neatbalstīto funkciju sarakstā, tāpēc profils, kas nosūtīts Connect stila klientam, to var vienkārši ignorēt. Pieņemta un nekad nepiemērota direktīva ir sliktāka par kļūdu, jo tunelis izskatās vesels.
Otrkārt, pārbaudiet maršrutu un tulkojumu atsevišķi ar īsu diagnostikas logu augstā detalizācijā, pēc tam pārbaudiet faktisko pakalpojumu, nevis ping. Treškārt, apstipriniet, ka vietējais maršrutētājs un attālais resurss paliek atšķirami no klienta, jo tas bija sākotnējais mērķis.
Ja klients nevar veikt tulkojumu, lūdziet palīdzību vārtejas pusē vai pieņemiet pārnumurēšanu. Vairāk maršrutu tai pašai adresei pievienot nav dizains.