Kio okazas pri konektoj ene kaj ekster la VPN-tunelo

Veraj artikoloj naskiĝas el leteroj al teknika subteno de Tucha. Ekzemple, kliento lastatempe kontaktis nin kun peto klarigi kio okazas dum konektoj ene de la VPN-tunelo inter la oficejo de la uzanto kaj la nuba medio, same kiel dum konektoj ekster la VPN-tunelo. Tial la tuta teksto sube estas reala letero, kiun ni sendis al unu el niaj klientoj responde al lia demando. Kompreneble, la IP-adresoj estis ŝanĝitaj por ne senanonimigi la klienton. Sed jes, la teknika subteno de Tucha estas vere fama pro siaj detalaj respondoj kaj informaj retpoŝtoj. 🙂

Kompreneble, ni komprenas, ke por multaj ĉi tiu artikolo ne estos revelacio. Sed, ĉar artikoloj por komencaj administrantoj aperas ĉe Habr de tempo al tempo, kaj ankaŭ ĉar ĉi tiu artikolo aperis de vera letero al vera kliento, ni ankoraŭ dividos ĉi tiun informon ĉi tie. Estas alta probablo ke ĝi estos utila al iu.
Sekve, ni klarigas detale kio okazas inter la servilo en la nubo kaj la oficejo se ili estas konektitaj per retejo-al-ejo reto. Notu, ke iuj servoj estas alireblaj nur de la oficejo, kaj iuj estas alireblaj de ie ajn en la Interreto.

Ni tuj klarigu, kion nia kliento volis sur la servilo 192.168.A.1 vi povus veni de ie ajn per RDP, konektante al AAA2:13389, kaj aliro al aliaj servoj nur de la oficejo (192.168.B.0/24)konektita per VPN. Ankaŭ, la kliento komence havis ĝin agordita ke la aŭto 192.168.B.2 en la oficejo ankaŭ eblis uzi RDP de ie ajn, konektante al BBB1:11111. Ni helpis organizi IPSec-konektojn inter la nubo kaj la oficejo, kaj la IT-specialisto de la kliento komencis demandi demandojn pri tio, kio okazos en tiu aŭ alia kazo. Por respondi ĉiujn ĉi tiujn demandojn, ni fakte skribis al li ĉion, kion vi povas legi sube.

Kio okazas pri konektoj ene kaj ekster la VPN-tunelo

Nun ni rigardu ĉi tiujn procezojn pli detale.

Pozicio unu

Kiam io estas sendita de 192.168.B.0/24 в 192.168.A.0/24 aŭ de 192.168.A.0/24 в 192.168.B.0/24, ĝi eniras la VPN. Tio estas, ĉi tiu pako estas aldone ĉifrita kaj transdonita inter BBB1 и AAA1, sed 192.168.A.1 vidas la pakaĵon ĝuste de 192.168.B.1. Ili povas komuniki unu kun la alia uzante ajnan protokolon. Revenaj respondoj estas transdonitaj de la sama maniero tra la VPN, kio signifas, ke la pako de 192.168.A.1 por 192.168.B.1 estos sendita kiel ESP-dagramo de AAA1 sur BBB1, kiun la enkursigilo disvolvos tiuflanke, elprenu tiun pakaĵeton el ĝi kaj sendu ĝin 192.168.B.1 kiel pako de 192.168.A.1.

Specifa ekzemplo:

1) 192.168.B.1 apelacias al 192.168.A.1, volas establi TCP-konekton kun 192.168.A.1:3389;

2) 192.168.B.1 sendas konektopeton de 192.168.B.1:55555 (li mem elektas la havennumeron por retrosciigo; ĉi-poste ni uzos la numeron 55555 kiel ekzemplon de la havennumero, kiun la sistemo elektas dum formado de TCP-konekto) sur 192.168.A.1:3389;

3) operaciumo, kiu funkcias per komputilo kun la adreso 192.168.B.1, decidas plusendi ĉi tiun paketon al la enirejadreso de la enkursigilo (192.168.B.254 en nia kazo), ĉar aliaj, pli specifaj itineroj por 192.168.A.1, ĝi ne havas, do, ĝi elsendas la pakaĵon per la defaŭlta itinero (0.0.0.0/0);

4) por tio ĝi provas trovi la MAC-adreson por la IP-adreso 192.168.B.254 en la ARP-protokola kaŝmemortabelo. Se ĝi ne estas detektita, sendas de la adreso 192.168.B.1 dissendi who-havas peton al la reto 192.168.B.0/24... Kiam 192.168.B.254 en respondo, ĝi sendas al ĝi sian MAC-adreson, la sistemo elsendas Ethernet-pakaĵon por ĝi kaj enmetas ĉi tiujn informojn en sian kaŝmemortabelon;

5) la enkursigilo ricevas ĉi tiun pakaĵon kaj decidas kien plusendi ĝin: ĝi havas skriban politikon laŭ kiu ĝi devas sendi ĉiujn pakaĵojn inter 192.168.B.0/24 и 192.168.A.0/24 translokigi per VPN-konekto inter BBB1 и AAA1;

6) la enkursigilo generas ESP-dagramon de BBB1 sur AAA1;

7) la enkursigilo decidas al kiu sendi ĉi tiun pakaĵon, ĝi sendas ĝin, ekzemple, BBB254 (ISP-enirejo) ĉar ekzistas pli specifaj itineroj al AAA1, ol 0.0.0.0/0, ĝi ne havas;

8) ekzakte same kiel jam dirite, ĝi trovas la MAC-adreson por BBB254 kaj transdonas la pakaĵon al la ISP-enirejo;

9) Interretaj provizantoj elsendas ESP-dagramon de BBB1 sur AAA1;

10) virtuala enkursigilo ŝaltita AAA1 ricevas ĉi tiun datugramon, deĉifras ĝin kaj ricevas pakaĵeton de 192.168.B.1:55555 por 192.168.A.1:3389;

11) la virtuala enkursigilo kontrolas al kiu pasi ĝin, trovas la reton en la vojtabelo 192.168.A.0/24 kaj sendas ĝin rekte al 192.168.A.1, ĉar ĝi havas interfacon 192.168.A.254/24;

12) por tio, la virtuala enkursigilo trovas la MAC-adreson por 192.168.A.1 kaj transdonas ĉi tiun paketon al li per virtuala Ethernet-reto;

13) 192.168.A.1 ricevas ĉi tiun pakaĵeton sur haveno 3389, konsentas establi konekton kaj generas pakaĵeton en respondo de 192.168.A.1:3389 sur 192.168.B.1:55555;

14) lia sistemo elsendas ĉi tiun paketon al la enireja adreso de la virtuala enkursigilo (192.168.A.254 en nia kazo), ĉar aliaj, pli specifaj itineroj por 192.168.B.1, ĝi ne havas, do, ĝi devas transdoni la pakaĵon per la defaŭlta itinero (0.0.0.0/0);

15) la sama kiel en antaŭaj kazoj, sistemo kiu funkcias sur servilo kun la adreso 192.168.A.1, trovas la MAC-adreson 192.168.A.254, ĉar ĝi estas en la sama reto kun sia interfaco 192.168.A.1/24;

16) la virtuala enkursigilo ricevas ĉi tiun paketon kaj decidas kien plusendi ĝin: ĝi havas skriban politikon laŭ kiu ĝi devas sendi ĉiujn pakaĵetojn inter 192.168.A.0/24 и 192.168.B.0/24 translokigi per VPN-konekto inter AAA1 и BBB1;

17) la virtuala enkursigilo generas ESP-dagramon de AAA1 por BBB1;

18) la virtuala enkursigilo decidas al kiu sendi ĉi tiun pakaĵon, al kiu sendas ĝin AAA254 (ISP-enirejo, en ĉi tiu kazo, tio estas ankaŭ ni), ĉar ekzistas pli specifaj itineroj al BBB1, ol 0.0.0.0/0, ĝi ne havas;

19) Interretaj provizantoj transdonas ESP-dagramon tra siaj retoj kun AAA1 sur BBB1;

20) enkursigilo sur BBB1 ricevas ĉi tiun datugramon, deĉifras ĝin kaj ricevas pakaĵeton de 192.168.A.1:3389 por 192.168.B.1:55555;

21) li komprenas, ke ĝi devus esti transdonita specife al 192.168.B.1, ĉar li estas en la sama reto kun li, do li havas respondan enskribon en la enrutiga tabelo, kiu devigas lin sendi pakaĵojn por la tuta 192.168.B.0/24 rekte;

22) la enkursigilo trovas la MAC-adreson por 192.168.B.1 kaj donas al li ĉi tiun pakaĵon;

23) operaciumo en komputilo kun la adreso 192.168.B.1 ricevas pakaĵon de 192.168.A.1:3389 por 192.168.B.1:55555 kaj iniciatas la sekvajn paŝojn por establi TCP-konekton.

Ĉi tiu ekzemplo sufiĉe koncize kaj simple (kaj ĉi tie vi povas memori amason da aliaj detaloj) priskribas kio okazas ĉe niveloj 2-4. Niveloj 1, 5-7 ne estas konsiderataj.

Pozicio du

Se kun 192.168.B.0/24 io estas sendata specife al AAA2, ĝi ne iras al la VPN, sed rekte. Tio estas, se la uzanto de la adreso 192.168.B.1 apelacias al AAA2:13389, ĉi tiu pako venas de la adreso BBB1, pasas AAA2, kaj tiam la enkursigilo ricevas ĝin kaj transdonas ĝin al 192.168.A.1. 192.168.A.1 scias nenion pri 192.168.B.1, li vidas pakaĵon el BBB1, ĉar li ricevis lin. Tial, la respondo al ĉi tiu peto sekvas la ĝeneralan vojon, ĝi venas de la adreso same AAA2 kaj iras al BBB1, kaj tiu enkursigilo sendas ĉi tiun respondon al 192.168.B.1, li vidas la respondon de AAA2, al kiu li alparolis.

Specifa ekzemplo:

1) 192.168.B.1 apelacias al AAA2, volas establi TCP-konekton kun AAA2:13389;

2) 192.168.B.1 sendas konektopeton de 192.168.B.1:55555 (ĉi tiu nombro, kiel en la antaŭa ekzemplo, povas esti malsama) on AAA2:13389;

3) operaciumo, kiu funkcias per komputilo kun la adreso 192.168.B.1, decidas plusendi ĉi tiun paketon al la enirejadreso de la enkursigilo (192.168.B.254 en nia kazo), ĉar aliaj, pli specifaj itineroj por AAA2, ĝi ne havas tian, kio signifas, ke ĝi transdonas la pakaĵon per la defaŭlta itinero (0.0.0.0/0);

4) por tio, kiel ni menciis en la antaŭa ekzemplo, ĝi provas trovi la MAC-adreson por la IP-adreso 192.168.B.254 en la ARP-protokola kaŝmemortabelo. Se ĝi ne estas detektita, sendas de la adreso 192.168.B.1 dissendi who-havas peton al la reto 192.168.B.0/24... Kiam 192.168.B.254 en respondo, ĝi sendas al ĝi sian MAC-adreson, la sistemo elsendas Ethernet-pakaĵon por ĝi kaj enmetas ĉi tiujn informojn en sian kaŝmemortabelon;

5) la enkursigilo ricevas ĉi tiun pakaĵon kaj decidas kien plusendi ĝin: ĝi havas skriban politikon laŭ kiu ĝi devas plusendi (anstataŭante la revenadreson) ĉiujn pakaĵetojn de 192.168.B.0/24 al aliaj interretaj nodoj;

6) ĉar ĉi tiu politiko implicas, ke la revenadreso devas kongrui kun la malalta adreso sur la interfaco tra kiu ĉi tiu pako estos elsendita, la enkursigilo unue decidas al kiu precize sendi ĉi tiun pakaĵon, kaj li, kiel en la antaŭa ekzemplo, devas sendi ĝin. al BBB254 (ISP-enirejo) ĉar ekzistas pli specifaj itineroj al AAA2, ol 0.0.0.0/0, ĝi ne havas;

7) tial, la enkursigilo anstataŭigas la revenadreson de la pakaĵeto, de nun la pako estas de BBB1:44444 (portnumero, kompreneble, povas esti malsama) al AAA2:13389;

8) la enkursigilo memoras, kion ĝi faris, kio signifas kiam AAA2:13389 к BBB1:44444 respondo alvenos, li scios, ke li devas ŝanĝi la cel-adreson kaj havenon al 192.168.B.1:55555.

9) nun la enkursigilo devus pasi ĝin al la ISP-reto per BBB254tial, same kiel ni jam menciis, ĝi trovas la MAC-adreson por BBB254 kaj transdonas la pakaĵon al la ISP-enirejo;

10) Interretaj provizantoj transdonas pakojn de BBB1 sur AAA2;

11) virtuala enkursigilo ŝaltita AAA2 ricevas ĉi tiun paketon sur la haveno 13389;

12) ekzistas regulo pri la virtuala enkursigilo, kiu kondiĉas, ke pakaĵoj ricevitaj de iu ajn sendinto sur ĉi tiu haveno estu elsenditaj al 192.168.A.1:3389;

13) la virtuala enkursigilo trovas la reton en la vojtabelo 192.168.A.0/24 kaj sendas ĝin rekte 192.168.A.1 ĉar ĝi havas interfacon 192.168.A.254/24;

14) por tio, la virtuala enkursigilo trovas la MAC-adreson por 192.168.A.1 kaj transdonas ĉi tiun paketon al li per virtuala Ethernet-reto;

15) 192.168.A.1 ricevas ĉi tiun pakaĵeton sur haveno 3389, konsentas establi konekton kaj generas pakaĵeton en respondo de 192.168.A.1:3389 sur BBB1:44444;

16) lia sistemo elsendas ĉi tiun paketon al la enireja adreso de la virtuala enkursigilo (192.168.A.254 en nia kazo), ĉar aliaj, pli specifaj itineroj por BBB1, ĝi ne havas, do, ĝi devas transdoni la pakaĵon per la defaŭlta itinero (0.0.0.0/0);

17) ĝuste la sama kiel en antaŭaj kazoj, sistemo kiu funkcias sur servilo kun la adreso 192.168.A.1, trovas la MAC-adreson 192.168.A.254, ĉar ĝi estas en la sama reto kun sia interfaco 192.168.A.1/24;

18) la virtuala enkursigilo ricevas ĉi tiun pakaĵon. Oni devas rimarki, ke li memoras pri kio li ricevis AAA2:13389 pako de BBB1:44444 kaj ŝanĝis la adreson kaj havenon de sia ricevanto al 192.168.A.1:3389, do, la pako de 192.168.A.1:3389 por BBB1:44444 ĝi ŝanĝas la sendandreson al AAA2:13389;

19) la virtuala enkursigilo decidas al kiu sendi ĉi tiun pakaĵon, al ĝi sendas ĝin AAA254 (ISP-enirejo, en ĉi tiu kazo, tio estas ankaŭ ni), ĉar ekzistas pli specifaj itineroj al BBB1, ol 0.0.0.0/0, ĝi ne havas;

20) Interretaj provizantoj elsendas pakaĵon kun AAA2 sur BBB1;

21) enkursigilo sur BBB1 ricevas ĉi tiun paketon kaj memoras tion kiam li sendis la pakaĵeton de 192.168.B.1:55555 por AAA2:13389, li ŝanĝis sian adreson kaj sendindan havenon al BBB1:44444, tiam ĉi tiu estas la respondo al kiu devas esti sendita 192.168.B.1:55555 (fakte, ekzistas pluraj pliaj kontroloj tie, sed ni ne profundigas tion);

22) li komprenas, ke ĝi estu transdonita rekte al 192.168.B.1, ĉar li estas en la sama reto kun li, do li havas respondan enskribon en la enrutiga tabelo, kiu devigas lin sendi pakaĵojn por la tuta 192.168.B.0/24 rekte;

23) la enkursigilo trovas la MAC-adreson por 192.168.B.1 kaj donas al li ĉi tiun pakaĵon;

24) operaciumo en komputilo kun la adreso 192.168.B.1 ricevas pakaĵon de AAA2:13389 por 192.168.B.1:55555 kaj iniciatas la sekvajn paŝojn por establi TCP-konekton.

Oni notu, ke en ĉi tiu kazo la komputilo kun la adreso 192.168.B.1 scias nenion pri la servilo kun la adreso 192.168.A.1, li nur komunikas kun AAA2. Same, la servilo kun la adreso 192.168.A.1 scias nenion pri la komputilo kun la adreso 192.168.B.1. Li kredas, ke li estis konektita de la adreso BBB1, kaj li scias nenion alian, por tiel diri.

Oni ankaŭ notu, ke se ĉi tiu komputilo aliras AAA2:1540, la konekto ne estos establita ĉar konekto plusendado al haveno 1540 ne estas agordita sur la virtuala enkursigilo, eĉ se en iuj serviloj en la virtuala reto 192.168.A.0/24 (ekzemple, sur servilo kun la adreso 192.168.A.1) kaj estas iuj servoj, kiuj atendas konektojn sur ĉi tiu haveno. Se komputila uzanto kun adreso 192.168.B.1 Nepras establi konekton al ĉi tiu servo, ĝi devas uzi VPN, t.e. kontaktu rekte 192.168.A.1:1540.

Oni devas emfazi, ke ajna provo establi ligon kun AAA1 (krom la IPSec-konekto de la BBB1 ne sukcesos. Ajnaj provoj establi ligojn kun AAA2, krom konektoj al haveno 13389, ankaŭ ne sukcesos.
Ni ankaŭ rimarkas, ke se al AAA2 Se iu alia aplikas (ekzemple, CCCC), ĉio indikita en paragrafoj 10-20 validos ankaŭ por li. Kio okazas antaŭ kaj post tio dependas de kio precize estas malantaŭ ĉi tiu CCCC Ni ne havas tiajn informojn, do ni konsilas vin konsulti la administrantojn de la nodo kun la CCCC-adreso.

Pozicio tri

Kaj, male, se kun 192.168.A.1 io estas sendita al iu haveno, kiu estas agordita por plusendi enen al BBB1 (ekzemple, 11111), ĝi ankaŭ ne finiĝas en la VPN, sed simple fluas de AAA1 kaj eniras BBB1, kaj li jam transdonas ĝin ie en, ekzemple, 192.168.B.2:3389. Li vidas ĉi tiun pakaĵon ne de 192.168.A.1, kaj de AAA1. Kaj kiam 192.168.B.2 respondas, la pako venas de BBB1 sur AAA1, kaj poste venas al la konektoiniciato - 192.168.A.1.

Specifa ekzemplo:

1) 192.168.A.1 apelacias al BBB1, volas establi TCP-konekton kun BBB1:11111;

2) 192.168.A.1 sendas konektopeton de 192.168.A.1:55555 (ĉi tiu nombro, kiel en la antaŭa ekzemplo, povas esti malsama) on BBB1:11111;

3) operaciumo, kiu funkcias en servilo kun la adreso 192.168.A.1, decidas plusendi ĉi tiun paketon al la enirejadreso de la enkursigilo (192.168.A.254 en nia kazo), ĉar aliaj, pli specifaj itineroj por BBB1, ĝi ne havas, do, ĝi elsendas la pakaĵon per la defaŭlta itinero (0.0.0.0/0);

4) por tio, kiel ni menciis en antaŭaj ekzemploj, ĝi provas trovi la MAC-adreson por la IP-adreso 192.168.A.254 en la ARP-protokola kaŝmemortabelo. Se ĝi ne estas detektita, sendas de la adreso 192.168.A.1 dissendi who-havas peton al la reto 192.168.A.0/24... Kiam 192.168.A.254 en respondo, li sendas al ŝi sian MAC-adreson, la sistemo elsendas Ethernet-pakaĵeton por ĝi kaj enmetas ĉi tiujn informojn en sian kaŝmemortabelon;

5) la virtuala enkursigilo ricevas ĉi tiun pakaĵon kaj decidas kien plusendi ĝin: ĝi havas skriban politikon laŭ kiu ĝi devas plusendi (anstataŭante la revenadreson) ĉiujn pakaĵetojn de 192.168.A.0/24 al aliaj interretaj nodoj;

6) ĉar ĉi tiu politiko supozas, ke la revenadreso devas kongrui kun la malalta adreso sur la interfaco tra kiu ĉi tiu pako estos elsendita, la virtuala enkursigilo unue decidas al kiu precize sendi ĉi tiun pakaĵeton, kaj li, kiel en la antaŭa ekzemplo, devas sendi ĝi sur AAA254 (ISP-enirejo, en ĉi tiu kazo, tio estas ankaŭ ni), ĉar ekzistas pli specifaj itineroj al BBB1, ol 0.0.0.0/0, ĝi ne havas;

7) tio signifas, ke la virtuala enkursigilo anstataŭigas la revenadreson de la pako, de nun ĝi estas pako de AAA1:44444 (portnumero, kompreneble, povas esti malsama) al BBB1:11111;

8) la virtuala enkursigilo memoras, kion ĝi faris, do kiam de BBB1:11111 por AAA1:44444 respondo alvenos, li scios, ke li devas ŝanĝi la cel-adreson kaj havenon al 192.168.A.1:55555.

9) nun la virtuala enkursigilo devus pasi ĝin al la ISP-reto per AAA254, do same kiel ni jam menciis, ĝi trovas la MAC-adreson por AAA254 kaj transdonas la pakaĵon al la ISP-enirejo;

10) Interretaj provizantoj transdonas pakojn de AAA1 al BBB1;

11) enkursigilo sur BBB1 ricevas ĉi tiun paketon sur la haveno 11111;

12) ekzistas regulo pri la virtuala enkursigilo, kiu kondiĉas, ke pakaĵoj, kiuj alvenis de iu ajn sendinto sur ĉi tiu haveno, estu elsenditaj al 192.168.B.2:3389;

13) la enkursigilo trovas la reton en la vojtabelo 192.168.B.0/24 kaj sendas ĝin rekte al 192.168.B.2, ĉar ĝi havas interfacon 192.168.B.254/24;

14) por tio, la virtuala enkursigilo trovas la MAC-adreson por 192.168.B.2 kaj transdonas ĉi tiun paketon al li per virtuala Ethernet-reto;

15) 192.168.B.2 ricevas ĉi tiun pakaĵeton sur haveno 3389, konsentas establi konekton kaj generas pakaĵeton en respondo de 192.168.B.2:3389 sur AAA1:44444;

16) lia sistemo elsendas ĉi tiun pakaĵon al la enirejadreso de la enkursigilo (192.168.B.254 en nia kazo), ĉar aliaj, pli specifaj itineroj por AAA1, ĝi ne havas, do, ĝi devas transdoni la pakaĵon per la defaŭlta itinero (0.0.0.0/0);

17) sammaniere kiel en antaŭaj kazoj, sistemo kiu funkcias per komputilo kun la adreso 192.168.B.2, trovas la MAC-adreson 192.168.B.254, ĉar ĝi estas en la sama reto kun sia interfaco 192.168.B.2/24;

18) la enkursigilo ricevas ĉi tiun pakaĵon. Oni devas rimarki, ke li memoras pri kio li ricevis BBB1:11111 pako de AAA1 kaj ŝanĝis la adreson kaj havenon de sia ricevanto al 192.168.B.2:3389, do, la pako de 192.168.B.2:3389 por AAA1:44444 ĝi ŝanĝas la sendandreson al BBB1:11111;

19) la enkursigilo decidas al kiu sendi ĉi tiun pakaĵon. Li sendas ĝin al, diru, BBB254 (ISP-enirejo, kies precizan adreson ni ne scias), ĉar ne ekzistas pli specifaj itineroj al AAA1, ol 0.0.0.0/0, ĝi ne havas;

20) Interretaj provizantoj elsendas pakaĵon kun BBB1 sur AAA1;

21) virtuala enkursigilo ŝaltita AAA1 ricevas ĉi tiun paketon kaj memoras tion kiam li sendis la pakaĵeton de 192.168.A.1:55555 por BBB1:11111, li ŝanĝis sian adreson kaj sendindan havenon al AAA1:44444. Ĉi tio signifas, ke ĉi tiu estas la respondo al kiu devas esti sendita 192.168.A.1:55555 (fakte, kiel ni menciis en la antaŭa ekzemplo, estas ankaŭ pluraj pliaj ĉekoj, sed ĉi-foje ni ne profundigas ilin);

22) li komprenas, ke ĝi estu transdonita rekte al 192.168.A.1, ĉar li estas en la sama reto kun li, tio signifas, ke li havas respondan enskribon en la vojtabelo, kiu devigas lin sendi pakaĵojn al la tuta 192.168.A.0/24 rekte;

23) la enkursigilo trovas la MAC-adreson por 192.168.A.1 kaj donas al li ĉi tiun pakaĵon;

24) operaciumo sur la servilo kun la adreso 192.168.A.1 ricevas pakaĵon de BBB1:11111 por 192.168.A.1:55555 kaj iniciatas la sekvajn paŝojn por establi TCP-konekton.

Ĝuste same kiel en la antaŭa kazo, ĉi-kaze la servilo kun la adreso 192.168.A.1 scias nenion pri la komputilo kun la adreso 192.168.B.1, li nur komunikas kun BBB1. Komputilo kun adreso 192.168.B.1 ankaŭ scias nenion pri la servilo kun la adreso 192.168.A.1. Li kredas, ke li estis konektita de la adreso AAA1, kaj la cetero estas kaŝita de li.

konkludo

Jen kiel ĉio okazas por konektoj ene de la VPN-tunelo inter la oficejo de la kliento kaj la nuba medio, same kiel por konektoj ekster la VPN-tunelo. Kaj se vi havas demandojn aŭ bezonas nian helpon por solvi nubajn problemojn, kontaktu nin 24x7.

fonto: www.habr.com

Aldoni komenton