MikroTik-VPN-uzanto atingas tro multe: limigu al unu gastiganto kaj unu pordo

La tunelo leviĝas, la saluto sukcesas, kaj ĉiu gastiganto en la reto respondas. Tio ne estas rompita VPN; ĝi estas VPN sen permesmodelo. RouterOS aŭtentikigas la konton kaj poste enkursigas ĝiajn pakojn kiel ĉies, do la fajroŝirmilo devas provizi la limon. Aldoni tiun limon sen rompi la saluton estas la tuta laboro.

Aŭtentikigo finiĝas kie permeso komenciĝas

Post kiam PPP-sesio leviĝis, pakoj de la kliento eniras la forward-ĉenon kiel trafiko de iu ajn alia interfaco. Se la forward-politiko de la enkursigilo estas permesema, la konsultanto heredas tiun permesemon ĉe saluto. La konto neniam portis amplekson, do estas nenio ŝanĝebla sur la konto. La regularo estis skribita por dungitoj kaj la nova sesio simple aliĝis al ĝi.

Kontrolu pri kiu vojo temas la peto antaŭ ol skribi ion. Trafiko al gastigantoj malantaŭ la enkursigilo trapasas forward, dum trafiko al la enkursigilo mem, inkluzive winbox kaj SSH, trapasas input. Amplekso kiu kovras nur forward lasas la aparaton malfermita al la sama kliento.

Ambaŭ ĉenoj bezonas decidon, eĉ se la decido estas lasi input fermita. Tiu elekto apartenas al la alirpeto, ne al postpenso.

Ligu la sesion al nomita listo

PPP-profilo povas meti la adreson kiun ĝi donas en nomitan adresliston kiam la sesio komenciĝas. Tio transformas paseman tunelan adreson en ion, kion la fajroŝirmilo povas kongruigi laŭ nomo, kaj la rikordo malaperas kiam la sesio finiĝas. La konto tiam heredas la amplekson de sia profilo anstataŭ de regulo, kiu malmole kodas adreson.

Unue kreu la profilon, poste eksplicite ligu la secret al ĝi. Secret kiu ankoraŭ montras al la defaŭlta profilo reproduktas la originan problemon.

Nomu la profilon kaj la liston tiel, ke iliaj taskoj estu evidentaj, kaj komentu ambaŭ per la referenco de la peto. Unu profilo povas servi plurajn homojn kun la sama amplekso, dum la listo ankoraŭ identigas ĉiun vivan sesion. Tio estas pli malmultekosta por revizio ol regulo por persono.

/ppp profile add name=scoped-consultant remote-address=consultant-pool address-list=vpn-scoped-clients
/ppp secret add name=consultant password=... service=ovpn profile=scoped-consultant

Registru la permesitan servon en unu listo

Metu la permesitan servilon en ĝian propran adresliston anstataŭ enigi la adreson en filtran regulon. La listo povas esti aŭditata, etendata kaj komentata, kaj la regulo, kiu uzas ĝin, ne ŝanĝiĝas kiam la servilo moviĝas. Unu rikordo ŝajnas troa ĝis la dua gastiganto alvenos, kio kutime okazas.

Kongruigu liston kiam la adreso estas dinamika aŭ ŝarĝ-distribuita, kaj kongruigu la adreson rekte kiam ĝi estas rezervita kaj stabila. Ambaŭ elektoj legeblas klare se la komento nomas la servon kaj la posedanton.

Limigu la protokolon kaj la pordon same kiel la gastiganton. Accept por gastiganto sen pordolimo malfermas ĉiun servon, kiun tiu gastiganto funkciigas, kio estas pli larĝa ol plej multaj alirpetoj intencas. La pordo estas parto de la permeso, ne detalo aldonota poste.

/ip firewall address-list add list=vpn-targets address=10.0.0.10 comment="consultant RDP target"

Ordigi la salon antaŭ iu ajn larĝa accept

Salta regulo sendas plusenditan trafikon de la limigita listo en privatan ĉenon, kie la tuta politiko taŭgas en tri linioj. La unua regulo akceptas la permesitan celon kaj pordon, kaj la lasta forĵetas ĉion alian. La salto devas stari super iu ajn larĝa accept en forward, ĉar pli frua accept signifas, ke la salto neniam ruliĝas. Tenu la accept por established kaj related antaŭ la salto, por ke revena trafiko daŭre fluu.

Kontrolu ke neniu fasttrack-regulo povas porti ĉi tiun trafikon preter la limigita ĉeno. Fasttrack preterpasas la reston de la filtra vojo, kaj limigita sesio, kiu estas fasttrackita, tute ne estas limigita.

Ripetu la decidon por la input-ĉeno se la propraj servoj de la enkursigilo devus esti neatingeblaj. Amplekso, kiu blokas plusenditan trafikon kaj lasas winbox malfermita, estas nur duone finita.

/ip firewall filter
add chain=forward action=jump jump-target=scoped-vpn src-address-list=vpn-scoped-clients
add chain=scoped-vpn action=accept protocol=tcp dst-address-list=vpn-targets dst-port=3389
add chain=scoped-vpn action=drop

Kontrolu per nombriloj kaj listan membrecon

De la kliento, testu la permesitan servon kaj unu, kiu devas malsukcesi, poste legu la regulan statistikon sur la enkursigilo. La nombriloj accept kaj drop montras, kiun vojon ĉiu pako prenis, kion la kliento ne povas vidi. Konfirmu ankaŭ, ke la adreso de la viva sesio aperis en la limigita listo.

Malplena listo signifas, ke la konto estas sur alia profilo aŭ ke la profilo perdis sian adreslistan agordon. Plialtiĝanta drop-nombrilo kun malsukcesa permesita servo signifas, ke la celo aŭ pordo ne kongruas kun tio, kion la kliento sendas.

Testu la saman servon laŭ nomo kaj laŭ adreso antaŭ ol konkludi ion. Malsukceso de nomrezolucio aspektas ekzakte kiel blokita pordo de la klienta flanko. Poste registru la profilon, ambaŭ listojn kaj la solan permesitan servon en la alirpeto, por ke la sekva revizio komparu anstataŭ rekonstrui.

/ip firewall filter print stats where chain=scoped-vpn
/ip firewall address-list print where list=vpn-scoped-clients