Jou VPN-brûkers tagong ta ien tsjinst, net ta it subnet

In oannimmer hat ien ynterne webapplikaasje nedich en neat oars, en it maklike antwurd is om har in tunnel nei it tsjinner-subnet te jaan. Dat wurket oant de dei dat se it skanne. It smellere ûntwerp freget mear tinken, want berikberens, rûtebou en applikaasjebegunning binne trije aparte kontrôles dy't oerienkomme moatte.

Skriuw de eask as in tsjinst, net as in subnet

Begjin mei de bestimmingshost, it protokol en de poarte, en foegje dan de brûkers- of apparaatgroep ta dy't der komme moat. Nim de partikuliere DNS-sône allinnich op as de applikaasje in namme oplost, en nim in identiteitsprovider allinnich op as de oanmeldstream ien nedich hat. Al it oare is in ôfhinklikens dy't jo noch net rjochtfeardige hawwe.

In subnet is in ymplemintaasjedetail fan it netwurkteam, wylst in tsjinst is wat it bedriuw frege hat en de ienheid dy't besjoen en ôfdien wurde kin.

As de list fan ôfhinklikens boppe trije items groeit, hat de applikaasje wierskynlik syn eigen ûntwerppetear nedich.

Rûte smel, mar hanthavenje earne oars

In smelle rûte of selektor fertelt de tunnel hokker pakketten te dragen; it is gjin autorisaasjebelied. It gateway-filter, de firewall fan de bestimmingshost en it eigen begunningsmodel fan de applikaasje binne it plak dêr't tagong besletten wurdt. In rûte dy't ien adres beslacht is in goed begjin, en it is net de kontrôle dy't in besliste brûker tsjinhâldt. Krekt dy skieding lit jo it filter feroarje sûnder de tunnel opnij te ûntwerpen.

Oarsom kin in brede rûte mei in strang filter legitime wêze, mar allinnich as elkenien belutsen wit hokker fan de twa de hanthavening docht.

Dokumintearje it hanthaveningspunt eksplisyt, oars sil de folgjende feroaring it by ûngelok ferpleatse.

Kontrolearje de boarne dy't de tsjinst echt sjocht

It doel sjocht of it poeladres fan de klant of it adres fan de gateway, ôfhinklik fan oft jo oersette. Firewallregels en logboeken fan de host moatte oerienkomme mei de echte boarne. As ferskate brûkers in oersetten boarne diele, kin gjin regel per brûker op dy host se ûnderskiede, en dat is in ûntwerpbeheining, gjin bug.

Kies oersetting bewust: it ferienfâldiget rûtebou en ferneatiget de identiteit fan de boarne, wat fan belang is foar audit en foar regels per brûker.

Skriuw op hokker fan de twa jo keazen hawwe, njonken de regel dy't dêrfan ôfhinget.

Applikaasje-autorisaasje is net opsjoneel

It berikken fan in poarte jout gjin rol. De applikaasje hat noch altyd syn eigen oanmelding en syn eigen begunningen nedich, want de netwurklaach kin net útdrukke hokker records in brûker bewurkje mei. In tsjinst dy't elke oanfraach fan it ynterne subnet fertrout, feroaret in smelle tunnel yn folsleine tagong foar ien kompromittearre bewiis. De tunnel beslist wa't de socket iepenje mei, en de applikaasje beslist wat se dermei dwaan mei.

Hjir betellet it smelle ûntwerp him twa kear út, want minder berikbere hosts betsjutte minder plakken dêr't in flater op applikaasjenivo misbrûkt wurde kin.

Hâld de netwurkregel en de applikaasjerol yn aparte systemen, en doch se apart ôf.

Bewiis sawol it tastiene as it wegere paad

Ferbyn jo as de autorisearre brûker en doch ien harmleas represintatyf aksje, en besykje dan in bestimming dy't ûnberikber wêze moat. In ûntwerp dat allinnich de earste helte testet is net test, en de wegere test is dejinge dy't it ûntwerp bewiist. Test in nije sesje nei elke regelferoaring, en sjoch nei it werompaad as oanfragen komme mar antwurden net.

Skeakelje trochstjoerfilters net út om de akseptaasjetest te heljen, want dat feroaret it ding dat test wurdt.

As de brûker de tsjinst net mear nedich hat, doch dan de opôfstân-identiteit en de applikaasjerol yn har eigen systemen ôf, en registrearje beide. De strongSwan-rjochtline foar trochstjoeren beslacht de gateway-kant fan it paad.