현재 Oracle Cloud에서 호스팅되는 무료 VPS를 보유하고 있습니다. 이 시스템은 주소 범위가 10.0.0.0/8(정확하게는 10.0.0.19)인 가상 LAN인 "가상 클라우드 네트워크"에 있습니다.
현실 세계와 통신하기 위해 퍼블릭 프라이빗 IPv4가 있는데, 203.0.113.1이라고 가정해 보겠습니다. 게이트웨이는 풀콘 1:1 NAT를 적용하므로 프로토콜 및 포트(해당하는 경우)에 관계없이 이 203.0.113.1 IP로 전송된 모든 패킷이 컴퓨터로 전달됩니다.
하지만 이 NAT는 대상 IP가 실제 공인 IP 203.0.113.1이 아닌 10.0.0.19로 대체된다는 의미입니다. 이는 대상 IP에 관심이 없는 대부분의 서비스(예: HTTPS, SSH 등)에서는 문제가 되지 않습니다.
그러나 IPsec의 경우 이는 문제가 됩니다. IPsec은 컴퓨터에 공개적으로 라우팅 가능한 IP 주소가 할당될 것으로 예상하고 연결 요청의 대상 IP를 사용하여 클라이언트가 연결되는 위치를 보고합니다. 이로 인해 클라이언트는 10.0.0.19에 연결을 시도하지만 당연히 실패합니다.
일종의 가상 어댑터(예: 루프백 어댑터)를 만들고 인터넷에서 해당 어댑터로 패킷을 전달하여 10.0.0.19 IP를 실제 IP 203.0.113.1로 대체하여 IPsec이 작동하도록 할 수 있습니까?
답변1
관심을 돌리고 있는 것 같습니다.
Android에서는 데스크탑 컴퓨터에 접근할 수 없어 사용하고 있던 시스템에서 연결을 시도하다가 약 1분 정도 프로세스가 지속되다가 실패하는 현상이 나타났습니다. 따라서 오류가 발생하는 데 걸리는 시간을 고려하면 이는 연결 재시도 및 시간 초과로 인한 것이라고 가정합니다.
그러나 Windows 컴퓨터에서는 컴퓨터가 인증서를 신뢰하지 않기 때문에 오류 13801이 시스템 로그에 즉시 발생합니다.
Wireshark를 사용하는 MitM은 OpenIKED 데몬이 중간에 Let's Encrypt에서 사용하는 콘텐츠를 제대로 전송하지 않아 시스템이 이를 신뢰하지 않는다는 것을 증명합니다.