Når ein fjernaksessklient må fungere som ein filialgateway

Ein berbar PC som er kopla til ein VPN, kan nå hovudkontoret. Skrivaren og filtenaren på same skrivebord kan ikkje, fordi ingenting videresender pakkane deira inn i den tunnelen eller bringar svara tilbake. Å gjere klienten om til ein filialgateway er eit val om ruting og eigarskap før det er eit konfigurasjonsval. Protokollnamnet på eska svarar ikkje på om den rolla er støtta.

Kva protokolletiketten ikkje fortel deg

OpenVPN dokumenterer eit design frå stad til stad der ein kopling videresender eit heilt subnett, og Access Server implementerer det med ei gatewayrolle og eksplisitt ruting. Eit anna produkt marknadsført som SSL VPN kan berre tilby fjernbrukarfunksjonar, utan nokon støtta måte å annonsere eit nettverk bak klienten. Versjonen betyr òg noko, fordi ein funksjon i éi utgåve ikkje er eit løfte om ei anna. Les implementasjonen du faktisk køyrer, og handsam ei oppskrift skriven for eit anna produkt som eit hint, ikkje eit design.

Spørsmålet som må avgjerast først, er om VPN-eigaren støttar videresendingsrolla i det heile. Viss ikkje, gjer inga ruting på klientsida ho støtta.

Kontrakten har to sider: filial og hovudkontor

På filialsida eig éin vert videresending, filtrering og attoppretting. Han treng ein medviten veg frå kvar filialeining, og den ytre VPN-tilkoplinga må halde fram med å vere tilgjengeleg gjennom det underliggjande nettverket sjølv medan tunnelen er nede. På hovudkontoret si side må nokon definere filialsubnettet, godta identiteten til gatewayen og tillate bestemte ressursar. Ingen av halvdelane verkar åleine.

Returvegen er den delen som blir hoppa over. Ei tunneladresse for klienten annonserer ikkje subnettet bak henne, så rutarane på hovudkontoret treng ein rute som peikar på VPN-gatewayen for det prefikset.

I eit ruta design videresender konsentratoren pakkar for filialprefikset, og rutinga på det overordna LAN-et veit korleis svara skal sendast tilbake. I eit omsett design blir kjelda hovudkontoret ser skriven om, noko som kan fjerne behovet for éin returrute medan det skjuler kva filialmaskin som sende trafikken. Den avveginga høyrer heime i designdokumentet, fordi applikasjonsloggar og tilgangsreglar mistar identiteten per eining når omsetjinga kjem inn.

Ruta eller omsett: vel returvegen medvite

Vel ruta når identitet per eining og politikk per vert betyr noko, og du kan vedlikehalde returruta på kvar relevante ruter.

Vel omsett når du ikkje kan leggje til ruter, men kan godta at hovudkontoret ser éi kjeldeadresse. Blanda design finst og er vanskelegare å resonnere om, så skriv ned kva prefiks som er ruta og kva som er omsette. Stadfest deretter valet med eit opptak i begge endar i staden for å stole på tunnelstatusen.

Ein nyttig kontroll er asymmetrisk: be om ein ressurs frå ei filialeining, og stadfest deretter at svaret forlèt hovudkontoret mot filialprefikset. traceroute -n 10.60.4.20 frå ein vert på hovudkontoret viser om den vegen går gjennom VPN-gatewayen.

Driv det som infrastruktur, ikkje som ei innlogging

Bestem korleis gatewayen startar, autentiserer, oppdaterer og attopprettar når ingen er logga inn. Fornying av legitimasjon, multifaktoroppfordringar, søvnåtferd og kven som svarar når filialen mistar tilgang, blir alle operative spørsmål. Fleire personar som deler éin nettverksveg må ikkje arve personlege privilegium til gatewaybrukaren, så ressursautorisasjon, loggomfang og feilpolitikk treng ein namngjeven eigar. Å dele ein konto for å unngå registrering av kvar eining er ikkje eit design.

Samanlikn ordninga med ein støtta stadsgateway under dei same krava før du forpliktar deg. Gjenbruk av ein gammal stasjonær PC fjernar ikkje vedlikehalds- eller attopprettingsarbeid, og bruktprisen skildrar ikkje driftskostnaden.

Valider dei tiltenkte filialapplikasjonane, returtrafikken deira og ein avvist destinasjon under ein godkjend plan. Suksess ser ut som ein eigen nettverksteneste med ein namngjeven filialidentitet og ein eksplisitt politikk, ikkje eit klientvindauge som seier Tilkopla.