Gateway-användare i Access Server: routa en klients filial-LAN

Du kan pinga tunneladressen för en OpenVPN-klient och ändå inte någon värd på LANet bakom den. Access Server ger klienten en adress från VPN-poolen, och pooladressen är allt servern vet att den äger. Filialprefixet är ett separat faktum som måste deklareras, och även då behöver filialen en vidarebefordrare och huvudkontoret en returväg. En rutt skriven på fel ställe ändrar ingenting.

Två adresser, två olika ägarkrav

När en klient ansluter tilldelar Access Server den en adress från den konfigurerade VPN-poolen, till exempel 10.90.0.0/24. Den tilldelningen är en leasing för en enda värd. Ingenting säger att samma klient också står framför 10.60.0.0/24, och servern gissar inte: ett LAN-prefix är bara nåbart via en viss klient om en administratör deklarerar det.

Därför hjälper inte en statisk rutt på en annan maskin. Rutten säger skicka 10.60.0.0/24 till den här adressen, men om adressen tillhör en klient som aldrig markerats som gateway har servern ingen anledning att leverera paketen dit, och klientens stack kan kasta dem. Deklarationen och rutten är två halvor av samma mekanism.

Vad gateway-inställningen installerar

I Admin Web UI är deklarationen en användaregenskap: aktivera Configure VPN gateway på connector-användaren och ange det verkliga filialprefixet i Network on the VPN client side. Användaren autentiseras som alla andra, så den behöver en policy som passar en enhet utan tillsyn, och dess autoinloggningsprofil är en hemlighet.

Bakom kryssrutan behandlar servern prefixet som nåbart via den klientens pooladress, och routingkonfigurationen under Access Controls avgör vad andra klienter får veta: rutterna till vanliga klienter och åtkomstreglerna som tillåter trafik från huvudkontorets nät till klientadresser och subnät. Aktivera routing för de nät som ska nå filialen och håll listan kort.

Ett Community-likt direktiv inklistrat i en genererad fil deltar inte i den här modellen. Produkten äger den routingtabell den skickar; en handredigerad rad skrivs över eller ignoreras.

Slutför båda nätens returvägar

En konkret plan: huvudkontor 10.40.0.0/24, filial 10.60.0.0/24, VPN-pool 10.90.0.0/24, och Access Server nåbar på en privat adress på huvudkontorets sida. Huvudkontorets router behöver rutter för filialprefixet och poolen. Utan dem bär tunneln begäran och svaret går ut via standardgatewayen, vilket ger den halvöppna anslutningen.

I filialen måste connectorn vidarebefordra paket som inte är adresserade till den: IP-vidarebefordran i operativsystemet plus en tillåtelse begränsad till tunnelns och LANets gränssnitt; på Linux är det net.ipv4.ip_forward=1 med forward-kedjans regler, på Windows routing and remote access. Sedan behöver filialens värdar en returväg: antingen är connectorn deras standardgateway, eller så bär den befintliga gatewayen specifika rutter.

Connectorns routingtabell konfigurerar inte om varje värd på filialens LAN. Om värdarna pekar på en annan router hör returrutterna dit, och den måste acceptera att källadressen den ser inte är en granne i det lokala subnätet.

Läs ett fel som en väg

Testa i fast ordning. Först en tillåten tjänst från Access Server till en värd i filialen, sedan samma tjänst från en vanlig värd på huvudkontoret, sedan motsatt riktning om policyn tillåter. Om den första går igenom och den andra misslyckas är det rutterna eller åtkomstreglerna. Om båda går igenom men inga svar kommer, undersök vidarebefordran i filialen och returvägen på huvudkontoret.

Värdens brandvägg är nästa misstanke, eftersom målet med routad åtkomst ser en huvudkontors- eller pooladress som källa. En regel för det lokala subnätet matchar inte och paketet kastas.

Två designer kräver mer. Överlappande prefix mellan platser gör målet tvetydigt och kräver omnumrering eller översättning, och en klustrad Access Server kräver att varje nod har en fungerande väg till filialens connector. Tillämpa ändringar via den vanliga spara- och uppdateringsvägen, återanslut connectorn och verifiera från båda hållen; full omstart av varje maskin ingår inte.

Access Servers site-to-site-handledning listar samma inställningar i produktordning; det är värt att följa den en gång.