인터넷 없이도 글로벌 IP 주소를 사용할 수 있나요?

Question 1

그것은 절대적으로 가능합니다. IPV4 공간에는 마법 같은 것이 없으며 모두 동일한 방식으로 작동합니다. 이 네트워크가 인터넷에 통합되면 수년이 지나면 골치 아픈 문제가 발생합니다.

Answer

그것은 절대적으로 가능합니다. IPV4 공간에는 마법 같은 것이 없으며 모두 동일한 방식으로 작동합니다. 이 네트워크가 인터넷에 통합되면 수년이 지나면 골치 아픈 문제가 발생합니다.

Question 2

예, 가능하지만 권장되지 않습니다.

대신 RFC1918 할당 블록과 가능한 한 소규모 네트워크를 사용해야 합니다. 소수의 장치가 있는 홈 네트워크에 10.0.0.0/8을 사용하지 마십시오.

자세한 내용은https://www.rfc-editor.org/rfc/rfc1918그리고 그 교체https://www.rfc-editor.org/rfc/rfc6761

좋은 경험 법칙은 해당 네트워크에서 실행할 수 있는 최대 장치 수의 4배 또는 /24(254개 호스트) 중 더 큰 네트워크 크기를 사용하는 것입니다. A /24는 또한 서브넷을 단순화합니다.

따라서 10.yourstreetnumber.yourbirthyear.0 또는 192.168.yourheightincm.0을 사용하세요. 창의력을 발휘하세요!

사이트 간 VPN을 만들 가능성이 있다면 172.16~31.0.0 범위를 후보로 고려하세요. 그 이유는 조금 더 복잡하고 덜 사용되기 때문입니다.

기존 공개 범위를 사용하지 않는 또 다른 이유는 DNS 캐싱이 네트워크를 변경하는 장치를 망칠 수 있다는 것입니다. IE 노트북, 휴대폰, 태블릿은 "dns.google.com"을 8.8.8.8로 캐시하고 LAN에 연결되면 해당 레코드를 계속 사용할 수 있습니다. 또는 누군가 집에 가서 8.8.8.8로 확인되는 호스트 이름 "fileserver.local"이 레코드의 TTL까지 캐시될 수 있습니다.

어리석은 IP 재사용의 예 - vmware 워크스테이션 시절에는 127.99.99.0/24를 IP 네트워크로 사용해 보았지만 루프백 인터페이스에 적용된 127.0.0.0/8보다 더 구체적이었습니다.

이는 vmware 및 Linux VM에서 완벽하게 작동했습니다. 그러나 Windows(XP?)는 IP 주소의 첫 번째 옥텟에 127을 입력하자마자 "Stop, no"라고 말했습니다. 당시에는 DHCP를 통해 IP 할당을 시도한 적이 없습니다.

의도하지 않은 결과가 발생할 가능성은 엄청납니다.

그리고 때로는 드물게 클래스풀한 네트워킹이 당신을 혼란스럽게 만들 때도 있습니다. 저는 192.168.0.0/16 네트워크를 운영했는데 Windows 95, XP, NT4, Linux, Mac, 프린터 등 많은 것들이 행복하게 공존하고 있었습니다.

그런 다음 우리는 여러 개의 Linksys WRT54GL AP를 얻었고 192.168과 함께 사용할 때 /24보다 큰 넷마스크를 허용하지 않았습니다. 이는 원래 192.168.0.0이 다음과 같이 정의되었기 때문입니다.

256개의 연속 클래스 C 네트워크

따라서 네트워크는 256개 이하의 호스트여야 했습니다. 이것은 일부 linksys 키트에서만 나타났으며 OpenWRT가 있는 플래시는 전체 /16 네트워크를 사용하게 되어 기뻤습니다.

결론적으로 /24는 대부분의 사용자에게 충분합니다. /8 또는 /16은 너무 큽니다.

Answer

예, 가능하지만 권장되지 않습니다.

대신 RFC1918 할당 블록과 가능한 한 소규모 네트워크를 사용해야 합니다. 소수의 장치가 있는 홈 네트워크에 10.0.0.0/8을 사용하지 마십시오.

자세한 내용은https://www.rfc-editor.org/rfc/rfc1918그리고 그 교체https://www.rfc-editor.org/rfc/rfc6761

좋은 경험 법칙은 해당 네트워크에서 실행할 수 있는 최대 장치 수의 4배 또는 /24(254개 호스트) 중 더 큰 네트워크 크기를 사용하는 것입니다. A /24는 또한 서브넷을 단순화합니다.

따라서 10.yourstreetnumber.yourbirthyear.0 또는 192.168.yourheightincm.0을 사용하세요. 창의력을 발휘하세요!

사이트 간 VPN을 만들 가능성이 있다면 172.16~31.0.0 범위를 후보로 고려하세요. 그 이유는 조금 더 복잡하고 덜 사용되기 때문입니다.

기존 공개 범위를 사용하지 않는 또 다른 이유는 DNS 캐싱이 네트워크를 변경하는 장치를 망칠 수 있다는 것입니다. IE 노트북, 휴대폰, 태블릿은 "dns.google.com"을 8.8.8.8로 캐시하고 LAN에 연결되면 해당 레코드를 계속 사용할 수 있습니다. 또는 누군가 집에 가서 8.8.8.8로 확인되는 호스트 이름 "fileserver.local"이 레코드의 TTL까지 캐시될 수 있습니다.

어리석은 IP 재사용의 예 - vmware 워크스테이션 시절에는 127.99.99.0/24를 IP 네트워크로 사용해 보았지만 루프백 인터페이스에 적용된 127.0.0.0/8보다 더 구체적이었습니다.

이는 vmware 및 Linux VM에서 완벽하게 작동했습니다. 그러나 Windows(XP?)는 IP 주소의 첫 번째 옥텟에 127을 입력하자마자 "Stop, no"라고 말했습니다. 당시에는 DHCP를 통해 IP 할당을 시도한 적이 없습니다.

의도하지 않은 결과가 발생할 가능성은 엄청납니다.

그리고 때로는 드물게 클래스풀한 네트워킹이 당신을 혼란스럽게 만들 때도 있습니다. 저는 192.168.0.0/16 네트워크를 운영했는데 Windows 95, XP, NT4, Linux, Mac, 프린터 등 많은 것들이 행복하게 공존하고 있었습니다.

그런 다음 우리는 여러 개의 Linksys WRT54GL AP를 얻었고 192.168과 함께 사용할 때 /24보다 큰 넷마스크를 허용하지 않았습니다. 이는 원래 192.168.0.0이 다음과 같이 정의되었기 때문입니다.

256개의 연속 클래스 C 네트워크

따라서 네트워크는 256개 이하의 호스트여야 했습니다. 이것은 일부 linksys 키트에서만 나타났으며 OpenWRT가 있는 플래시는 전체 /16 네트워크를 사용하게 되어 기뻤습니다.

결론적으로 /24는 대부분의 사용자에게 충분합니다. /8 또는 /16은 너무 큽니다.

Question 3

예, 가능합니다. 아니요, 당신은 원하지 않습니다. 내가 본 다른 답변과는 달리, 그 이유에 대해 더 자세히 알아보려고 합니다(특히 두 번째 문장의 경우).

당신이 컴퓨터를 제어하고 그 컴퓨터의 IP 주소를 설정할 수 있다고 가정해 보겠습니다. 따라서 IP 주소 8.8.8.8을 입력합니다. 그렇게 할 수 있나요? 예.

이제 "라우팅"이 문제가 될 수 있습니다(이 답변의 뒷부분에서 자세히 설명하겠습니다). 그러나 이를 해결할 수 있는 방법이 있을 수 있습니다. 따라서 원격 끝이 ICMP 서버에 접속하여 "ping 8.8.8.8"을 실행했다고 가정해 보겠습니다. 귀하의 ICMP 서버(일반적으로 "TCP/IP 스택" 소프트웨어 구성 요소에 내장되어 있음)가 응답합니까? 예. 괜찮아요.

이 컴퓨터에서 DNS 서버와 같은 서버를 시작한다고 가정해 보겠습니다. 컴퓨터가 DNS 서버를 실행하고 응답을 받은 경우 응답할 수 있고 모든 것이 작동할 수 있습니까? 예. 괜찮아요.

HTTP 서버를 시작한다고 가정해 보겠습니다. 다른 컴퓨터가 웹 브라우저를 열고 IP 주소로 귀하의 컴퓨터와 통신하게 된다면 귀하의 컴퓨터가 응답하고 모든 것이 작동할 수 있습니까? 음... 음... 예전에는 "예"라고 대답이 나오곤 했어요. 하지만 이제 HPKP로 인해 상황이 좀 더 복잡해졌습니다. 자세한 내용은 다음을 참조하세요.HTTP 공개 키 고정에 관한 Wikipedia 웹페이지]. 그래서, 그것은 잘 작동하지 않을 수도 있습니다. 요약하자면, 널리 사용되는 웹 브라우저는 이를 공격 스타일로 간주하고 일부 세계 최고의 사이트에 대한 적절한 HTTPS 인증서/연결에 대한 세부 정보를 제공했습니다. 또 다른 관련 기술로는 HSTS("HTTP Strict Transport Security")와 관련된 "HSTS 사전 로딩"이 있습니다. 따라서 사람들이 최신 버전의 웹 브라우저를 설치하면 해당 브라우저에 일부 웹사이트에 대한 일부 세부정보가 표시될 수 있습니다. 가짜 "Google" 사이트가 예상과 일치하지 않으면 브라우저가 개입할 수 있습니다(아마도 최종 사용자에게 문제를 알릴 것입니다).

그리고 말씀하신 대로 이런 짓을 하면 해당 IP 주소로는 합법적인 사이트에 접속할 수 없게 됩니다.

자, 내가 왜 이 일을 하고 싶지 않다고 말하는 걸까요?

첫째, 더 나은 해결책이 있습니다. 장치가 DHCP를 사용하도록 합니다. 그런 다음 로컬 네트워크에서 합리적인 주소(예: FEC0:0:0:ffff::/126 또는 fd 또는 fec0으로 시작하는 IPv6 주소)에서 로컬 DNS 서버를 사용할 장소를 가리키는 DHCP 서버를 갖습니다. 또는 IETF BCP 5("RFC 1918")의 주소 범위를 사용하는 IPv4입니다. 클라이언트 시스템에 대해 이를 표준화하면 모바일 시스템이 원하는 대로 원격 및 로컬 네트워크에서 작동할 가능성이 높습니다.

예상한 대로 작업을 수행하는 데 있어 가장 큰 과제는 라우팅입니다. 192.168.55.3/24에 주소를 설정하고 192.168.55.105/24에 있는 다른 컴퓨터가 사용자와 통신을 시도하면 해당 컴퓨터는 /24(서브넷 마스크 255.255.255.0이라고도 함)를 인식하고 그 내용을 파악합니다. 처음 3개의 옥텟("192.168.55."로 시작)과 일치하는 항목은 로컬 네트워크에 있으며 직접 통신을 시도합니다.

DNS 클라이언트가 192.168.55.105/24에 있고 8.8.8.8과 통신을 시도하는 경우 컴퓨터는 8.8.8.8이 처음 세 옥텟과 일치하지 않는다는 것을 인식하므로 컴퓨터는 트래픽을 게이트웨이 장치로 보내려고 시도합니다. , 가장 일반적으로 인터넷으로 정보를 보내는 "기본 게이트웨이"입니다. (이 "게이트웨이" 장치는 로컬 네트워크에 있어야 합니다. 보다 기술적인 용어를 사용하면 게이트웨이는 동일한 서브넷에 있어야 합니다.)

따라서 컴퓨터가 8.8.8.8과 통신할 수 있도록 하기 위해 수행할 수 있는 세 가지 접근 방식이 있습니다.

클라이언트 시스템이 8.8.8.0/24 범위를 불법적으로 사용하게 만들 수 있습니다. 그렇다면 8.8.8.8이 가까워 보일 것입니다. 이렇게 하면 8.8.8.8과의 유효한 통신이 중단될 수 있으며 이 전략을 동시에 사용하여 로컬 컴퓨터가 다른 주소와 동일한 IP 범위에 있도록 할 수는 없습니다.
로컬 시스템이 192.168.55.105/24 대신 192.168.55.105/0을 사용하도록 할 수 있습니다. 이는 0.0.0.0의 서브넷 마스크를 사용하고 있음을 의미하므로 이제 컴퓨터에서 8.8.8.8이 로컬 주소임을 효과적으로 확신하게 되었습니다. 따라서 통신은 "기본 게이트웨이"로 이동하지 않고 대신 로컬 네트워크에서 직접 8.8.8.8에 도달하려고 시도합니다. 클라이언트와 서버 모두 이 작업을 수행하면 제대로 작동할 것입니다.
- 그러나 여기에 표시된 극단적인 예를 사용하면 효과적으로 수행한 작업은 모든 IP 주소가 로컬 네트워크의 일부임을 컴퓨터에 확신시키는 것입니다. 따라서 이 불법적인 방법을 통해 이제 영향을 받은 컴퓨터는 전체 인터넷이 로컬 네트워크에 있는 것처럼 처리되어야 한다고 확신하게 되었습니다. 이제 8.8.8.8의 합법적인 Google 사이트와의 통신을 끊는 대신 인터넷의 모든 합법적인 IP 주소와의 통신을 효과적으로 끊었습니다. 아야. 나쁜.
"기본 게이트웨이" 장치에 일부 사용자 정의 라우팅을 설정하여 8.8.8.8로 전송된 정보가 인터넷 서비스 공급자에게 전달되는 대신 원하는 로컬 IP 주소로 리디렉션되도록 할 수 있습니다.

세 번째 접근 방식은 이론적으로 너무 많은 문제나 원치 않는 부작용 없이 작동할 수 있지만 가장 큰 단점은 트래픽 라우팅을 처리해야 한다는 것입니다. 뭔가를 엉망으로 만들려면 먼저 잘 이해하는 것이 좋습니다.

트래픽 라우팅을 이해하는 사람으로서 나는 원하는 합법적인 연결(실제 8.8.8.8)을 성공적으로 끊으면서 동시에 끊고 싶지 않은 합법적인 연결을 끊지 않으려면 어느 정도의 전문 지식이 필요할 수 있음을 제안하고 싶습니다. 그리고 이를 수행할 수 있는 많은 전문 지식이 있다면 설정된 개인 주소에서 DNS 서버를 간단히 실행할 수 있는 전문 지식도 있을 것입니다. 그렇다면 예측하고 문제를 해결하기 어려운 이상하고 희귀한 부작용을 일으킬 가능성이 적은 표준화된 방식으로 작업을 수행하는 것은 어떨까요?

귀하가 요청한 내용과 요청한 방식에 대한 답변으로, 예, 기술적으로 이와 같은 것이 가능할 수 있습니다. 그러나 통신이 제대로 진행되지 않는 경우 이는 종종 "중간자"("MITM") 공격으로 설명된다는 점을 명심하십시오. 웹 브라우저 연결은 이미 HKPK를 지원하여 이러한 속임수를 물리칠 수 있도록 발전했습니다. 잘 알려지지 않은 사실은 DNS가 EDNS("DNS용 확장 메커니즘 사용")를 사용하는 것으로 대체되었다는 점이며, 더 널리 알려진 사실은 DNSSec라는 DNS 보안에 대한 몇 가지 새로운 향상된 기능이 있다는 것입니다. 만약 당신이 이 중 아무것도 모르고 있었다면, 현재 널리 사용되는 인터넷 기반 소프트웨어 코드의 관리자가 이미 당신보다 훨씬 앞서 있을 수 있다는 것을 깨달으십시오. 따라서 "MITM 공격"을 포함시키려고 하기 전에 이를 염두에 두는 것이 좋습니다. 당신이 감독하는 네트워크의 멋진 새로운 디자인의 중요한 부분입니다.

요약하자면, (가능성을 탐구하는 테스트 랩이 아니라) 실제 네트워크에서 이 작업을 수행하고 싶지 않다고 생각하는 주된 이유는 단순히 유용하고 합법적인 목표를 달성하기 위한 더 나은 방법이 있다는 것입니다. . 즉, 네트워크 작동 방식을 설계할 때 올바른 방식으로 작업을 수행해야 합니다. 전체적으로 통증이 덜할 것 같습니다.

이 사실을 잊은 경우를 대비해 다시 명확히 하자면, 제가 말하는 "올바른 방법"은 개인 주소에서 로컬 DNS 서버를 작동하여 아무도 속이지 않고 컴퓨터가 로컬 개인 주소를 사용하거나 DHCP에 의존하도록 장려하는 것입니다. 로컬 DHCP 서버가 장치에게 로컬 DNS 서버에 의존하도록 지시하도록 합니다. 이는 공개 사이트와의 통신 기능을 손상시키지 않는 보다 정직한 디자인 스타일이며 널리 지원되므로 인터넷 표준 관리자는 전체에서 사용되는 많은 로컬 네트워크에서 합법적인 디자인을 깨뜨리는 작업을 수행할 가능성이 적습니다. 세계.

Answer

예, 가능합니다. 아니요, 당신은 원하지 않습니다. 내가 본 다른 답변과는 달리, 그 이유에 대해 더 자세히 알아보려고 합니다(특히 두 번째 문장의 경우).

당신이 컴퓨터를 제어하고 그 컴퓨터의 IP 주소를 설정할 수 있다고 가정해 보겠습니다. 따라서 IP 주소 8.8.8.8을 입력합니다. 그렇게 할 수 있나요? 예.

이제 "라우팅"이 문제가 될 수 있습니다(이 답변의 뒷부분에서 자세히 설명하겠습니다). 그러나 이를 해결할 수 있는 방법이 있을 수 있습니다. 따라서 원격 끝이 ICMP 서버에 접속하여 "ping 8.8.8.8"을 실행했다고 가정해 보겠습니다. 귀하의 ICMP 서버(일반적으로 "TCP/IP 스택" 소프트웨어 구성 요소에 내장되어 있음)가 응답합니까? 예. 괜찮아요.

이 컴퓨터에서 DNS 서버와 같은 서버를 시작한다고 가정해 보겠습니다. 컴퓨터가 DNS 서버를 실행하고 응답을 받은 경우 응답할 수 있고 모든 것이 작동할 수 있습니까? 예. 괜찮아요.

HTTP 서버를 시작한다고 가정해 보겠습니다. 다른 컴퓨터가 웹 브라우저를 열고 IP 주소로 귀하의 컴퓨터와 통신하게 된다면 귀하의 컴퓨터가 응답하고 모든 것이 작동할 수 있습니까? 음... 음... 예전에는 "예"라고 대답이 나오곤 했어요. 하지만 이제 HPKP로 인해 상황이 좀 더 복잡해졌습니다. 자세한 내용은 다음을 참조하세요.HTTP 공개 키 고정에 관한 Wikipedia 웹페이지]. 그래서, 그것은 잘 작동하지 않을 수도 있습니다. 요약하자면, 널리 사용되는 웹 브라우저는 이를 공격 스타일로 간주하고 일부 세계 최고의 사이트에 대한 적절한 HTTPS 인증서/연결에 대한 세부 정보를 제공했습니다. 또 다른 관련 기술로는 HSTS("HTTP Strict Transport Security")와 관련된 "HSTS 사전 로딩"이 있습니다. 따라서 사람들이 최신 버전의 웹 브라우저를 설치하면 해당 브라우저에 일부 웹사이트에 대한 일부 세부정보가 표시될 수 있습니다. 가짜 "Google" 사이트가 예상과 일치하지 않으면 브라우저가 개입할 수 있습니다(아마도 최종 사용자에게 문제를 알릴 것입니다).

그리고 말씀하신 대로 이런 짓을 하면 해당 IP 주소로는 합법적인 사이트에 접속할 수 없게 됩니다.

자, 내가 왜 이 일을 하고 싶지 않다고 말하는 걸까요?

첫째, 더 나은 해결책이 있습니다. 장치가 DHCP를 사용하도록 합니다. 그런 다음 로컬 네트워크에서 합리적인 주소(예: FEC0:0:0:ffff::/126 또는 fd 또는 fec0으로 시작하는 IPv6 주소)에서 로컬 DNS 서버를 사용할 장소를 가리키는 DHCP 서버를 갖습니다. 또는 IETF BCP 5("RFC 1918")의 주소 범위를 사용하는 IPv4입니다. 클라이언트 시스템에 대해 이를 표준화하면 모바일 시스템이 원하는 대로 원격 및 로컬 네트워크에서 작동할 가능성이 높습니다.

예상한 대로 작업을 수행하는 데 있어 가장 큰 과제는 라우팅입니다. 192.168.55.3/24에 주소를 설정하고 192.168.55.105/24에 있는 다른 컴퓨터가 사용자와 통신을 시도하면 해당 컴퓨터는 /24(서브넷 마스크 255.255.255.0이라고도 함)를 인식하고 그 내용을 파악합니다. 처음 3개의 옥텟("192.168.55."로 시작)과 일치하는 항목은 로컬 네트워크에 있으며 직접 통신을 시도합니다.

DNS 클라이언트가 192.168.55.105/24에 있고 8.8.8.8과 통신을 시도하는 경우 컴퓨터는 8.8.8.8이 처음 세 옥텟과 일치하지 않는다는 것을 인식하므로 컴퓨터는 트래픽을 게이트웨이 장치로 보내려고 시도합니다. , 가장 일반적으로 인터넷으로 정보를 보내는 "기본 게이트웨이"입니다. (이 "게이트웨이" 장치는 로컬 네트워크에 있어야 합니다. 보다 기술적인 용어를 사용하면 게이트웨이는 동일한 서브넷에 있어야 합니다.)

따라서 컴퓨터가 8.8.8.8과 통신할 수 있도록 하기 위해 수행할 수 있는 세 가지 접근 방식이 있습니다.

클라이언트 시스템이 8.8.8.0/24 범위를 불법적으로 사용하게 만들 수 있습니다. 그렇다면 8.8.8.8이 가까워 보일 것입니다. 이렇게 하면 8.8.8.8과의 유효한 통신이 중단될 수 있으며 이 전략을 동시에 사용하여 로컬 컴퓨터가 다른 주소와 동일한 IP 범위에 있도록 할 수는 없습니다.
로컬 시스템이 192.168.55.105/24 대신 192.168.55.105/0을 사용하도록 할 수 있습니다. 이는 0.0.0.0의 서브넷 마스크를 사용하고 있음을 의미하므로 이제 컴퓨터에서 8.8.8.8이 로컬 주소임을 효과적으로 확신하게 되었습니다. 따라서 통신은 "기본 게이트웨이"로 이동하지 않고 대신 로컬 네트워크에서 직접 8.8.8.8에 도달하려고 시도합니다. 클라이언트와 서버 모두 이 작업을 수행하면 제대로 작동할 것입니다.
- 그러나 여기에 표시된 극단적인 예를 사용하면 효과적으로 수행한 작업은 모든 IP 주소가 로컬 네트워크의 일부임을 컴퓨터에 확신시키는 것입니다. 따라서 이 불법적인 방법을 통해 이제 영향을 받은 컴퓨터는 전체 인터넷이 로컬 네트워크에 있는 것처럼 처리되어야 한다고 확신하게 되었습니다. 이제 8.8.8.8의 합법적인 Google 사이트와의 통신을 끊는 대신 인터넷의 모든 합법적인 IP 주소와의 통신을 효과적으로 끊었습니다. 아야. 나쁜.
"기본 게이트웨이" 장치에 일부 사용자 정의 라우팅을 설정하여 8.8.8.8로 전송된 정보가 인터넷 서비스 공급자에게 전달되는 대신 원하는 로컬 IP 주소로 리디렉션되도록 할 수 있습니다.

세 번째 접근 방식은 이론적으로 너무 많은 문제나 원치 않는 부작용 없이 작동할 수 있지만 가장 큰 단점은 트래픽 라우팅을 처리해야 한다는 것입니다. 뭔가를 엉망으로 만들려면 먼저 잘 이해하는 것이 좋습니다.

트래픽 라우팅을 이해하는 사람으로서 나는 원하는 합법적인 연결(실제 8.8.8.8)을 성공적으로 끊으면서 동시에 끊고 싶지 않은 합법적인 연결을 끊지 않으려면 어느 정도의 전문 지식이 필요할 수 있음을 제안하고 싶습니다. 그리고 이를 수행할 수 있는 많은 전문 지식이 있다면 설정된 개인 주소에서 DNS 서버를 간단히 실행할 수 있는 전문 지식도 있을 것입니다. 그렇다면 예측하고 문제를 해결하기 어려운 이상하고 희귀한 부작용을 일으킬 가능성이 적은 표준화된 방식으로 작업을 수행하는 것은 어떨까요?

귀하가 요청한 내용과 요청한 방식에 대한 답변으로, 예, 기술적으로 이와 같은 것이 가능할 수 있습니다. 그러나 통신이 제대로 진행되지 않는 경우 이는 종종 "중간자"("MITM") 공격으로 설명된다는 점을 명심하십시오. 웹 브라우저 연결은 이미 HKPK를 지원하여 이러한 속임수를 물리칠 수 있도록 발전했습니다. 잘 알려지지 않은 사실은 DNS가 EDNS("DNS용 확장 메커니즘 사용")를 사용하는 것으로 대체되었다는 점이며, 더 널리 알려진 사실은 DNSSec라는 DNS 보안에 대한 몇 가지 새로운 향상된 기능이 있다는 것입니다. 만약 당신이 이 중 아무것도 모르고 있었다면, 현재 널리 사용되는 인터넷 기반 소프트웨어 코드의 관리자가 이미 당신보다 훨씬 앞서 있을 수 있다는 것을 깨달으십시오. 따라서 "MITM 공격"을 포함시키려고 하기 전에 이를 염두에 두는 것이 좋습니다. 당신이 감독하는 네트워크의 멋진 새로운 디자인의 중요한 부분입니다.

요약하자면, (가능성을 탐구하는 테스트 랩이 아니라) 실제 네트워크에서 이 작업을 수행하고 싶지 않다고 생각하는 주된 이유는 단순히 유용하고 합법적인 목표를 달성하기 위한 더 나은 방법이 있다는 것입니다. . 즉, 네트워크 작동 방식을 설계할 때 올바른 방식으로 작업을 수행해야 합니다. 전체적으로 통증이 덜할 것 같습니다.

이 사실을 잊은 경우를 대비해 다시 명확히 하자면, 제가 말하는 "올바른 방법"은 개인 주소에서 로컬 DNS 서버를 작동하여 아무도 속이지 않고 컴퓨터가 로컬 개인 주소를 사용하거나 DHCP에 의존하도록 장려하는 것입니다. 로컬 DHCP 서버가 장치에게 로컬 DNS 서버에 의존하도록 지시하도록 합니다. 이는 공개 사이트와의 통신 기능을 손상시키지 않는 보다 정직한 디자인 스타일이며 널리 지원되므로 인터넷 표준 관리자는 전체에서 사용되는 많은 로컬 네트워크에서 합법적인 디자인을 깨뜨리는 작업을 수행할 가능성이 적습니다. 세계.

Question 4

이론적으로는 괜찮을 것입니다.

실제로:

제3자의 가정을 깨뜨릴 수 있습니다.
잘 알려진 특정 IP 규칙이 유지된다고 가정하는 소프트웨어/하드웨어를 사용할 수 있으며, 이러한 가정을 위반하면 의도하지 않은 동작이 발생할 수 있습니다.
숨겨진 버그를 유발할 수 있습니다.
일부 버그가 있는 소프트웨어는 대부분의 경우 잘 작동하지만 이상한 세부 사항으로 인해 문제가 발생할 수 있습니다. 이러한 버그는 발견되면 수정될 수 있지만, 비표준 구성을 사용하는 경우 이전에 누구도 접할 기회가 없었던 버그가 발생할 가능성이 높아질 수 있습니다.
귀하의 네트워크로 작업하는 다른 사람들을 혼란스럽게 할 수 있습니다.
8.8.8.8내부 네트워크의 다른 의미를 기억하는 것이 괜찮더라도 이는 잠재적으로 다른 사람들을 혼란스럽게 할 수 있습니다. 동료, 기술 지원 담당자, 도움말 포럼에서 공유할 수 있는 로그를 읽는 사람들 등이 문제를 겪을 수 있습니다.
캐시에 모순이 생길 수 있습니다.
네트워크의 장치가 이전에 글로벌 인터넷에 연결된 경우 설정, 방화벽 규칙 등에 IPv4 주소가 저장되어 로컬 네트워크에 연결할 때 원치 않는 충돌이 발생할 수 있습니다.

이론적으로는 서드파티 디자인과 버그가 귀하의 잘못이 아닐 수도 있습니다. 그러나 실제로는당신은 유령을 믿기 시작할 수도 있습니다.

Answer

이론적으로는 괜찮을 것입니다.

실제로:

제3자의 가정을 깨뜨릴 수 있습니다.
잘 알려진 특정 IP 규칙이 유지된다고 가정하는 소프트웨어/하드웨어를 사용할 수 있으며, 이러한 가정을 위반하면 의도하지 않은 동작이 발생할 수 있습니다.
숨겨진 버그를 유발할 수 있습니다.
일부 버그가 있는 소프트웨어는 대부분의 경우 잘 작동하지만 이상한 세부 사항으로 인해 문제가 발생할 수 있습니다. 이러한 버그는 발견되면 수정될 수 있지만, 비표준 구성을 사용하는 경우 이전에 누구도 접할 기회가 없었던 버그가 발생할 가능성이 높아질 수 있습니다.
귀하의 네트워크로 작업하는 다른 사람들을 혼란스럽게 할 수 있습니다.
8.8.8.8내부 네트워크의 다른 의미를 기억하는 것이 괜찮더라도 이는 잠재적으로 다른 사람들을 혼란스럽게 할 수 있습니다. 동료, 기술 지원 담당자, 도움말 포럼에서 공유할 수 있는 로그를 읽는 사람들 등이 문제를 겪을 수 있습니다.
캐시에 모순이 생길 수 있습니다.
네트워크의 장치가 이전에 글로벌 인터넷에 연결된 경우 설정, 방화벽 규칙 등에 IPv4 주소가 저장되어 로컬 네트워크에 연결할 때 원치 않는 충돌이 발생할 수 있습니다.

이론적으로는 서드파티 디자인과 버그가 귀하의 잘못이 아닐 수도 있습니다. 그러나 실제로는당신은 유령을 믿기 시작할 수도 있습니다.

인터넷 없이도 글로벌 IP 주소를 사용할 수 있나요?

답변1

답변2

답변3

답변4

관련 정보