Gateway-bruker i Access Server: ruting av en klients filial-LAN

Du kan pinge en OpenVPN-klients tunneladresse og likevel ikke nå noen vert på LAN-et bak den. Access Server gir klienten en adresse fra VPN-poolen, og pooladressen er alt serveren vet den eier. Filialprefikset er et eget faktum som må deklareres, og selv da trenger filialen en videresender og hovedkontoret en returvei. En rute skrevet på feil sted ser ut som en løsning og endrer ingenting.

To adresser, to ulike eierkrav

Når en klient kobler til, tildeler Access Server den en adresse fra den konfigurerte VPN-poolen, for eksempel 10.90.0.0/24. Tildelingen er en leie for én vert. Ingenting i forbindelsen sier at samme klient også står foran 10.60.0.0/24, og serveren gjetter ikke: et LAN-prefiks er bare tilgjengelig gjennom en bestemt klient hvis en administrator deklarerer det.

Derfor virker ikke en statisk rute på en annen maskin. Ruten sier send 10.60.0.0/24 til denne adressen, men hvis adressen tilhører en klient som aldri ble merket som gateway, har serveren ingen grunn til å levere pakkene dit, og klientens stack kan forkaste dem. Deklarasjonen og ruten er to halvdeler av samme mekanisme.

Hva gateway-innstillingen faktisk installerer

I Admin Web UI er deklarasjonen en brukeregenskap: slå på Configure VPN gateway på connector-brukeren og skriv inn det ekte filialprefikset i Network on the VPN client side. Brukeren autentiseres som alle andre, så den trenger en legitimasjonspolicy som passer for en enhet uten tilsyn, og auto-innloggingsprofilen er en hemmelighet.

Bak avkrysningsboksen behandler serveren prefikset som tilgjengelig gjennom klientens pooladresse, og rutingkonfigurasjonen under Access Controls avgjør hva andre klienter får vite: rutene som sendes til vanlige klienter og tilgangsreglene som tillater trafikk fra hovedkontorets nett til klientadresser og subnett. Slå på ruting for nettene som skal nå filialen, og hold den tillatte listen kort.

Et Community-lignende direktiv limt inn i en generert fil deltar ikke i denne modellen. Produktet eier rutetabellen det sender; en håndredigert linje overskrives eller ignoreres.

Fullfør begge nettenes returveier

En konkret plan: hovedkontor 10.40.0.0/24, filial 10.60.0.0/24, VPN-pool 10.90.0.0/24, og Access Server tilgjengelig på en privat adresse på hovedkontorets side. Hovedkontorets ruter trenger ruter for filialprefikset og for poolen, begge mot Access Server. Uten dem bærer tunnelen forespørselen, og svaret går ut via standardgatewayen, som gir den klassiske halvåpne forbindelsen.

I filialen må connectoren videresende pakker som ikke er adressert til den selv: IP-videresending i operativsystemet pluss en videresendingstillatelse begrenset til tunnel- og LAN-grensesnitt; på Linux er det net.ipv4.ip_forward=1 sammen med forward-kjedereglene, på Windows er det routing and remote access. Deretter trenger filialens verter en returvei: enten er connectoren deres standardgateway, eller den eksisterende gatewayen bærer spesifikke ruter for hovedkontorets og poolens prefikser.

Connector-ens egen rutetabell omkonfigurerer ikke hver vert på filialens LAN. Hvis vertene peker på en annen ruter, hører returrutene til der, og den må godta at kildeadressen den ser ikke er en nabo på det lokale subnettet.

Les en feil som en vei, ikke som en tillatelse

Test i fast rekkefølge. Først en tillatt tjeneste fra Access Server til en vert i filialen, deretter samme tjeneste fra en vanlig vert i hovedkontoret, deretter motsatt vei hvis policyen tillater det. Hvis den første passerer og den andre feiler, er det de sendte rutene eller tilgangsreglene. Hvis begge passerer men ingen svar kommer, undersøk videresendingen i filialen og returveien i hovedkontoret.

Vertens brannmur er den neste mistenkte, fordi målet med rutet tilgang ser en hovedkontor- eller pooladresse som kilde. En regel skrevet for det lokale subnettet vil ikke stemme, og pakken forkastes.

To design trenger mer. Overlappende prefikser mellom steder gjør målet tvetydig og krever omnummerering eller oversettelse, og en klynget Access Server krever at hver node har en fungerende vei til filialens connector, ikke én node som holder ruten. Bruk endringer via produktets vanlige lagre- og oppdateringsvei, koble connectoren til på nytt og verifiser fra begge ender; full omstart av hver maskin er ikke en del av prosedyren.

Access Server site-to-site-veiledningen lister de samme innstillingene i produktrekkefølge; det er verdt å følge den én gang før du tilpasser designet til egne prefikser.