Gumagamit ng gateway sa Access Server: pag-route ng LAN ng sangay ng kliyente

Maaari mong i-ping ang tunnel address ng kliyenteng OpenVPN at hindi pa rin maabot ang anumang host sa LAN sa likod nito. Nagbibigay ang Access Server ng address mula sa VPN pool, at ang address ng pool ang tanging bagay na alam ng server na pag-aari nito. Ang prefix ng sangay ay hiwalay na katotohanang dapat ideklara, at kahit noon kailangan ng sangay ng tagapagpasa at ng punong tanggapan ng pabalik na ruta. Ang rutang naisulat sa maling lugar ay hindi nagbabago ng anuman.

Dalawang address, dalawang pag-angkin

Kapag kumonekta ang kliyente, nagbibigay ang Access Server ng address mula sa naka-configure na pool, halimbawa 10.90.0.0/24. Ang paglalaang iyon ay upa para sa isang host. Wala sa koneksyon ang nagsasabing ang parehong kliyente ay nasa harap din ng 10.60.0.0/24, at hindi manghuhula ang server: ang LAN prefix ay maaabot sa pamamagitan ng partikular na kliyente lamang kung ideklara ito ng administrador.

Kaya hindi nakakatulong ang static na ruta sa ibang makina. Sinasabi ng ruta na ipadala ang 10.60.0.0/24 sa address na ito, ngunit kung ang address ay pag-aari ng kliyenteng hindi namarkahan bilang gateway, walang dahilan ang server na ihatid ang mga packet doon, at maaaring itapon ito ng stack ng kliyente. Ang deklarasyon at ruta ay dalawang kalahati ng isang mekanismo.

Ano ang ini-install ng gateway setting

Sa Admin Web UI ang deklarasyon ay katangian ng gumagamit: i-on ang Configure VPN gateway sa connector user at ilagay ang tunay na prefix sa Network on the VPN client side. Ang gumagamit na iyon ay nagpapatunay tulad ng iba, kaya kailangan niya ng patakarang angkop sa device na walang pagmamasid, at ang auto-login profile ay lihim.

Itinuturing ng server na naaabot ang prefix sa pamamagitan ng pool address ng kliyenteng iyon, at itinatakda ng routing sa Access Controls kung ano ang ipinapaalam sa iba: ang mga rutang ipinapadala sa ordinaryong kliyente at ang mga patakaran sa pag-access na nagpapahintulot ng trapiko mula sa mga network ng punong tanggapan. I-on ang routing para sa mga network na dapat makarating sa sangay at panatilihing maikli ang listahan.

Ang direktibang Community-style na idinikit sa generated na file ay hindi lumalahok sa modelong ito. Pag-aari ng produkto ang routing table na ipinapadala nito; ang linyang na-edit sa kamay ay pinapalitan o binabalewala.

Kumpletuhin ang pabalik na ruta ng dalawang network

Plano: punong tanggapan 10.40.0.0/24, sangay 10.60.0.0/24, VPN pool 10.90.0.0/24, at Access Server na maaabot sa pribadong address. Kailangan ng router ang mga ruta para sa prefix ng sangay at pool. Kung wala, lalabas ang sagot sa default gateway, na lumilikha ng kalahating bukas na koneksyon.

Sa sangay, kailangang ipasa ng connector ang mga packet na hindi para sa kanya: IP forwarding sa OS at limitadong pahintulot sa tunnel at LAN interfaces; sa Linux ito ay net.ipv4.ip_forward=1 kasama ang forward chain rules, sa Windows ay routing and remote access. Pagkatapos, kailangan ng mga host ng pabalik na ruta: connector ang default gateway nila, o ang umiiral na gateway ay may partikular na ruta.

Ang routing table ng connector ay hindi nagko-configure muli ng bawat host sa LAN. Kung ang mga host ay tumuturo sa ibang router, doon ang pabalik na ruta, at kailangan nitong tanggapin na ang source address na nakikita nito ay hindi kapitbahay sa lokal na subnet.

Basahin ang kabiguan bilang ruta

Subukan sa takdang pagkakasunod-sunod. Una ang pinapayagang serbisyo mula sa Access Server patungo sa host ng sangay, pagkatapos ang parehong serbisyo mula sa ordinaryong host ng punong tanggapan, pagkatapos ang kabaligtaran kung pinapayagan ng patakaran. Kung pumasa ang una at nabigo ang pangalawa, ang mga ipinadalang ruta o patakaran sa pag-access ang problema. Kung pumasa ang dalawa pero walang sagot, suriin ang pagpapasa sa sangay at ang pabalik na ruta.

Ang firewall ng host ang susunod na hinala, dahil sa naka-route na pag-access ang destinasyon ay nakakakita ng address ng punong tanggapan o pool bilang pinagmulan. Ang patakarang isinulat para sa lokal na subnet ay hindi tutugma.

Dalawang disenyo ang nangangailangan ng higit pa. Ang magkakapatong na prefix ay nagpapalabo sa destinasyon at nangangailangan ng muling pagbilang o pagsasalin, at ang clustered na Access Server ay nangangailangan ng gumaganang ruta sa bawat node patungo sa connector. Ipatupad ang mga pagbabago sa karaniwang paraan ng pag-save at pag-update, ikonekta muli ang connector at i-verify mula sa dalawang dulo.

Ang site-to-site tutorial ng Access Server ay naglilista ng parehong mga setting sa ayos ng produkto.