Dodanie reguły zezwolenia dla RDP nie zawęża dostępu przez VPN

Plan brzmi rozsądnie: zostaw istniejące zezwolenie dla Pulpitu zdalnego bez zmian i dodaj małe dla jedynego klienta VPN, który powinien mieć dostęp. Zapora systemu Windows nie działa w ten sposób. Reguły nie są uporządkowaną listą, na której wygrywa najbardziej szczegółowy wpis, a wąskie zezwolenie obok szerokiego niczego nie zmienia, bo szerokie nadal wpuszcza wszystkich, których już wpuszczało. Zawężenie usługi oznacza edycję zezwolenia, które już wykonuje pracę.

Reguła, którą dodajesz, nie jest regułą, która ma znaczenie

Zapora systemu Windows ocenia wszystkie obowiązujące reguły przychodzące w magazynach zasad dotyczących komputera, a następnie decyduje, czy jakieś zezwolenie pasuje i czy jakieś blokowanie je przewyższa. Dodanie reguły dodaje zezwolenie; nie usuwa ani nie uściśla zezwoleń, które już istnieją.

Pytanie nigdy nie brzmi, co dodałeś. Brzmi: co zawiera efektywna zasada po scaleniu zasady lokalnej, zasady domeny i wartości domyślnych profilu. Stację roboczą z jedną regułą lokalną łatwo przemyśleć; serwera przyłączonego do domeny już nie.

Dlatego administrator może wprowadzić zmianę, która wygląda poprawnie, przetestować ją z niewłaściwego komputera i uznać, że zadziałała. Wykluczone źródło nigdy nie zostało przetestowane. Test, który dowodzi tylko sukcesu, dowodzi mniej niż połowy tego, czemu zmiana miała służyć.

Ustal, jaki adres widzi serwer

Zanim cokolwiek ograniczysz, obserwuj jedną dozwoloną sesję na hoście Windows i zapisz adres źródłowy, który zgłasza serwer. To nie zawsze adres, który klient uważa za swój.

Jeśli brama VPN zachowuje adresy klientów, serwer widzi adres tunelu klienta i reguła ograniczona adresem ma sens. Jeśli brama tłumaczy adresy, każdy klient przychodzi jako adres bramy, a ograniczenie do tego adresu daje dostęp każdemu klientowi za nią. Wtedy reguła jest precyzyjna w niewłaściwej rzeczy.

Te dwa projekty wymagają różnych odpowiedzi. Pierwszy można wyrazić w regule zapory; drugi trzeba wymusić tam, gdzie tożsamość jeszcze istnieje, czyli w samym VPN albo w uwierzytelnionej bramie przed usługą.

Filtr zapory nie odzyska tożsamości, którą tłumaczenie sieci odrzuciło, choćby adres wpisano najstaranniej.

Zmień właściciela efektywnej reguły

Przejrzyj efektywną zasadę przychodzącą i znajdź każdą regułę, która obecnie dopuszcza ruch RDP, w tym reguły, których wyświetlana nazwa nigdy nie wspomina portu 3389. Liczą się też reguły ograniczone usługą i aplikacją, a także transport UDP, który włączają niektóre wdrożenia RDP.

Następnie edytuj istniejące reguły przez magazyn, do którego należą. Lokalna zmiana reguły, którą definiuje także zasada domeny, może zostać scalona, zignorowana lub nadpisana, i warto wiedzieć, który z tych przypadków zachodzi, zanim się na niej oprzesz.

Te polecenia znajdują aktywne reguły, pokazują filtr adresów powiązany z jedną z nich i wyświetlają podgląd zmiany zakresu:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

Nazwy reguł są tu symbolami zastępczymi tego, co znalazł przegląd, a flaga podglądu istnieje po to, by literówka w adresie nie odcięła cię od serwera, który edytujesz.

Najpierw blokuj, potem zezwalaj to inny model

Nawyk z innych zapór to napisanie szerokiego blokowania, a następnie wąskiego zezwolenia nad nim. W Windows jawne blokowanie zwykle wygrywa z zezwoleniem, więc taka kolejność tworzy usługę, do której nikt nie dotrze, zamiast wyjątku dla jednego klienta. Wynikiem jest awaria wyglądająca jak zepsuta usługa RDP. W rzeczywistości to błąd priorytetu, a poprawka polega na usunięciu blokowania, a nie na dodaniu kolejnego zezwolenia.

Zachowaj domyślne blokowanie ruchu przychodzącego w aktywnych profilach i zamiast tego zawęź konkretne zezwolenia. To zostawia maszynę z jedną zrozumiałą postawą zamiast dwóch sprzecznych reguł, których wzajemne oddziaływanie zależy od szczegółów priorytetu.

Udowodnij to drugim źródłem

Testuj z dozwolonego klienta i ze źródła, które teraz powinno zawieść. Jedno udane połączenie dowodzi tylko, że dozwolona ścieżka działa; nic nie mówi o wykluczeniu, którego właśnie dokonałeś.

Powtórz test przez IPv6, jeśli serwer ma je włączone, bo zamiar dotyczący tylko IPv4 może współistnieć z szerokim zezwoleniem IPv6, na które nikt nie spojrzał.

Na koniec trzymaj uwierzytelnianie oddzielnie od osiągalności. Uwierzytelnianie na poziomie sieci, uprawnienia konta i ograniczenia logowania nadal decydują, kto może korzystać z sesji, a zapora decyduje tylko, kto może zapytać. Usunięcie urządzenia później powinno usunąć zarówno jego rejestrację VPN, jak i to uprawnienie sieciowe, inaczej ograniczony adres kiedyś będzie należeć do kogoś innego.