MikroTik VPN-användare når för långt: begränsa till en värd och en port

Tunneln kommer upp, inloggningen lyckas och varje värd i nätet svarar. Det är inte en trasig VPN; det är en VPN utan behörighetsmodell. RouterOS autentiserar kontot och routar sedan dess paket som allas, så brandväggen måste leverera gränsen. Att lägga till den gränsen utan att bryta inloggningen är hela arbetet.

Autentisering slutar där behörigheten börjar

När en PPP-session är uppe går klientens paket in i forward-kedjan som trafik från vilket annat gränssnitt som helst. Om routerns forward-policy är tillåtande ärver konsulten den tillåtelsen vid inloggning. Kontot bar aldrig någon omfattning, så det finns inget på kontot att ändra. Regeluppsättningen skrevs för anställda och den nya sessionen anslöt sig helt enkelt till den.

Kontrollera vilken väg förfrågan gäller innan du skriver något. Trafik till värdar bakom routern korsar forward, medan trafik till routern själv, inklusive winbox och SSH, korsar input. En omfattning som bara täcker forward lämnar enheten öppen för samma klient.

Båda kedjorna behöver ett beslut, även om beslutet är att lämna input stängt. Det valet hör hemma i åtkomstbegäran, inte i en eftertanke.

Knyt sessionen till en namngiven lista

En PPP-profil kan lägga adressen den delar ut i en namngiven adresslista när sessionen startar. Det gör en övergående tunneladress till något brandväggen kan matcha på namn, och posten försvinner när sessionen tar slut. Kontot ärver då omfattningen från sin profil i stället för från en regel som hårdkodar en adress.

Skapa profilen först och bind sedan secret uttryckligen till den. Ett secret som fortfarande pekar på standardprofilen återskapar det ursprungliga problemet.

Namnge profilen och listan så att deras uppgifter är uppenbara, och kommentera båda med ärendets referens. En profil kan betjäna flera personer med samma omfattning, medan listan fortfarande identifierar varje levande session. Det är billigare att granska än 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

Registrera den tillåtna tjänsten i en lista

Sätt den tillåtna servern i sin egen adresslista i stället för att bädda in adressen i en filterregel. Listan kan granskas, utökas och kommenteras, och regeln som använder den ändras inte när servern flyttar. En enda post verkar överdriven tills den andra värden dyker upp, vilket den oftast gör.

Matcha en lista när adressen är dynamisk eller lastbalanserad, och matcha adressen direkt när den är reserverad och stabil. Båda valen läses tydligt om kommentaren namnger tjänsten och ägaren.

Begränsa protokollet och porten liksom värden. Ett accept för en värd utan portbegränsning öppnar varje tjänst som värden kör, vilket är bredare än de flesta åtkomstbegäranden avser. Porten är en del av behörigheten, inte en detalj som läggs till senare.

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

Ordna jumpet före varje brett accept

En jump-regel skickar vidarebefordrad trafik från den begränsade listan in i en privat kedja där hela policyn ryms på tre rader. Den första regeln accepterar den tillåtna destinationen och porten, och den sista regeln släpper allt annat. Jumpet måste stå över varje brett accept i forward, eftersom ett tidigare accept innebär att jumpet aldrig körs. Håll accept för established och related före jumpet så att returtrafiken fortfarande flödar.

Kontrollera att ingen fasttrack-regel kan föra denna trafik förbi den begränsade kedjan. Fasttrack kringgår resten av filtervägen, och en begränsad session som fasttrackas är inte begränsad alls.

Upprepa beslutet för input-kedjan om routerns egna tjänster ska vara oåtkomliga. En omfattning som blockerar vidarebefordrad trafik och lämnar winbox öppet är bara halvfärdig.

/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

Verifiera med räknare och listmedlemskap

Testa från klienten den tillåtna tjänsten och en som måste misslyckas, och läs sedan regelstatistiken på routern. Accept- och drop-räknarna visar vilken väg varje paket tog, vilket klienten inte kan se. Bekräfta också att den levande sessionens adress dök upp i den begränsade listan.

En tom lista betyder att kontot ligger på en annan profil eller att profilen tappade sin adresslisteinställning. En stigande drop-räknare med en misslyckad tillåten tjänst betyder att destinationen eller porten inte stämmer med det klienten skickar.

Testa samma tjänst på namn och på adress innan du drar någon slutsats. Ett fel i namnmatchningen ser från klientsidan precis ut som en blockerad port. Registrera sedan profilen, båda listorna och den enda tillåtna tjänsten i åtkomstbegäran så att nästa granskning jämför i stället för att bygga upp igen.

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