Access Server vārtejas lietotājs: klienta filiāles LAN maršrutēšana
Access Server klienta tuneļa adrese nav maršruts uz tā filiāli. Deklarējiet vārtejas lietotāju, pēc tam izlabojiet abus atgriešanās ceļus un pārsūtīšanu.
Varat pingot OpenVPN klienta tuneļa adresi un tomēr nesasniegt nevienu resursdatoru LAN tīklā aiz tās. Access Server piešķir klientam adresi no VPN pūla, un pūla adrese ir viss, ko serveris uzskata par savu. Filiāles prefikss ir atsevišķs fakts, kas jādeklarē, un arī tad filiālei vajag pārsūtītāju, bet galvenajam birojam – atgriešanās ceļu. Nepareizā vietā ierakstīts maršruts neko nemaina.
Divas adreses, divas atšķirīgas īpašumtiesību pretenzijas
Kad klients pievienojas, Access Server piešķir tam adresi no konfigurētā VPN pūla, piemēram, 10.90.0.0/24. Šis piešķīrums ir viena resursdatora noma. Savienojums nepasaka, ka tas pats klients stāv arī 10.60.0.0/24 priekšā, un serveris neizgudros: LAN prefikss ir sasniedzams caur konkrētu klientu tikai tad, ja administrators to deklarē.
Tāpēc statisks maršruts citā mašīnā nepalīdz. Maršruts saka sūti 10.60.0.0/24 uz šo adresi, bet, ja adrese pieder klientam, kas nekad nav atzīmēts kā vārteja, serverim nav iemesla piegādāt tur šīs paketes, un klienta steks var tās izmest. Deklarācija un maršruts ir viena mehānisma divas puses.
Ko vārtejas iestatījums patiešām instalē
Admin Web UI deklarācija ir lietotāja īpašība: ieslēdziet Configure VPN gateway savienotāja lietotājam un ievadiet īsto filiāles prefiksu laukā Network on the VPN client side. Šis lietotājs tiek autentificēts kā jebkurš cits, tāpēc tam vajag akreditācijas datu politiku, kas piemērota ierīcei bez uzraudzības, un tā automātiskās pieteikšanās profils ir noslēpums.
Aiz šīs izvēles rūtiņas serveris uzskata prefiksu par sasniedzamu caur šī klienta pūla adresi, un maršrutēšanas konfigurācija sadaļā Access Controls nosaka, ko paziņo citiem klientiem: maršrutus, kas nosūtīti parastiem klientiem, un piekļuves noteikumus, kas atļauj datplūsmu no galvenā biroja tīkliem uz klientu adresēm un apakštīkliem. Ieslēdziet maršrutēšanu tīkliem, kuriem jāsasniedz filiāle, un turiet atļauto sarakstu īsu.
Community stila direktīva, kas ielīmēta ģenerētā failā, šajā modelī nepiedalās. Produkts pārvalda maršrutēšanas tabulu, ko tas sūta; ar roku labota rinda tiek pārrakstīta vai ignorēta.
Pabeidziet abu tīklu atgriešanās ceļus
Konkrēts plāns: galvenais birojs 10.40.0.0/24, filiāle 10.60.0.0/24, VPN pūls 10.90.0.0/24, un Access Server sasniedzams privātā adresē galvenā biroja pusē. Galvenā biroja maršrutētājam vajag maršrutus filiāles prefiksam un pūlam, abus uz Access Server. Bez tiem tunelis nes pieprasījumu un atbilde iziet caur noklusējuma vārteju, kas rada pusatvērtu savienojumu.
Filiālē savienotājam jāpārsūta paketes, kas nav adresētas tam pašam: IP pārsūtīšana operētājsistēmā un pārsūtīšanas atļauja, kas ierobežota ar tuneļa un LAN saskarnēm; Linux tas ir net.ipv4.ip_forward=1 kopā ar forward ķēdes noteikumiem, Windows – routing and remote access. Pēc tam filiāles resursdatoriem vajag atgriešanās ceļu: vai nu savienotājs ir to noklusējuma vārteja, vai esošā vārteja nes konkrētus maršrutus galvenā biroja un pūla prefiksiem.
Paša savienotāja maršrutēšanas tabula nepārkonfigurē katru filiāles LAN resursdatoru. Ja resursdatori norāda uz citu maršrutētāju, atgriešanās maršruti pieder tur, un tam jāpieņem, ka redzamā avota adrese nav vietējā apakštīkla kaimiņš.
Lasiet kļūmi kā ceļu, nevis kā atļauju
Pārbaudiet noteiktā secībā. Vispirms atļauts pakalpojums no Access Server uz filiāles resursdatoru, pēc tam tas pats pakalpojums no parasta galvenā biroja resursdatora, pēc tam pretējais virziens, ja politika atļauj. Ja pirmais iztur un otrais neizdodas, vainojami nosūtītie maršruti vai piekļuves noteikumi. Ja abi iztur, bet atbildes nenāk, pārbaudiet pārsūtīšanu filiālē un atgriešanās maršrutu galvenajā birojā.
Nākamais aizdomās turamais ir resursdatora ugunsmūris, jo maršrutētas piekļuves gadījumā galamērķis redz galvenā biroja vai pūla adresi kā avotu. Vietējam apakštīklam rakstīts noteikums nesakritīs, un pakete tiek izmesta.
Diviem dizainiem vajag vairāk. Pārklājošies prefiksi starp vietām padara galamērķi neviennozīmīgu un prasa pārnumurēšanu vai tulkošanu, un klasterēts Access Server prasa, lai katram mezglam būtu strādājošs ceļš uz filiāles savienotāju, nevis viens mezgls, kas tur maršrutu. Piemērojiet izmaiņas parastajā saglabāšanas un atjaunināšanas ceļā, pievienojiet savienotāju no jauna un pārbaudiet no abiem galiem; pilnīga katras mašīnas restartēšana nav procedūras daļa.
Access Server site-to-site apmācība uzskaita tos pašus iestatījumus produkta secībā; ir vērts to izsekot pirms dizaina pielāgošanas saviem prefiksiem.