LTE VPN 링크 위의 EoIP: 작은 RouterOS 실습실 만들기

EoIP는 완전한 Ethernet 프레임을 받아 GRE로 감싸 구성된 원격 주소로 보내며, 그래서 결과는 경로가 아니라 케이블처럼 동작한다. 라우터를 나가는 것은 원본 프레임을 페이로드로 가진 IP 프로토콜 47이며, 따라서 브로드캐스트와 ARP, 비IP 프로토콜이 모두 지나간다. GRE는 자체적인 기밀성을 더하지 않으며, 프레임은 바깥 패킷을 볼 수 있는 무엇에게나 읽히는 상태로 남는다. 이 한 가지 사실이 이 실습의 순서를 정한다. 먼저 암호화된 경로를 만들고, 그 안에서 Ethernet을 나른다.

EoIP가 감싸는 것과 감싸지 않는 것

캡슐화가 전체 메커니즘이다. 프레임이 브리지된 포트에 도착해 GRE 헤더와 외부 IP 헤더를 얻고 상대 라우터로 전달되면, 상대는 둘 다 벗겨 내고 프레임을 자기 브리지에 주입한다. 받는 브리지는 출발지 MAC을 마치 로컬 포트에서처럼 정확히 학습한다. 그 과정에서 프레임을 인증하거나 숨기는 것은 없다.

따라서 기밀성은 GRE 패킷이 지나는 경로에서 와야 한다. 이 설계에서 하위 계층은 두 라우터 사이의 WireGuard 또는 IPsec 터널이고, EoIP는 그 안에서 운반된다. MikroTik은 EoIP 인터페이스 자체에도 자동 IPsec 옵션을 제공하지만, 그것은 다른 구성이며 이 실습이 설정하는 것이 아니다.

라우팅된 IP 서비스에는 라우팅된 VPN이 더 작은 설계이고 우선할 것이다. 장치가 정말로 다른 사이트의 Ethernet 프레임을 봐야 할 때만 두 번째 계층으로 손을 뻗어라.

전제 조건: 암호화된 하위 계층과 사용하지 않는 포트 두 개

두 라우터 모두 확립된 암호화 링크와 상대가 도달할 수 있는 그 위의 주소가 필요하다. 외부 연결은 LTE 쪽이 시작하므로 허브는 모바일 네트워크에 절대 걸지 않고, LTE 라우터는 통신사가 요구하는 NAT 상태를 유지한다. 그 위에 무엇이든 더하기 전에 터널이 살아 있는지 확인하라. 원격 주소에 도달하지 못하는 EoIP 인터페이스는 잘못 구성된 것과 똑같이 보이기 때문이다.

각 라우터에는 이미 브리지 멤버도, VLAN 트렁크도, 관리 인터페이스도, 운영 링크도 아닌 포트가 하나 필요하다. 살아 있는 포트를 빌리는 실습은 실습이 아니며, 그 실패 모드는 운영 중인 네트워크의 브로드캐스트 폭풍이다. 시작하기 전에 관리를 다른 인터페이스나 콘솔로 옮겨라.

Hub tunnel address:    10.44.7.1/32
LTE tunnel address:    10.44.7.2/32
Lab ports:             ether7 on both routers, unused
Test hosts:            192.168.77.11/24 and 192.168.77.12/24

그 값들은 예시이지 요구 사항이 아니다. 터널 인터페이스 위에 있어야 하고 보호된 경로로 라우팅되어야 한다. 두 라우터의 방화벽 정책은 두 터널 주소 사이의 GRE를 허용해야 하며, GRE는 IP 프로토콜 47이지 47번 TCP나 UDP 포트가 아니다. 이 설계는 원시 GRE를 어느 WAN에도 노출하지 않는다.

일치하는 ID로 터널 쌍을 만든다

양 끝은 두 번 정의되는 하나의 논리 인터페이스이므로 모든 식별 필드가 일치해야 한다. 허브에서:

/interface eoip add name=eoip-lab local-address=10.44.7.1 remote-address=10.44.7.2 tunnel-id=37 mac-address=02:1A:2B:00:00:01

LTE 라우터에서는 주소가 뒤바뀌고 MAC이 다르다:

/interface eoip add name=eoip-lab local-address=10.44.7.2 remote-address=10.44.7.1 tunnel-id=37 mac-address=02:1A:2B:00:00:02

터널 ID는 양 끝에서 일치해야 하고 어느 라우터에든 이미 구성된 다른 쌍과 충돌해서는 안 된다. MAC 주소는 로컬 관리 값이며 합류하는 두 번째 계층 도메인 안에서 고유해야 하므로, 벤더 예제의 값을 재사용하지 마라. 인터페이스 이름은 각 라우터에 로컬이며 자신의 스크립트에 대해서만 일관되면 된다.

현재 EoIP 매뉴얼은 엔드포인트와 터널 ID 필드를 문서화하고 EoIP가 GRE 위의 Ethernet임을 분명히 밝힌다. 그 명령에서 무엇도 암호화하지 않으므로 하위 계층 점검이 먼저다.

테스트 포트만 브리지한다

브리지가 터널을 세그먼트로 만들며, 그 구성이 안전 경계의 전부다. 허브에서:

/interface bridge add name=br-eoiphub protocol-mode=rstp auto-mac=no admin-mac=02:1A:2B:00:01:01
/interface bridge port add bridge=br-eoiphub interface=ether7
/interface bridge port add bridge=br-eoiphub interface=eoip-lab

LTE 라우터에서:

/interface bridge add name=br-eoiplte protocol-mode=rstp auto-mac=no admin-mac=02:1A:2B:00:01:02
/interface bridge port add bridge=br-eoiplte interface=ether7
/interface bridge port add bridge=br-eoiplte interface=eoip-lab

이 명령들은 새 브리지를 만들고 각각에 정확히 두 개의 포트를 더한다. EoIP 인터페이스가 두 번째 계층 멤버이고, 암호화된 터널은 라우팅된 전송으로 남아야 하며 절대 브리지 포트로 추가해서는 안 된다. 운영 포트를 추가하지 말고 실습 브리지에서 DHCP 서버를 시작하지 마라.

두 테스트 호스트에 경쟁 DHCP 서버가 없는 사용하지 않는 서브넷의 주소를 주어라. 예를 들어 192.168.77.11/24와 192.168.77.12/24다. 그 서브넷 안에서 서로에게 도달하는 데 기본 게이트웨이가 필요 없고, 프레임이 지나는 데 라우터 인터페이스 주소도 필요 없다.

LAN을 확장하기 전에 오버헤드를 계산하라

IPv4 위의 EoIP는 운반되는 페이로드 주위에 Ethernet, GRE, 외부 IP 헤더를 더한다. 태그가 없는 경우에 대해 MikroTik은 42바이트를 문서화하며, 따라서 사용 가능한 IP MTU가 1400바이트인 하위 계층은 내부 프레임에 1358바이트를 남긴다. 그 숫자는 예산이지 보편적인 MSS 값이 아니며, 브리지된 호스트가 더 작은 프레임을 내보내도록 강제하지 않는다.

경로의 실제 한계를 확인한 뒤 장치가 실제로 보내는 가장 큰 프레임으로 시험하라. 보호된 경로 안에서 분할해야 하는 1500바이트 프레임은 들어가는 프레임과 다르게 동작하며, 그 차이는 링크 장애가 아니라 응용 프로그램 멈춤으로 나타난다.

/interface eoip print detail where name=eoip-lab
/interface bridge host print where bridge=br-eoiphub
/ping 192.168.77.12 count=4 interface=br-eoiphub

RSTP는 루프를 다루지 임의의 병렬 경로를 다루지 않으므로 파일럿 토폴로지를 단순하게 유지하라. 브리지를 확장하면 브로드캐스트와 멀티캐스트, DHCP 동작도 모바일 링크 너머로 확장되며, 그 트래픽은 쓸모 있는 프레임이 오가든 아니든 용량을 소비한다.

운영 연결은 실습이 정말로 필요한 프레임 크기와 응용 동작에 도달한 뒤에만 계획하라. 그 전환 전에 주소 지정, VLAN 소속, DHCP 권한, 루프 방지, 그리고 링크 자체가 끊겼을 때 누군가 라우터에 어떻게 도달하는지를 합의하라. Ethernet 확장은 장치뿐 아니라 장애 도메인도 연결하므로, 운영 중인 브리지에 포트 하나를 더하는 대신 변경 창을 마련할 가치가 있다.