특정 프로세스를위한 백업 인터넷 연결

Aug 17 2020

Linux 서버에 보조 백업 인터넷 연결을 추가하고 싶습니다. 이를 위해 USB LTE 모뎀을 사용할 계획입니다.

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

변경할 수있는 사용자 지정 서버 응용 프로그램이 있습니다. 중단없는 연결이 중요한 몇 가지 작업과 다운 타임이 실제로 중요하지 않은 다른 작업이 있습니다.

나는 다음과 같은 것을 상상하고있다.

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

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

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

답변

josh3736 Sep 01 2020 at 03:53

백업 인터페이스의 소스 주소에 대한 대체 라우팅 테이블 과 라우팅 정책 규칙 을 구성하여이를 달성했습니다 .

제가 가지고있는 USB LTE 모뎀은 NDIS 장치로 제공되므로 eth1IP 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) { … });