Donu al VPN-uzantoj aliron al unu servo, ne al la subreto

Kontraktisto bezonas unu internan retaplikaĵon kaj nenion alian, kaj la facila respondo estas doni al li tunelon en la servilan subreton. Tio funkcias ĝis la tago, kiam li skanos ĝin. La pli mallarĝa dezajno postulas pli da pripenso, ĉar atingeblo, enkursigado kaj aplikaĵa permeso estas tri apartaj regiloj, kiuj devas kongrui.

Skribu la postulon kiel servo, ne kiel subreto

Komencu per la celloka gastiganto, la protokolo kaj la pordo, poste aldonu la uzantan aŭ aparatan grupon, kiu devas atingi ĝin. Inkluzivu la privatan DNS-zonon nur se la aplikaĵo solvas nomon, kaj inkluzivu identigprovizanton nur se la ensaluta fluo bezonas ĝin. Ĉio alia estas dependeco, kiun vi ankoraŭ ne pravigis.

Subreto estas efektiviga detalo de la reta teamo, dum servo estas tio, kion petis la entrepreno, kaj la unuo, kiun oni povas revizii kaj retiri.

Se la dependeca listo kreskas preter tri eroj, la aplikaĵo verŝajne bezonas propran dezajnan interparoladon.

Enkursigu mallarĝe, sed plenumu aliloke

Mallarĝa vojo aŭ selektilo diras al la tunelo, kiujn pakaĵojn ĝi portu; ĝi ne estas rajtiga politiko. La pordega filtrilo, la fajroŝirmilo de la cela gastiganto kaj la propra permesmodelo de la aplikaĵo estas la loko, kie oni decidas pri aliro. Vojo kovranta unu adreson estas bona komenco, kaj ĝi ne estas la regilo, kiu haltigas decideman uzanton. Ĝuste tiu apartigo ebligas ŝanĝi la filtrilon sen redesegni la tunelon.

Male, larĝa vojo kun strikta filtrilo povas esti laŭleĝa, sed nur se ĉiuj koncernatoj scias, kiu el la du plenumas la regulon.

Dokumentu la plenuman punkton eksplicite, alie la sekva ŝanĝo movos ĝin hazarde.

Kontrolu la fonton, kiun la servo efektive vidas

La celo vidas aŭ la adreson el la klienta baseno aŭ la adreson de la pordego, laŭ tio, ĉu vi tradukas. La fajroŝirmilaj reguloj kaj protokoloj de la gastiganto devas kongrui kun la reala fonto. Se pluraj uzantoj dividas tradukitan fonton, neniu regulo por unuopa uzanto sur tiu gastiganto povas distingi ilin, kaj tio estas dezajna limigo, ne cimo.

Elektu tradukon konscie: ĝi simpligas enkursigadon kaj detruas fontan identecon, kio gravas por revizio kaj por reguloj por unuopaj uzantoj.

Notu, kiun el la du vi elektis, apud la regulo, kiu dependas de ĝi.

La rajtigo de la aplikaĵo ne estas laŭvola

Atingi pordon ne donas rolon. La aplikaĵo ankoraŭ bezonas sian propran ensaluton kaj siajn proprajn permesojn, ĉar la reta tavolo ne povas esprimi, kiujn rikordojn uzanto rajtas redakti. Servo, kiu fidas ĉiun peton el la interna subreto, transformas mallarĝan tunelon en plenan aliron por unu kompromitita legitimilo. La tunelo decidas, kiu rajtas malfermi la ingon, kaj la aplikaĵo decidas, kion oni rajtas fari kun ĝi.

Ĉi tie la mallarĝa dezajno pagas duoble, ĉar malpli da atingeblaj gastigantoj signifas malpli da lokoj, kie eraro je aplikaĵa nivelo povas esti ekspluatata.

Tenu la retan regulon kaj la aplikaĵan rolon en apartaj sistemoj, kaj retiru ilin aparte.

Pruvu kaj la permesitan kaj la rifuzitan vojon

Konektiĝu kiel la rajtigita uzanto kaj plenumu unu sendanĝeran reprezentan operacion, poste provu celon, kiu devus esti neatingebla. Dezajno, kiu testas nur la unuan duonon, ne estas testita, kaj la rifuza testo estas tiu, kiu pruvas la dezajnon. Testu novan seancon post ĉiu regula ŝanĝo, kaj rigardu la revenan vojon, se petoj alvenas sed respondoj ne.

Ne malŝaltu plusendajn filtrilojn por igi la akceptan teston sukcesi, ĉar tio ŝanĝas la aferon, kiu estas testata.

Kiam la uzanto ne plu bezonas la servon, retiru la malproksiman identecon kaj la aplikaĵan rolon en iliaj respektivaj sistemoj, kaj registru ambaŭ. La gvidilo de strongSwan pri plusendado kovras la pordegan flankon de la vojo.