Kiel limigi aliron inter du oficejoj ligitaj per VPN

Tunelo inter ejoj respondas unu demandon, ĉu la du oficejoj povas interŝanĝi pakaĵojn, kaj lasas malfermita la gravan: kiu branĉa aparato rajtas atingi kiun centran servon. Trakti la tunelon kiel reciprokan fidon estas la maniero per kiu gastiga tekkomputilo finiĝas sur la sama vojo kiel la financa servilo. La solvo ne estas pli bona tunelo, sed eksplicita permeslisto trudita post malĉifrado. Ĉi tiu manlibro kondukas tiun liston de difino al pruvita rifuzo.

Laboru en ĉi tiu ordo, kaj ne larĝigu la tunelan itineron ĝis la subaj politikaj paŝoj trapasos.

Skribu la matricon antaŭ ol tuŝi la enirejon

Utila vico nomas tri aferojn: fontan grupon, celan gastiganton aŭ servan reton, kaj la protokolon kaj pordon kiujn la aplikaĵo efektive uzas. La branĉo kaj la datena centro ne estas eroj. Privata DNS kaj aŭtentigaj servoj meritas proprajn vicojn nur kiam la aplikaĵo ne povas funkcii sen ili.

Grupigu fontojn laŭ rolo anstataŭ laŭ subreta oportuneco: personaro, gastoj, administrado. Kiam ĉiuj tri dividas unu plat fondaĵo LAN, la enirejo ne povas distingi ilin ĉe la reta tavolo, do identecaj kontroloj aŭ segmentado devas veni unue. Poste metu la matricon skribe, kun posedanto kaj revizidato en ĉiu vico.

Trudu ĝin tie, kie la pakaĵoj estas malĉifrataj

La reguloj kiuj permesas IKE kaj ESP konstruas nur la eksteran tunelon. Interna trafiko alvenas malkaŝe ĉe la tunela interfaco, kaj ĝuste tie apartenas la permeslisto: plusenda ĉeno sur la malĉifranta aparato, implica forĵeto, unu regulo por ĉiu matrica vico. Ĉe Linux-enirejoj tio signifas ebligitan plusendadon kaj filtrajn regulojn sur la tunela aparato, ne sur la fizika ligilo, kiel klarigas la plusenda gvidilo de strongSwan.

Trafikoselektiloj estas itinera decido, ne rajtiga decido. Larĝa selektilo kiu kovras ambaŭ subretojn povas esti ĝusta por itinado dum la fajroŝirmilo ankoraŭ permesas nur TCP 443 al unu gastiganto. La selektilo estas intertraktata por la tunelo kaj priskribas kion rajtas eniri ĝin, ne kion rajtas uzi iu ajn aparato. Neniam larĝigu fajroŝirmilan regulon ĉar la selektilo estas larĝa.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT kaj koincidaj subretoj ŝanĝas la regulojn

Kiam la branĉa enirejo tradukas ĉiun gastiganton al unu adreso antaŭ la tunelo, ĉiu fontbazita vico kolapsas en tiun unu adreson. Aŭ ĉesigu traduki tunelan trafikon, aŭ akceptu ke reguloj devas baziĝi sur io alia, kiel la origina fonta adreso registrita antaŭ la traduko. La malproksima flanko havas la saman problemon, ĉar la cela gastiganto vidas la adreson post NAT kaj ne la originan.

Koincidaj gamoj estas la alia kaptilo. Du oficejoj kiuj ambaŭ uzas 192.168.1.0/24 ne povas esti priskribitaj en unu politika tabelo sen mapi unu flankon, kaj mapado ne anstataŭas adresadon kiu ne kolizias. Riparu la planon antaŭ ol skribi regulojn kiujn vi devos malimpliki poste.

Pruvu rifuzon, ne nur sukceson

Testi nur la permesitan aplikaĵon pruvas tre malmulte, ĉar permesema regulo ie supre produktas la saman rezulton.

De ordinara branĉa aparato, atingi la celatan servon kaj konfirmu ke la tuta seanco funkcias. Poste provu celon kiu devas resti fermita, kiel administran pordon sur servilo kun kiu la branĉo havas nenion komunan, kaj legu la nombrilon aŭ protokolan enskribon kiu ĝin forĵetis. Malŝalti la regularon por kontroli ĉu ĝi funkcias nuligas la teston kaj lasas la enirejon malfermita dum vi rigardas.

Tenu la liston viva

Aplikaĵoj moviĝas, kaj regulo kiu postvivas sian aplikaĵon fariĝas truo kiun neniu posedas. Ligu la revizidaton al la vico, kaj ŝanĝu la selektilan amplekson kaj la fajroŝirmilan regulon en la sama prizorga paŝo kiam servo ŝanĝas adreson.

Limigoj ĉe gastiganta nivelo ankoraŭ gravas malantaŭ la tunelo: la propra fajroŝirmilo de la servilo devus akcepti la branĉan gamon nur por la servo kiun ĝi publikigas. Du tavoloj kiuj interkonsentas estas pli facile auditaj ol unu tavolo al kiu oni plene fidas.