Access Serverin yhdyskäytäväkäyttäjä: asiakkaan sivukonttorin LANin reititys

Voit pingata OpenVPN-asiakkaan tunneliosoitetta ja silti olla pääsemättä yhteenkään isäntään sen takana olevassa LANissa. Access Server antaa asiakkaalle osoitteen VPN-poolista, ja poolin osoite on kaikki, minkä palvelin tietää omistavansa. Sivukonttorin etuliite on erillinen tosiasia, joka täytyy ilmoittaa, ja silloinkin sivukonttori tarvitsee välittäjän ja pääkonttori paluureitin. Väärään paikkaan kirjoitettu reitti näyttää ratkaisulta eikä muuta mitään.

Kaksi osoitetta, kaksi erilaista omistusvaatimusta

Kun asiakas yhdistää, Access Server antaa sille osoitteen määritetystä VPN-poolista, esimerkiksi 10.90.0.0/24. Tämä osoitus on vuokra yhdelle isännälle. Yhteydessä ei sanota, että sama asiakas seisoo myös 10.60.0.0/24-osoitteen edessä, eikä palvelin arvaa: LAN-etuliite on tavoitettavissa tietyn asiakkaan kautta vain, jos ylläpitäjä ilmoittaa sen.

Siksi staattinen reitti toisella koneella ei auta. Reitti sanoo lähetä 10.60.0.0/24 tähän osoitteeseen, mutta jos osoite kuuluu asiakkaalle, jota ei koskaan merkitty yhdyskäytäväksi, palvelimella ei ole syytä toimittaa paketteja sinne, ja asiakkaan oma pino voi pudottaa ne. Ilmoitus ja reitti ovat yhden mekanismin kaksi puoliskoa.

Mitä yhdyskäytäväasetus todella asentaa

Admin Web UI:ssa ilmoitus on käyttäjän ominaisuus: ota Configure VPN gateway käyttöön liittimen käyttäjällä ja syötä sivukonttorin todellinen etuliite kohtaan Network on the VPN client side. Tämä käyttäjä todennetaan kuten mikä tahansa muu, joten se tarvitsee valvomattomaan laitteeseen sopivan tunnistetietokäytännön, ja sen automaattisen kirjautumisen profiili on salaisuus, ei mukavuustiedosto.

Valintaruudun takana palvelin pitää etuliitettä tavoitettavana kyseisen asiakkaan pooliosoitteen kautta, ja Access Controlsin alla oleva reititysmääritys päättää, mitä muille asiakkaille kerrotaan: tavallisille asiakkaille työnnetyt reitit ja pääsykäytännöt, jotka sallivat liikenteen pääkonttorin verkoista asiakkaiden osoitteisiin ja aliverkkoihin. Ota reititys käyttöön verkoille, joiden on päästävä sivukonttoriin, ja pidä sallittu luettelo lyhyenä.

Generoituun tiedostoon liitetty Community-tyylinen direktiivi ei osallistu tähän malliin. Tuote omistaa työntämänsä reititystaulukon; käsin muokattu rivi ylikirjoitetaan seuraavassa generoinnissa tai jätetään huomiotta.

Viimeistele molempien verkkojen paluureitit

Konkreettinen suunnitelma: pääkonttori 10.40.0.0/24, sivukonttori 10.60.0.0/24, VPN-pooli 10.90.0.0/24 ja Access Server tavoitettavissa yksityisestä osoitteesta pääkonttorin puolella. Pääkonttorin reitittimeen tarvitaan reitit sivukonttorin etuliitteelle ja poolille, molemmat Access Serveriin. Ilman niitä tunneli kuljettaa pyynnön ja vastaus lähtee oletusyhdyskäytävän kautta, mikä tuottaa klassisen puoliavoimen yhteyden.

Sivukonttorissa liittimen on välitettävä paketteja, joita ei ole osoitettu sille itselleen: IP-välitys käyttöjärjestelmässä sekä tunnelin ja LANin liitäntöihin rajattu välityslupa; Linuxissa se on net.ipv4.ip_forward=1 yhdessä forward-ketjun sääntöjen kanssa, Windowsissa routing and remote access. Sen jälkeen sivukonttorin isännät tarvitsevat paluureitin: joko liitin on niiden oletusyhdyskäytävä tai olemassa oleva yhdyskäytävä kuljettaa erityiset reitit pääkonttorin ja poolin etuliitteille.

Liittimen oma reititystaulukko ei määritä uudelleen jokaista isäntää sivukonttorin LANissa. Jos isännät osoittavat toiseen reitittimeen, paluureitit kuuluvat sinne, ja sen on hyväksyttävä, että nähty lähdeosoite ei ole paikallisen aliverkon naapuri.

Lue epäonnistuminen polkuna, ei lupana

Testaa kiinteässä järjestyksessä. Ensin sallittu palvelu Access Serveristä sivukonttorin isäntään, sitten sama palvelu tavallisesta pääkonttorin isännästä, sitten vastakkaiseen suuntaan jos käytäntö sallii. Jos ensimmäinen menee läpi ja toinen epäonnistuu, ongelma on työnnetyissä reiteissä tai pääsykäytännöissä. Jos molemmat menevät läpi mutta vastauksia ei tule, tutki välitystä sivukonttorissa ja paluureittiä pääkonttorissa.

Isännän palomuuri on seuraava epäilty, koska reititetyssä pääsyssä kohde näkee lähteenä pääkonttorin tai poolin osoitteen. Paikalliselle aliverkolle kirjoitettu sääntö ei täsmää, ja paketti pudotetaan sen jälkeen kun reititys toimi moitteettomasti.

Kaksi suunnittelua tarvitsevat enemmän. Päällekkäiset etuliitteet toimipaikkojen välillä tekevät kohteesta monitulkintaisen ja vaativat uudelleennumeroinnin tai käännöksen, ja klusteroitu Access Server tarvitsee jokaiselle solmulle toimivan polun sivukonttorin liittimeen, ei yhtä solmua, joka pitää reittiä. Tee muutokset tuotteen tavallista tallennus- ja päivityspolkua pitkin, yhdistä liitin uudelleen ja varmista molemmista päistä; jokaisen koneen täydellinen uudelleenkäynnistys ei kuulu menettelyyn.

Access Serverin site-to-site-opas luettelee samat asetukset tuotteen järjestyksessä; se kannattaa seurata kerran ennen kuin sovitat suunnitelman omiin etuliitteisiisi.