핑이 한 방향으로만 작동하는 이유: Windows가 서버의 에코를 버리는 까닭

클라이언트는 서버로 핑이 가지만 서버는 클라이언트로 핑이 가지 않는데, 그런데도 터널은 두 문장 모두에서 분명히 패킷을 나르고 있습니다. 다른 것은 경로가 아니라 각 테스트의 첫 패킷입니다. 하나는 Windows가 이미 추적하는 흐름에 대한 응답이고, 다른 하나는 어떤 규칙도 허용하지 않은 새 인바운드 요청이며, 이 차이가 단방향 핑 보고의 대부분을 설명하고 작성해야 할 규칙을 곧바로 가리킵니다. 반대 방향으로 두 번 시험하면 한 분 남짓에 어느 경우인지 갈라집니다.

두 방향, 두 가지 다른 결정

클라이언트가 에코 요청을 보내면 Windows 방화벽은 허용하기로 결정한 아웃바운드 연결로 봅니다. 응답은 그 확립된 흐름 안으로 돌아오므로, 상태를 추적하는 엔진은 ICMP용 인바운드 규칙을 묻지 않고 통과시킵니다. 실무에서 상태 기반 필터링이 뜻하는 바가 이것이며, 아무도 쓰지 않은 규칙은 여기에 관여하지 않습니다. 따라서 클라이언트의 성공은 인바운드 정책에 대해 아무것도 말해 주지 않습니다.

서버가 먼저 요청을 보내면 그것에 맞는 상태가 없습니다. Windows는 그 패킷을 새 인바운드 연결로 처리하고 인바운드 정책에 묻지만, 그 정책은 기본적으로 임의 출처에서 오는 에코 요청을 전혀 염두에 두지 않습니다.

즉 클라이언트의 성공은 아웃바운드 ICMP와 귀환 경로가 작동함을 증명했을 뿐입니다. 인바운드 결정은 한 번도 시험하지 않았고, 방화벽이 멀쩡하다는 자연스러운 결론은 그럴듯하지만 틀렸습니다. 그래서 증거가 이미 들어 있는 티켓에서도 같은 실수가 되풀이됩니다.

패킷이 사라질 때까지 추적하라

무엇이든 바꾸기 전에 주소를 확인하십시오. 클라이언트가 실제로 가진 터널 주소를 쓰고, 서버가 클라이언트 뒤의 LAN 주소가 아니라 그 주소로 라우팅하는지 확인하십시오. 두 실패는 둘 다 시간 초과로 끝나므로 서버 프롬프트에서 똑같이 보이며, 패킷이 어디서 죽는지가 무엇을 바꿀지 결정하는 유일한 사실입니다.

요청이 터널 인터페이스에 도달했는데 나가는 것이 없다면 로컬 방화벽이 유력한 원인입니다. 인터페이스에 아예 도달하지 않는다면 답은 상류, 즉 서버의 경로, 아웃바운드 정책, 또는 VPN 자체의 피어 전달입니다.

서버가 핑을 보내는 동안 클라이언트의 터널 인터페이스에서 캡처하십시오. 요청이 옆에 응답 없이 도착하는 것을 보는 것이 Windows 규칙을 쓸 근거가 됩니다. 아무것도 보이지 않으면 상류로 가야 하며, 그 상태에서 규칙을 더하면 결코 도착하지 않은 패킷에 대해 기계가 더 관대해질 뿐입니다. 어느 쪽이든 캡처 비용은 그것이 대신하는 추측보다 적습니다.

ICMP를 여는 대신 규칙 하나를 한정하라

둘 다 곧 설정할 범위에 나타나므로, 무엇이든 쓰기 전에 어댑터와 현재 범주를 확인하십시오. 그 별칭은 Windows 인터페이스 이름이며, 가져온 VPN 프로필의 이름과 반드시 같지는 않습니다. 아래 명령은 무엇이 있는지 나열한 뒤 적용하지 않고 범위가 한정된 규칙을 미리 보여 줍니다.

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

ICMPv4 유형 8이 에코 요청이며, 서버가 응답을 받아야 하는 유일한 메시지입니다. 그것을 서버의 터널 주소와 터널 인터페이스로 한정하고, 프로필은 어댑터가 실제로 그러한 상태로 두십시오. 예시에 맞추려고 네트워크 이름을 바꾸는 것은 그 자체의 결과를 지닌 별개의 변경입니다.

규칙이 다루지 않는 것

IPv6 에코는 메시지 유형이 다른 다른 프로토콜이므로 ICMPv4 규칙은 그것에 대해 아무것도 말하지 않으며, 두 체계를 모두 나르는 터널은 다른 쪽을 위한 규칙을 따로 가져야 합니다. 이 규칙은 다른 것도 열지 않고, RDP, 파일 공유, 그 밖의 모든 서비스는 여전히 각자의 정책에 따릅니다. 넓은 ICMP 허용을 켜는 대신 좁은 규칙 하나를 한정하는 데에 요점이 있습니다. 넓은 허용은 손쉬운 해결책이며, 나중에는 아무도 알아차리지 않기 때문에 가장 오래 살아남습니다.

관리되는 장치에서는 다음 정책 새로 고침 때 규칙이 바뀔 수 있으므로, 로컬 관리자가 아니라 정책 소유자가 같은 변경을 해야 합니다. 새로 고침은 명령을 지우고 요구 사항만 남기므로, 의도를 명령과 함께 티켓에 적으십시오. 둘은 같은 산출물이 아니며, 살아남는 것은 하나뿐입니다.

결과를 올바른 방향에서 읽어라

규칙이 적용되면 서버에서 핑을 보내 응답이 클라이언트에 도달하는지 확인하고, 이어서 여전히 제외되어야 하는 출처에서 핑을 보내 도달하지 않는지 확인하십시오. 터널이 다른 주소 체계도 나른다면 그쪽에서도 도달성 시험을 반복하십시오.

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

미리 보기와 적용된 규칙은 다른 상태이므로, 효력이 발생한 규칙을 출력하는 편이 그것을 만든 명령을 믿는 것보다 유용합니다. 주소 필터가 의도한 출처를 보여 주고 제외한 출처가 여전히 시간 초과로 끝난다면, 규칙은 그 범위가 말하는 대로 정확히 작동합니다. 클라이언트에서 시작한 성공한 핑으로는 그것을 결코 보여 줄 수 없었으므로, 각 시험의 방향은 결과 옆의 기록에 남아야 합니다. 티켓에 두 방향을 모두 남기지 않으면 다음 독자가 실패할 수 없는 시험을 되풀이합니다.