Access Server-gatewaybruger: routing af en klients filial-LAN

Du kan pinge en OpenVPN-klients tunneladresse og stadig ikke nå nogen vært på LAN'et bag den. Access Server giver klienten en adresse fra VPN-puljen, og puljeadressen er alt, hvad serveren ved, den ejer. Filialpræfikset er et særskilt faktum, der skal erklæres, og selv da har filialen brug for en videresender og hovedkontoret for en returvej. En rute skrevet det forkerte sted ser ud som en løsning og ændrer intet.

To adresser, to forskellige ejerskabskrav

Når en klient forbinder, tildeler Access Server den en adresse fra den konfigurerede VPN-pulje, for eksempel 10.90.0.0/24. Tildelingen er en leje til én vært. Intet i forbindelsen siger, at samme klient også står foran 10.60.0.0/24, og serveren gætter ikke: et LAN-præfiks er kun tilgængeligt gennem en bestemt klient, hvis en administrator erklærer det.

Derfor virker en statisk rute på en anden maskine ikke. Ruten siger send 10.60.0.0/24 til denne adresse, men hvis adressen tilhører en klient, der aldrig blev markeret som gateway, har serveren ingen grund til at levere pakkerne dertil, og klientens egen stak kan kaste dem væk. Erklæringen og ruten er to halvdele af samme mekanisme.

Hvad gateway-indstillingen faktisk installerer

I Admin Web UI er erklæringen en brugeregenskab: slå Configure VPN gateway til på connector-brugeren, og indtast det rigtige filialpræfiks i Network on the VPN client side. Brugeren godkendes som enhver anden, så den kræver en legitimationspolitik, der passer til en enhed uden opsyn, og dens auto-login-profil er en hemmelighed, ikke en bekvemmelighedsfil.

Bag afkrydsningsfeltet behandler serveren præfikset som tilgængeligt gennem klientens puljeadresse, og routing-konfigurationen under Access Controls afgør, hvad andre klienter får at vide: ruterne, der push'es til almindelige klienter, og adgangsreglerne, der tillader trafik fra hovedkontorets netværk til klientadresser og klientsubnet. Slå routing til for de netværk, der skal nå filialen, og hold den tilladte liste kort.

Et Community-lignende direktiv indsat i en genereret fil deltager ikke i denne model. Produktet ejer den routing-tabel, det push'er; en håndredigeret linje overskrives ved næste generering eller ignoreres.

Fuldfør begge netværks returveje

En konkret plan: hovedkontor 10.40.0.0/24, filial 10.60.0.0/24, VPN-pulje 10.90.0.0/24, og Access Server tilgængelig på en privat adresse på hovedkontorets side. Hovedkontorets router skal have ruter til filialpræfikset og til puljen, begge pegende på Access Server. Uden dem bærer tunnelen anmodningen, og svaret forlader via standardgatewayen, hvilket giver den klassiske halvåbne forbindelse.

I filialen skal connectoren videresende pakker, der ikke er adresseret til den selv: IP forwarding i dens styresystem plus en videresendelsestilladelse begrænset til tunnel- og LAN-interfaces; på Linux er det net.ipv4.ip_forward=1 sammen med forward-kædereglene, på Windows er det routing and remote access. Filialens værter skal derefter have en returvej: enten er connectoren deres standardgateway, eller den eksisterende gateway bærer specifikke ruter til hovedkontorets og puljens præfikser.

Connector'ens egen routing-tabel omkonfigurerer ikke hver vært på filialens LAN. Hvis værterne peger på en anden router, hører returruterne til der, og den skal acceptere, at kildeadressen, den ser, ikke er en nabo på det lokale subnet.

Læs en fejl som en vej, ikke som en tilladelse

Test i fast rækkefølge. Først en tilladt tjeneste fra Access Server til en vært i filialen, derefter samme tjeneste fra en almindelig vært i hovedkontoret, derefter den modsatte retning hvis politikken tillader det. Hvis den første består og den anden fejler, er det de push'ede ruter eller adgangsreglerne. Hvis begge består, men svar aldrig kommer, skal du undersøge videresendelsen i filialen og returvejen i hovedkontoret.

Værtens firewall er den næste mistænkte, for med routed adgang ser destinationen en hovedkontor- eller puljeadresse som kilde. En regel skrevet til det lokale subnet matcher ikke, og pakken kasseres, efter at routing'en fungerede perfekt.

To designs kræver mere end dette mønster. Overlappende præfikser mellem lokaliteter gør destinationen tvetydig og kræver omnummerering eller oversættelse, og en klynget Access Server kræver, at hver node har en fungerende vej til filialens connector, ikke én node der holder ruten. Anvend ændringer via produktets normale gem- og opdateringsvej, genopret connector-forbindelsen, og verificér igen fra begge ender; en fuld genstart af hver maskine er ikke en del af proceduren.

Access Server site-to-site-vejledningen lister de samme indstillinger i produktets rækkefølge; den er værd at følge én gang, før du tilpasser designet til dine egne præfikser.