MikroTik VPN-bruker når for langt: begrens til én vert og én port

Tunnelen kommer opp, innloggingen lykkes, og hver vert på nettverket svarer. Det er ikke en ødelagt VPN; det er en VPN uten tillatelsesmodell. RouterOS autentiserer kontoen og ruter deretter pakkene dens som alles, så brannmuren må levere grensen. Å legge til den grensen uten å ødelegge innloggingen er hele jobben.

Autentisering slutter der tillatelsen begynner

Når en PPP-økt er oppe, går pakkene fra klienten inn i forward-kjeden som trafikk fra et hvilket som helst annet grensesnitt. Hvis forward-policyen til ruteren er ettergivende, arver konsulenten den ettergivenheten ved innlogging. Kontoen bar aldri et omfang, så det er ingenting på kontoen å endre. Regelsettet ble skrevet for ansatte, og den nye økten sluttet seg ganske enkelt til det.

Sjekk hvilken vei forespørselen gjelder før du skriver noe. Trafikk til verter bak ruteren krysser forward, mens trafikk til ruteren selv, inkludert winbox og SSH, krysser input. Et omfang som bare dekker forward, lar enheten stå åpen for den samme klienten.

Begge kjedene trenger en beslutning, selv om beslutningen er å holde input lukket. Det valget hører hjemme i tilgangsforespørselen, ikke i en ettertanke.

Knytt økten til en navngitt liste

En PPP-profil kan legge adressen den deler ut i en navngitt adresseliste når økten starter. Det gjør en forbigående tunneladresse til noe brannmuren kan matche ved navn, og oppføringen forsvinner når økten slutter. Kontoen arver da omfanget fra profilen sin i stedet for fra en regel som hardkoder en adresse.

Opprett profilen først, og bind deretter secret eksplisitt til den. Et secret som fortsatt peker på standardprofilen, gjenskaper det opprinnelige problemet.

Gi profilen og listen navn slik at oppgavene deres er tydelige, og kommenter begge med referansen til forespørselen. Én profil kan betjene flere personer med samme omfang, mens listen fortsatt identifiserer hver levende økt. Det er billigere å gjennomgå enn en regel per person.

/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

Registrer den tillatte tjenesten på én liste

Sett den tillatte serveren på sin egen adresseliste i stedet for å bygge adressen inn i en filterregel. Listen kan revideres, utvides og kommenteres, og regelen som bruker den endres ikke når serveren flytter. Én oppføring virker overdrevet helt til den andre verten dukker opp, noe den vanligvis gjør.

Match en liste når adressen er dynamisk eller lastbalansert, og match adressen direkte når den er reservert og stabil. Begge valgene leses tydelig hvis kommentaren nevner tjenesten og eieren.

Begrens protokollen og porten så vel som verten. Et accept for en vert uten portbegrensning åpner hver tjeneste som verten kjører, noe som er bredere enn de fleste tilgangsforespørsler har tenkt. Porten er en del av tillatelsen, ikke en detalj som legges til senere.

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

Ordne jumpet før et hvilket som helst bredt accept

En jump-regel sender videresendt trafikk fra den begrensede listen inn i en privat kjede der hele policyen får plass på tre linjer. Den første regelen godtar den tillatte destinasjonen og porten, og den siste regelen dropper alt annet. Jumpet må stå over et hvilket som helst bredt accept i forward, fordi et tidligere accept betyr at jumpet aldri kjører. Hold accept for established og related foran jumpet slik at returtrafikk fortsatt flyter.

Sjekk at ingen fasttrack-regel kan føre denne trafikken forbi den begrensede kjeden. Fasttrack omgår resten av filterveien, og en begrenset økt som fasttrackes er ikke begrenset i det hele tatt.

Gjenta beslutningen for input-kjeden hvis ruterens egne tjenester skal være utilgjengelige. Et omfang som blokkerer videresendt trafikk og lar winbox stå åpen, er bare halvferdig.

/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

Verifiser med tellere og listemedlemskap

Test fra klienten den tillatte tjenesten og en som må feile, og les deretter regelstatistikken på ruteren. Accept- og drop-tellerne viser hvilken vei hver pakke tok, noe klienten ikke kan se. Bekreft også at adressen til den levende økten dukket opp i den begrensede listen.

En tom liste betyr at kontoen er på en annen profil, eller at profilen mistet adresselisteinnstillingen. En stigende drop-teller med en feilende tillatt tjeneste betyr at destinasjonen eller porten ikke samsvarer med det klienten sender.

Test den samme tjenesten ved navn og ved adresse før du konkluderer noe. En feil i navneoppslag ser nøyaktig ut som en blokkert port fra klientsiden. Registrer deretter profilen, begge listene og den eneste tillatte tjenesten i tilgangsforespørselen, slik at neste gjennomgang sammenligner i stedet for å gjenoppbygge.

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