CS/Network

ifconfig 명령어 및 네트워크 인터페이스 카드

prden 2024. 9. 22. 14:58

1. ifconfig로 퍼블릭 아이피, 로컬 아이피

the ifconfig command does not display your public IP address. It only shows the local IP addresses assigned to your network interfaces, like the ones on your LAN (Local Area Network) or loopback interface.

 

Here’s a quick explanation of why:

 

1. Local IP addresses (Private IPs): These are the addresses you see in the ifconfig output, such as 192.168.x.x or 172.x.x.x. These are used within your local network and are not directly visible to the outside world. For example, 192.168.0.108 in your output is your local IP on the Ethernet interface.

2. Public IP address: This is the IP address assigned to your router (or network device) by your Internet Service Provider (ISP) for communication over the internet. It is not shown in ifconfig because ifconfig only shows the addresses of your machine’s interfaces on the internal network.

 

퍼블릭 아이피 확인

curl ifconfig.me

 

2. ifconfig 확인 - 네트워크 인터페이스 카드 

 

1. br-a336ff40d8cd and br-b16b276dfbfa:

These interfaces are bridge interfaces, typically created by Docker or similar virtualization tools. A bridge interface connects multiple network interfaces together, allowing communication between containers and the host.

inet: Shows the IP address assigned to this bridge interface. For example, 172.19.0.1 and 172.18.0.1 are the IP addresses for br-a336ff40d8cd and br-b16b276dfbfa, respectively.

ether: This represents the MAC (Media Access Control) address of the interface, a unique identifier for network interfaces used in Ethernet communications.

These bridges are likely being used for networking between containers, with their IP ranges (172.x.x.x) often used in private internal network

  • the br-* interfaces in your ifconfig output are created by Docker or Docker Compose. These bridge interfaces are used by Docker to manage networking between containers and the host machine.
  •  

 

2. docker0:

Another bridge interface, docker0 is the default Docker bridge. Docker uses this bridge to route container traffic from the host to the external network.

inet: IP address assigned to this interface is 172.17.0.1, which is within Docker’s default subnet range.

ether: The MAC address for this interface is 02:42:b3:90:07:28.

Like the other bridges, this interface enables container networking.

 

3. enp3s0:

This is likely the physical Ethernet network interface on your machine. It’s the actual hardware that connects to your local network (wired Ethernet connection).

inet: The IP address 192.168.0.108 is the IP assigned to this interface by your router in the local network.

inet6: This is the IPv6 address for this interface (fe80::4fd2:f37b:47b7:e95f), used for communication over IPv6 networks.

ether: The MAC address 7c:10:c9:d3:1b:ee identifies this physical network interface card (NIC).

The RX and TX fields show the received and transmitted packets, indicating network traffic passing through this NIC.

 

4. lo (Loopback interface):

lo is the loopback interface. It is a special network interface used for local machine communication.

inet: 127.0.0.1 is the loopback IP address (also known as “localhost”), used to communicate with services running on the same machine.

inet6: ::1 is the loopback address for IPv6.

Traffic sent to this interface only travels within your local machine and does not leave your device.

 

2-1) Loopback is why Loopback

 

The term “loopback” refers to a special network interface used to route traffic back to the same device that sent it. It is a logical network interface that allows the system to communicate with itself, commonly used for testing and local inter-process communication.

 

Why is it called “Loopback”?

 

The word “loopback” comes from the idea of “looping back” network traffic:

 

“Loop”: A loop is a circular path, meaning the data goes out and comes right back.

“Back”: Refers to the fact that the data is sent back to the same system, rather than being transmitted to another device over the network.

 

Essentially, the data sent to the loopback interface loops back to the machine itself, instead of leaving the machine.

 

Practical Uses of Loopback:

 

1. Local Communication: The loopback interface allows applications running on the same machine to communicate with each other using the networking stack without the need for a physical network connection. For example, web servers like Apache or Nginx can be accessed at 127.0.0.1 (localhost) to test locally without going over the network.

2. Testing: Developers often use the loopback interface to test network applications and services without involving external networks.

3. Localhost: The IP address 127.0.0.1 (for IPv4) or ::1 (for IPv6) is reserved for the loopback interface. It is commonly known as localhost, and any traffic sent to this address is routed back to the same machine.

 

Example:

 

When you ping 127.0.0.1 or localhost, the traffic is sent out and immediately returned to your system, demonstrating that the network stack is functioning correctly. It’s a quick way to test if the local network configuration is working.

 

Why It’s Special:

 

Unlike other network interfaces that connect to external networks, the loopback interface does not require any physical hardware and exists purely for internal communication within the machine. It ensures that the system can route data to itself without needing a real network card or external connection.

 

3. http://localhost VS. http:127.0.0.1

 

The issue where http://localhost doesn’t work while http://127.0.0.1 does, especially in browser testing modes (like mobile testing mode), is due to the differences between how localhost and 127.0.0.1 are resolved and handled by various systems and configurations.

 

Key Differences Between localhost and 127.0.0.1:

 

1. Name Resolution:

localhost is a hostname that the operating system needs to resolve to an IP address (usually to 127.0.0.1 for IPv4 or ::1 for IPv6). This resolution is handled either by a system’s DNS resolver or through the hosts file (e.g., /etc/hosts on Linux and macOS or C:\Windows\System32\drivers\etc\hosts on Windows).

127.0.0.1 is the direct IP address of the loopback interface and doesn’t require name resolution.

2. Network Stack Handling:

Some applications or network configurations treat localhost and 127.0.0.1 differently. localhost can sometimes be affected by DNS settings, browser behavior, or even firewall rules.

Mobile testing modes (or virtual devices) in browsers might treat localhost as a device-specific name that resolves differently in a mobile or isolated environment.

 

Reasons localhost Might Not Work While 127.0.0.1 Does:

 

1. DNS or Hosts File Issues:

The localhost name might not resolve properly due to a misconfigured hosts file or other name resolution issues.

If localhost is missing or incorrectly mapped in the hosts file, it won’t resolve to 127.0.0.1.

2. IPv6 vs. IPv4:

Modern systems might try to resolve localhost to the IPv6 address ::1 by default, but if your server is only listening on an IPv4 interface (127.0.0.1), it won’t work.

127.0.0.1 forces an IPv4 connection, while localhost could attempt either IPv6 (::1) or IPv4, depending on the configuration.

3. Browser Behavior in Testing Modes:

When testing in mobile emulation mode, some browsers or virtual machines might treat localhost as a special name and may not map it correctly to 127.0.0.1. This can be due to isolation or containerization of the test environment.

Mobile emulation modes may use different internal DNS settings that affect how localhost resolves compared to 127.0.0.1.

4. Proxy or Firewall Settings:

If you’re using any proxies or firewalls, they might behave differently for localhost versus 127.0.0.1. For instance, localhost traffic might be blocked or rerouted through a proxy, while 127.0.0.1 goes directly to the loopback interface.

 

How to Fix or Investigate:

 

1. Check the Hosts File:

Ensure that localhost is correctly mapped to 127.0.0.1 in your system’s hosts file. For example:

127.0.0.1 localhost
::1       localhost

 

2. Force IPv4 in Your Application:

If you suspect IPv6 is causing the issue, ensure your application is bound to both IPv4 and IPv6, or specifically to 127.0.0.1.

3. Try Disabling Proxies:

If you’re using a browser with mobile testing mode, check if there are any proxy settings enabled that might treat localhost differently.

4. Use 127.0.0.1 Directly:

In cases where localhost doesn’t work and you need to test quickly, just use http://127.0.0.1 directly in your browser.

 

Summary:

 

localhost might not work in certain scenarios because of DNS resolution issues, IPv6/IPv4 mismatches, or browser-specific handling in testing modes.

Using 127.0.0.1 bypasses these issues since it is a direct IP address that doesn’t require name resolution and explicitly uses IPv4.

 

* DNS name resolution

 - name resolution : 도메인 이름에 대응하는 IP 주소 찾아내는 작업

'CS > Network' 카테고리의 다른 글

Capturing network requests  (1) 2024.09.21
Telnet vs. SSH  (1) 2024.09.21
세션 클러스터링  (1) 2024.09.15
우분투 Wake on Lan 설정  (0) 2024.09.11
프론트는 https로 서비스, apiserver는 http 프로토콜일 경우  (0) 2023.09.19