Utworzono VPC „Dev” z jedną podsiecią i regułą zapory sieciowej zezwalającą tylko na ruch HTTP z włączonym logowaniem. Połączenie RDP z instancją kończy się niepowodzeniem, a w Cloud Logging nie pojawiają się żadne odrzucone wpisy zapory sieciowej. Chcesz zobaczyć logi zablokowanego ruchu. Co należy zrobić?

Poprawna odpowiedź to utworzenie reguły zapory sieciowej typu "deny-all" z niskim priorytetem (np. 65500) i włączeniem logowania. Domyślne reguły zapory sieciowej Google Cloud mają priorytet 1000 i zezwalają na ruch wychodzący, ale blokują cały ruch przychodzący, chyba że zostanie on jawnie dozwolony. Ponieważ nie ma reguły zezwalającej na RDP (port 3389), ruch jest blokowany przez domyślną regułę "deny-all" o priorytecie 65535, która nie jest logowana. Dodanie własnej reguły "deny-all" z priorytetem niższym niż domyślna reguła (czyli wyższym numerem priorytetu) i włączonym logowaniem spowoduje, że to właśnie ta reguła zablokuje ruch RDP i zarejestruje to zdarzenie w Cloud Logging. Sprawdzenie logów przepływu VPC (VPC Flow Logs) dla instancji nie pokaże odrzuconego ruchu przez zaporę sieciową, ponieważ logi przepływu rejestrują ruch, który przeszedł przez interfejs sieciowy instancji, a nie ruch zablokowany przez zaporę. Próba połączenia przez SSH i sprawdzenie logów nie jest rozwiązaniem problemu z logowaniem zablokowanego ruchu RDP. Utworzenie reguły zezwalającej na TCP/22 (SSH) z włączonym logowaniem nie pomoże w logowaniu zablokowanego ruchu RDP, ponieważ dotyczy innego protokołu.