Access Server-gatewaybrûker: it filiaal-LAN fan in klient rûte

Jo kinne it tunneladres fan in OpenVPN-klient pingje en dochs gjin host berikke op it LAN dêrefter. Access Server jout dy klient in adres út 'e VPN-pool, en it pooladres is alles wat de server as syn eigendom ken. It filiaalprefiks is in apart feit dat ferklearre wurde moat, en sels dan hat it filiaal in trochstjoerder nedich en it haadkantoar in weromrûte. In rûte op 'e ferkearde plak liket in oplossing en feroaret neat.

Twa adressen, twa ferskillende eigendomsbewearingen

As in klient ferbynt, jout Access Server him in adres út 'e konfigurearre VPN-pool, bygelyks 10.90.0.0/24. Dy tawizing is in hier foar ien host. Neat yn 'e ferbining seit dat deselde klient ek foar 10.60.0.0/24 stiet, en de server sil net riede: in LAN-prefiks is allinnich fia in bepaald klient berikber as in behearder it ferklearret.

Dêrom helpt in statyske rûte op in oare masine net. De rûte seit stjoer 10.60.0.0/24 nei dit adres, mar as it adres fan in klient is dy't nea as gateway markearre waard, hat de server gjin reden om dy pakketten dêr te besoargjen, en de stâl fan 'e klient kin se weilizze. De ferklearring en de rûte binne twa helten fan ien meganisme.

Wat de gateway-ynstelling werklik ynstallearret

Yn 'e Admin Web UI is de ferklearring in brûkerskaaimerk: skeakelje Configure VPN gateway oan by de connector-brûker en fier it echte filiaalprefiks yn by Network on the VPN client side. Dy brûker wurdt lykas elkenien oare ferifiearre, dus hat er in oanmeldbelied nedich dat by in apparaat sûnder tafersjoch past, en syn auto-login-profyl is in geheim, gjin gemaksbestân.

Efter dat fek behannelt de server it prefiks as berikber fia it pooladres fan dy klient, en de rûtekonfiguraasje ûnder Access Controls beslút wat oare klienten te hearren krije: de rûtes dy't nei gewoane klienten stjoerd wurde en de tagongsregels dy't ferkear fan 'e netwurken fan it haadkantoar nei klientadressen en subnetten tastean. Skeakelje rûtering oan foar de netwurken dy't it filiaal berikke moatte, en hâld de tastiene list koart.

In direktive yn Community-styl dy't yn in generearre bestân plakt wurdt, docht net mei oan dit model. It produkt hat de rûtetabel dy't it stjoert; in mei de hân bewurke rigel wurdt by de folgjende generaasje oerskreaun of negearre.

Meitsje beide weromrûtes fan 'e netwurken klear

In konkreet plan: haadkantoar 10.40.0.0/24, filiaal 10.60.0.0/24, VPN-pool 10.90.0.0/24, en Access Server berikber op in privee adres oan 'e kant fan it haadkantoar. De router fan it haadkantoar hat rûtes nedich foar it filiaalprefiks en foar de pool, beide nei Access Server. Sûnder dy draacht de tunnel it fersyk en giet it antwurd fuort fia de standertgateway, wat de klassike healiepen ferbining jout.

Yn it filiaal moat de connector pakketten trochstjoere dy't net oan himsels rjochte binne: IP-trochstjoering yn syn bestjoeringssysteem plus in trochstjoeringsfergunning beheind ta de tunnel- en LAN-ynterfaces; op Linux is dat net.ipv4.ip_forward=1 mei de regels fan 'e forward-ketting, op Windows is dat routing and remote access. Dêrnei hawwe de hosts yn it filiaal in weromrûte nedich: of de connector is harren standertgateway, of de besteande gateway draacht spesifike rûtes foar de prefiksen fan it haadkantoar en de pool.

De eigen rûtetabel fan 'e connector konfigurearret net elke host op it filiaal-LAN opnij. As de hosts nei in oare router wize, hearre de weromrûtes dêre, en dy moat akseptearje dat it boarneadres dat er sjocht gjin buorman op it lokale subnet is.

Lês in mislearring as in paad, net as in tastimming

Test yn in fêste oarder. Earst in tastiene tsjinst fan Access Server nei in host yn it filiaal, dêrnei deselde tsjinst fan in gewoane host fan it haadkantoar, dêrnei de oare kant as it belied it tastiet. As de earste slagget en de twadde mislearret, binne de stjoerde rûtes of de tagongsregels it probleem. As beide slagje mar der komme gjin antwurden, ûndersykje dan de trochstjoering yn it filiaal en de weromrûte by it haadkantoar.

De host-firewall is de folgjende fertochte, want by rûte tagong sjocht it doel in adres fan it haadkantoar of fan 'e pool as boarne. In regel skreaun foar it lokale subnet sil net passe, en it pakket wurdt weilizze neidat de rûtering perfekt wurke hat.

Twa ûntwerpen freegje mear. Oerlaapjende prefiksen tusken lokaasjes meitsje it doel dûbelsinnich en freegje nûmering opnij of oersetting, en in klusterjend Access Server freget dat elke knoop in wurkjend paad nei de filiaalconnector hat, net ien knoop dy't de rûte hâldt. Pas feroarings ta fia it normale bewarje- en bywurkpaad, ferbyn de connector opnij en ferifiearje fan beide kanten; in folsleine werstart fan elke masine is gjin part fan 'e proseduere.

De site-to-site-tutorial fan Access Server listet deselde ynstellings yn produktfolchoarder; it is de muoite wurdich om dy ien kear te folgjen foardat jo it ûntwerp oan jo eigen prefiksen oanpasse.