☰

특정 프로세스에 대한 인터넷 연결 백업

tag-icon • tag-icon linux networking
특정 프로세스에 대한 인터넷 연결 백업

내 Linux 서버에 보조 백업 인터넷 연결을 추가하고 싶습니다. 저는 이 목적으로 USB LTE 모뎀을 사용할 계획입니다.

이 셀룰러 연결은 측정되기 때문에 소비할 수 있는 데이터 양을 필요한 최소값으로 제한하고 싶습니다.

변경할 수 있는 사용자 정의 서버 애플리케이션이 있습니다. 중단 없는 연결이 중요한 몇 가지 작업과 가동 중지 시간이 실제로 중요하지 않은 다른 작업이 있습니다.

나는 다음과 같은 것을 상상하고 있습니다 :

  • 서버는 외부 HTTP API 요청을 해야 합니다. 첫 번째 시도는 시스템의 기본 경로(예: 기본 인터넷 연결인 eth0)를 통해 이루어집니다.
  • 요청이 실패하거나 시간 초과되면 LTE 인터페이스를 통해 요청을 다시 시도하세요.

내 서버 프로세스가 명시적으로 LTE를 통해 전송하려는 트래픽만 LTE를 통해 전송되어야 합니다. 시스템의 어떤 부분에서도 다른 트래픽이 LTE를 통과해서는 안 됩니다.

  • 특히 노드를 사용하겠습니다.localAddress요청이 LTE를 통해 이루어져야 함을 지정하는 소켓 옵션입니다.
  • 다른 트래픽이 LTE 인터페이스를 통해 라우팅되지 않도록 하려면 어떻게 해야 합니까(eth0이 다운된 경우에도)?
  • DNS 확인은 어떻습니까?

답변1

나는 결국 이것을 구성하여 이것을 달성했습니다.대체 경로 테이블그리고라우팅 정책 규칙백업 인터페이스의 소스 주소입니다.

eth1제가 가지고 있는 USB LTE 모뎀은 NDIS 장치로 표시되므로 단순히 IP가 192.168.0.190인 것처럼 표시되고 내부적으로 NAT 라우팅을 수행합니다. eth1고정 IP로 구성 하고 경로를 수동으로 구성했습니다.

  1. 기본 구성에서는 DHCP를 사용하므로 인터페이스를 종료하고 자동으로 추가된 경로가 모두 삭제되었는지 확인하세요.

  2. 인터페이스에 대한 고정 IP 구성을 추가하고 불러옵니다.

  3. 1서브넷 및 기본 게이트웨이에 대한 대체 라우팅 테이블(저는 선택함)에 항목을 추가합니다 .

    # ip route add 192.168.0.0/24 dev eth1 src 192.168.1.190 table 1
# ip route add default via 192.168.0.1 table 1

  4. 192.168.1.190을 소스 주소로 명시적으로 사용하는 앱이 기본값 대신 라우팅 테이블 1을 사용하도록 라우팅 정책 규칙을 설정합니다.

    # ip rule add from 192.168.0.190/32 table 1
# ip rule add to 192.168.0.190/32 table 1

이 시점에서 연결을 테스트할 수 있어야 합니다.

$ curl https://wtfismyip.com/text
1.2.3.4  # primary ISP external IP
$ curl --interface 192.168.0.190 https://wtfismyip.com/text
5.6.7.8  # backup LTE external IP

모든 것이 좋아 보인다면 구성을 영구적으로 만드십시오. 나는 다음에 추가했다 /etc/network/interfaces:

iface eth1 inet static
        address 192.168.0.190
        netmask 255.255.255.0
        post-up ip route add 192.168.0.0/24 dev eth1 src 192.168.0.190 table 1
        post-up ip route add default via 192.168.0.1 table 1
        post-up ip rule add from 192.168.0.190/32 table 1
        post-up ip rule add to 192.168.0.190/32 table 1

이제 나가는 연결을 만들 때 192.168.0.190에 명시적으로 바인딩하는 앱만 백업 연결을 통해 라우팅됩니다. 다른 모든 트래픽은 eth0(또는 [기본] 라우팅 테이블에 구성된 모든 것 main) 라우팅됩니다.

그것은가능한사용 가능한 모든 IP를 열거하고 그로부터 트래픽을 보내려고 시도하는 것이 있어서 백업 연결을 통해 예기치 않은 트래픽이 발생할 수 있지만 그럴 가능성은 거의 없습니다. 나는 그러한 트래픽을 관찰하지 못했습니다.

이는 DNS 확인을 다루지 않습니다. 기본 연결이 오프라인인 상황에서는 운이 좋게도 캐시에서 조회를 얻을 수 있지만 이에 의존하는 것은 좋지 않습니다. LTE 인터페이스를 통해 요청을 보내도록 시스템 전체 확인자를 구성하지 않을 것입니다. 대신 앱에서 백업 요청 시 DNS 확인을 수동으로 처리할 수 있습니다.

노드를 사용하면 특정 소스 주소에서 HTTP 요청(또는 TCP 연결)을 만드는 것이 쉽습니다. 간단히 지정localAddress옵션, 예:

https.get('https://wtfismyip.com/text', { localAddress: '192.168.0.190' }, …);

DNS 조회를 해결하는 것은 약간 까다롭습니다. lookup기본 DNS 확인 프로세스를 재정의할 수 있는 옵션도 사용할 수 있습니다 . 사용자 정의를 사용할 수 있습니다dns.Resolver조회를 하려고 합니다. 안타깝게도 노드에는 DNS 조회를 위한 소스 주소를 지정할 수 있는 방법이 없었습니다.그래서 추가했어요. 그 자리에 조각들을 하나로 모을 수 있습니다:

const resolver = new dns.Resolver();
resolver.setServers(['8.8.8.8']);
resolver.setLocalAddress('192.168.0.190'); // requires node > v15.0.0

https.get('https://wtfismyip.com/text', {
  localAddress: '192.168.0.190',
  lookup: function(hostname, opts, cb) {
    resolver.resolve(hostname, function(err, records) {
      if (err) cb(err);
      else if (!records[0]) cb(new Error('Missing DNS record'));
      else cb(null, records[0], 4);
    });
  }
}, function(res) { … });

관련 정보