Gateway-brukar i Access Server: ruting av filial-LAN-et til ein klient

Du kan pinge tunneladressa til ein OpenVPN-klient og likevel ikkje nå nokon vert på LAN-et bak han. Access Server gir klienten ei adresse frå VPN-poolen, og pooladressa er alt serveren veit han eig. Filialprefikset er eit eige faktum som må deklarerast, og sjølv då treng filialen ein videresendar og hovudkontoret ein returveg. Ei rute skriven på feil stad ser ut som ei løysing og endrar ingenting.

To adresser, to ulike eigarkrav

Når ein klient koplar til, tildeler Access Server han ei adresse frå den konfigurerte VPN-poolen, til dømes 10.90.0.0/24. Tildelinga er ein leige for éin vert. Ingenting i sambandet seier at same klient også står framfor 10.60.0.0/24, og serveren gissar ikkje: eit LAN-prefiks er berre tilgjengeleg gjennom ein bestemt klient om ein administrator deklarerer det.

Difor verkar ikkje ei statisk rute på ein annan maskin. Ruta seier send 10.60.0.0/24 til denne adressa, men om adressa høyrer til ein klient som aldri vart merkt som gateway, har serveren ingen grunn til å levere pakkane dit, og stakken til klienten kan kaste dei. Deklarasjonen og ruta er to halvdelar av same mekanisme.

Kva gateway-innstillinga faktisk installerer

I Admin Web UI er deklarasjonen ein brukareigenskap: slå på Configure VPN gateway på connector-brukaren og skriv inn det ekte filialprefikset i Network on the VPN client side. Brukaren autentiserer som alle andre, så han treng ein legitimasjonspolicy som passar for eit apparat utan tilsyn, og auto-innloggingsprofilen er ein løyndom.

Bak avkrysningsboksen handsamar serveren prefikset som tilgjengeleg gjennom pooladressa til klienten, og rutingkonfigurasjonen under Access Controls avgjer kva andre klientar får vite: rutene som blir sende til vanlege klientar og tilgangsreglane som lèt trafikk frå netta til hovudkontoret gå til klientadresser og subnett. Slå på ruting for netta som skal nå filialen, og hald den tillatne lista kort.

Eit Community-liknande direktiv lima inn i ei generert fil deltek ikkje i denne modellen. Produktet eig rutetabellen det sender; ei handredigert linje blir overstyrt eller ignorert.

Fullfør begge returvegane til netta

Ein konkret plan: hovudkontor 10.40.0.0/24, filial 10.60.0.0/24, VPN-pool 10.90.0.0/24, og Access Server tilgjengeleg på ei privat adresse på sida til hovudkontoret. Ruteren til hovudkontoret treng ruter for filialprefikset og for poolen, begge mot Access Server. Utan dei ber tunnelen førespurnaden, og svaret går ut via standardgatewayen, som gir den klassiske halvopne sambandet.

I filialen må connectoren videresende pakkar som ikkje er adresserte til han sjølv: IP-videresending i operativsystemet pluss ei videresendingstillating avgrensa til tunnel- og LAN-grensesnitt; på Linux er det net.ipv4.ip_forward=1 saman med forward-kjedereglane, på Windows er det routing and remote access. Deretter treng vertane i filialen ein returveg: anten er connectoren standardgatewayen deira, eller den eksisterande gatewayen ber spesifikke ruter for prefiksa til hovudkontoret og poolen.

Rutetabellen til connectoren omkonfigurerer ikkje kvar vert på filial-LAN-et. Om vertane peiker på ein annan ruter, høyrer returrutene til der, og den må godta at kjeldeadressa han ser ikkje er ein nabo i det lokale subnettet.

Les ein feil som ein veg, ikkje som eit løyve

Test i fast rekkjefølgje. Fyrst ei tillaten teneste frå Access Server til ein vert i filialen, deretter same teneste frå ein vanleg vert i hovudkontoret, deretter motsett veg om policyen tillèt det. Om den fyrste går gjennom og den andre feilar, er det dei sende rutene eller tilgangsreglane. Om begge går gjennom men ingen svar kjem, undersøk videresendinga i filialen og returvegen i hovudkontoret.

Brannmuren til verten er den neste mistenkte, fordi målet med ruta tilgang ser ei hovudkontor- eller pooladresse som kjelde. Ein regel skriven for det lokale subnettet vil ikkje stemme, og pakken blir kasta.

To design treng meir. Overlappande prefiks mellom stader gjer målet tvitydig og krev omnummerering eller omsetjing, og ein klynga Access Server krev at kvar node har ein fungerande veg til connectoren i filialen, ikkje éin node som held ruta. Bruk endringar via den vanlege lagre- og oppdateringsvegen, kople connectoren til på nytt og verifiser frå begge endar; full omstart av kvar maskin er ikkje del av prosedyren.

Site-to-site-veiledninga til Access Server listar dei same innstillingane i produktrekkjefølgje; det er verdt å følgje henne éin gong før du tilpassar designet til eigne prefiks.