Access Server-gatewaygebruiker: die tak-LAN van n kliënt roeteer

Jy kan n OpenVPN-kliënt se tonneladres ping en steeds geen gasheer op die LAN agter dit bereik nie. Access Server gee daardie kliënt n adres uit die VPN-poel, en die poeladres is al wat die bediener weet hy besit. Die takvoorvoegsel is n aparte feit wat verklaar moet word, en selfs dan het die tak n aanstuurder en die hoofkantoor n terugpad nodig. n Roete op die verkeerde plek lyk soos n oplossing en verander niks.

Twee adresse, twee eienaarskapsaansprake

Wanneer n kliënt verbind, ken Access Server n adres uit die gekonfigureerde VPN-poel toe, byvoorbeeld 10.90.0.0/24. Daardie toekenning is n huurkontrak vir een gasheer. Niks in die verbinding sê die kliënt sit ook voor 10.60.0.0/24 nie, en die bediener sal nie raai nie: n LAN-voorvoegsel is slegs deur n spesifieke kliënt bereikbaar as n administrateur dit verklaar.

Daarom werk n statiese roete op n ander masjien nie. Die roete sê stuur 10.60.0.0/24 na hierdie adres, maar as die adres aan n kliënt behoort wat nooit as gateway gemerk is nie, het die bediener geen rede om daardie pakkette daar af te lewer nie, en die kliënt se eie stapel kan dit laat val. Die verklaring en die roete is twee helftes van een meganisme.

Wat die gateway-instelling werklik installeer

In die Admin Web UI is die verklaring n gebruiker-eienskap: aktiveer Configure VPN gateway op die verbinder-gebruiker en voer die werklike takvoorvoegsel in by Network on the VPN client side. Daardie gebruiker verifieer soos enige ander, dus het dit n geloofwaardigheidsbeleid nodig wat by n onbemande toestel pas, en sy outo-aanmeldprofiel is n geheim, nie n geriefslêer nie.

Agter daardie merkblokkie behandel die bediener die voorvoegsel as bereikbaar deur daardie kliënt se poeladres, en die roetekonfigurasie onder Access Controls bepaal wat ander kliënte meegedeel word: die roetes wat aan gewone kliënte gestuur word en die toegangsreëls wat verkeer van hoofkantoornetwerke na kliëntadresse en kliëntsubnette toelaat. Aktiveer roetering vir die netwerke wat die tak moet bereik, en hou die toegelate lys kort.

n Opdrag in Community-styl wat in n gegenereerde lêer geplak word, neem nie aan hierdie model deel nie. Die produk besit die roetetabel wat hy stuur; n handmatig geredigeerde reël word by die volgende regenerasie oorgeskryf of deur die betrokke komponente geïgnoreer.

Voltooi albei netwerke se terugpaaie

n Konkrete plan: hoofkantoor 10.40.0.0/24, tak 10.60.0.0/24, VPN-poel 10.90.0.0/24, en Access Server bereikbaar by n private adres aan die hoofkantoor se kant. Die hoofkantoor se roeteerder het roetes vir die takvoorvoegsel en die poel nodig, albei na Access Server. Sonder hulle dra die tonnel die versoek en verlaat die antwoord via die verstekpoort, wat die klassieke halfoop verbinding gee.

By die tak moet die verbinder pakkette aanstuur wat nie aan homself gerig is nie: IP-aansturing in sy bedryfstelsel plus n aansturingspermissie beperk tot die tonnel- en LAN-koppelvlakke; op Linux is dit net.ipv4.ip_forward=1 saam met die forward chain-reëls, op Windows is dit roetering en remote access. Tak-gashere het dan n terugpad nodig: óf die verbinder is hul verstekpoort, óf die bestaande poort dra spesifieke roetes vir die hoofkantoor- en poelvoorvoegsels.

Die verbinder se eie roetetabel herkonfigureer nie elke gasheer op die tak-LAN nie. As die gashere na n ander roeteerder wys, hoort die terugroetes daar, en daardie roeteerder moet aanvaar dat die bronadres wat hy sien nie n buur op die plaaslike subnet is nie.

Lees n fout as n pad, nie as n toestemming nie

Toets in n vaste orde. Eers n toegelate diens van Access Server na n tak-gasheer, dan dieselfde diens van n gewone hoofkantoor-gasheer, dan die omgekeerde rigting as die beleid dit toelaat. As die eerste slaag en die tweede misluk, is die gestuurde roetes of die toegangsreëls die probleem. As albei slaag maar antwoorde nooit opdaag nie, ondersoek aansturing by die tak en die terugroete aan die hoofkantoor se kant.

n Gasheer-firewall is die volgende verdagte, want met geroteerde toegang sien die bestemming n hoofkantoor- of poeladres as die bron. n Reël wat vir die plaaslike subnet geskryf is, pas nie, en die pakket word laat val nadat die roetering perfek gewerk het.

Twee ontwerpe het meer as hierdie patroon nodig. Oorvleuelende voorvoegsels tussen terreine maak die bestemming dubbelsinnig en vereis hernommering of vertaling, en n gegroepeerde Access Server vereis dat elke nodus n werkende pad na die takverbinder het, nie een nodus wat die roete hou nie. Pas veranderinge deur die produk se normale stoor- en opdateerpad toe, verbind die verbinder weer, en verifieer weer van beide kante; n volledige herbegin van elke masjien is nie deel van die prosedure nie.

Die Access Server site-to-site-tutoriaal lys dieselfde instellings in produkorde, wat die moeite werd is om een keer te volg voordat jy die ontwerp by jou eie voorvoegsels aanpas.