Gateway-uzanto de Access Server: enkursigi la filian LAN de kliento

Vi povas pingi la tunelan adreson de OpenVPN-kliento kaj tamen ne atingi iun ajn gastiganton en la LAN malantaŭ ĝi. Access Server donas al tiu kliento adreson el la VPN-pool, kaj la pool-adreso estas ĉio, kion la servilo scias posedi. La filia prefikso estas aparta fakto, kiun oni devas deklari, kaj eĉ tiam la filio bezonas plusendilon kaj la ĉefsidejo revenan vojon. Itinero tajpita en la malĝustan lokon aspektas kiel solvo kaj ŝanĝas nenion.

Du adresoj, du malsamaj posedpretendoj

Kiam kliento konektiĝas, Access Server atribuas al ĝi adreson el la agordita VPN-pool, ekzemple 10.90.0.0/24. Tiu atribuo estas luo por unu gastiganto. Nenio en la konekto diras, ke la sama kliento ankaŭ staras antaŭ 10.60.0.0/24, kaj la servilo ne divenos: LAN-prefikso estas atingebla tra certa kliento nur se administranto deklaras ĝin.

Tial statika itinero sur alia maŝino ne helpas. La itinero diras sendu 10.60.0.0/24 al ĉi tiu adreso, sed se la adreso apartenas al kliento neniam markita kiel gateway, la servilo havas neniun kialon liveri tiujn pakaĵojn tien, kaj la stako de la kliento povas forĵeti ilin. La deklaro kaj la itinero estas du duonoj de unu mekanismo.

Kion la gateway-agordo efektive instalas

En la Admin Web UI la deklaro estas uzanta eco: ŝaltu Configure VPN gateway ĉe la konektila uzanto kaj entajpu la veran filian prefikson en Network on the VPN client side. Tiu uzanto aŭtentikiĝas kiel ĉiu alia, do ĝi bezonas akreditilan politikon taŭgan por senprizorga aparato, kaj ĝia aŭtomata ensaluta profilo estas sekreto, ne komforta dosiero.

Malantaŭ tiu markobutono la servilo traktas la prefikson kiel atingeblan tra la pool-adreso de tiu kliento, kaj la enkursiga agordo sub Access Controls decidas kion oni diras al la aliaj klientoj: la itineroj plusendataj al ordinaraj klientoj kaj la alirreguloj permesantaj trafikon de la retoj de la ĉefsidejo al klientaj adresoj kaj subretoj. Ŝaltu enkursigon por la retoj, kiuj devas atingi la filion, kaj tenu la permesatan liston mallonga.

Community-stila direktivo algluita en generitan dosieron ne partoprenas en ĉi tiu modelo. La produkto posedas la enkursigan tabelon, kiun ĝi plusendas; mane redaktita linio estas superskribata ĉe la sekva generado aŭ ignorata.

Kompletigu la revenajn vojojn de ambaŭ retoj

Konkreta plano: ĉefsidejo 10.40.0.0/24, filio 10.60.0.0/24, VPN-pool 10.90.0.0/24, kaj Access Server atingebla per privata adreso ĉe la flanko de la ĉefsidejo. La enkursigilo de la ĉefsidejo bezonas itinerojn por la filia prefikso kaj por la pool, ambaŭ al Access Server. Sen ili la tunelo portas la peton kaj la respondo eliras per la implicita gateway, kio donas la klasikan duonmalfermitan konekton.

En la filio la konektilo devas plusendi pakaĵojn ne adresitajn al ĝi mem: IP-plusendado en ĝia operaciumo plus plusenda permeso limigita al la tunelaj kaj LAN-interfacoj; en Linux tio estas net.ipv4.ip_forward=1 kune kun la reguloj de la forward-ĉeno, en Windows temas pri routing and remote access. Poste la gastigantoj de la filio bezonas revenan vojon: aŭ la konektilo estas ilia implicita gateway, aŭ la ekzistanta gateway portas specifajn itinerojn por la prefiksoj de la ĉefsidejo kaj de la pool.

La propra enkursiga tabelo de la konektilo ne reagordas ĉiun gastiganton en la filia LAN. Se la gastigantoj montras al alia enkursigilo, la revenaj itineroj apartenas tien, kaj ĝi devas akcepti, ke la fonta adreso, kiun ĝi vidas, ne estas najbaro en la loka subreto.

Legu fiaskon kiel vojon, ne kiel permeson

Testu en fiksa ordo. Unue permesata servo de Access Server al filia gastiganto, poste la sama servo de ordinara ĉefsideja gastiganto, poste la kontraŭa direkto se la politiko permesas. Se la unua pasas kaj la dua fiaskas, la plusenditaj itineroj aŭ la alirreguloj estas la problemo. Se ambaŭ pasas sed respondoj neniam alvenas, ekzamenu la plusendadon en la filio kaj la revenan itinero en la ĉefsidejo.

La gastiganta fajroŝirmilo estas la sekva suspektito, ĉar kun enkursigita aliro la celo vidas ĉefsidejan aŭ pool-adreson kiel fonton. Regulo skribita por la loka subreto ne kongruos, kaj la pakaĵo estas forĵetata post kiam la enkursigado perfekte funkciis.

Du dezajnoj bezonas pli ol ĉi tiu ŝablono. Interkovrantaj prefiksoj inter ejoj igas la celon ambigua kaj postulas renumeradon aŭ tradukadon, kaj kunigita Access Server bezonas laborantan vojon de ĉiu nodo al la filia konektilo, ne unu nodon tenantan la itinero. Apliku ŝanĝojn per la normala konservo kaj ĝisdatigo, rekonnectu la konektilon, kaj kontrolu denove de ambaŭ finoj; plena restartigo de ĉiu maŝino ne estas parto de la procedo.

La lernilo pri site-to-site de Access Server listigas la samajn agordojn en produkta ordo; indas sekvi ĝin unufoje antaŭ ol adapti la dezajnon al viaj propraj prefiksoj.