ISP와 휴대폰 인터넷 액세스를 병합 할 수 있습니까? 다운로드 및 업로드를 분할하고 싶습니다. [중복]

ISP를 다운로드 전용으로 사용하고 휴대폰 4G 연결을 업로드 전용으로 사용하고 싶습니다. ISP의 업로드 속도는 좋지 않지만 다운로드는 양호하고 4G 업로드는 훌륭하고 무료입니다 (다운로드 비용 만 지불).

따라서 하나의 PC, 두 개의 연결 : 다운로드 용 ISP 및 업로드 용 4G. 이렇게하면 오늘과 동일한 비용을 지불하지만 업로드를 0.1Mbit / s에서 약 60Mbit / s로 늘리십시오.

연결간에 업로드와 다운로드를 분리하는 것은 사실상 불가능하지만 (다른 답변에 자세히 설명 된대로) 수동 해결 방법이있을 수 있습니다.

시작하려는 작업에 따라 기본 연결을 조작하여 전환 할 수 있습니다. Windows의 기본 연결은 먼저 연결된 인터페이스이며, 순서는 미터법 으로 계산됩니다 (이는 무선을 케이블 위에 배치하는 경향이 있음).

네트워크 연결의 고급 설정 : Windows에서 기본 연결을 변경하는 방법 에서 수동 순서로 메트릭을 쉽게 무시할 수 있습니다 . (사소한 차이없이 XP에서 8.1로 동일하게 작동해야 함)

대부분의 최신 프로그램은 시스템에서 제공하는 기본 연결을 사용하며 연결이 설정된 후에는 연결을 유지해야합니다. 일반적으로 프로그램을 시작할 때 기본값으로 설정된 연결을 사용합니다. 연결을 열기 전에 기본 연결을 전환하면 작업에 따라 연결을 전환하고 동시에 열어 둘 수 있습니다.

일부 프로그램 (예 : 다운로드 / 업로드 관리자)은 세션이 아닌 작업별로 연결을 열므로 마일리지가 다를 수 있습니다.

이건 불가능 해. 승인은 전송 제어 프로토콜의 필수 부분입니다. 수신 및 발신 데이터를 두 인터페이스간에 명확하게 분리하면 프로토콜의 승인 구성 요소가 기본적으로 비활성화됩니다.

TCP는 연결 지향 프로토콜입니다. 즉, 각 끝에있는 응용 프로그램이 메시지 교환을 완료 할 때까지 연결이 설정되고 유지됩니다. 네트워크가 전달할 수있는 패킷으로 응용 프로그램 데이터를 분리하는 방법을 결정하고, 네트워크 계층에서 패킷을 전송 및 수신하고, 흐름 제어를 관리하며, 오류없는 데이터 전송을 제공하기 때문에 손실되거나 깨진 패킷의 재전송을 처리합니다. 도착하는 모든 패킷의 승인. OSI (Open Systems Interconnection) 통신 모델에서 TCP는 전송 계층 4 계층의 일부와 세션 계층 5 계층의 일부를 다룹니다.

라우터는 별도의 인터페이스간에 네트워크로드 밸런싱을 구현할 수 있지만 일반적으로 해싱에서 작동합니다. 이는 해싱 알고리즘을 기반으로 지정된 인터페이스에서 연결이 설정되고 종료 될 때까지 해당 인터페이스에서 유지됨을 의미합니다. 값 비싼 라우터 일지라도 완료 될 때까지 설정된 연결을 유지하려면 각 인터페이스가 필요합니다.

추가 : 가능할 수도 있지만 구현 범위로 인해 비현실적입니다. 또한 모든 트래픽을 모바일 테더로 오프로드 할 수 있다고해도 ISP가 서비스 약관을 업데이트하기까지 얼마나 걸릴 것이라고 생각하십니까? 이미 어딘가에 공정 사용 정책이있을 수 있습니다. 요구 사항은 다음과 같습니다.

• ISP 연결을 통해 되돌아 오는 ISP 연결을 통해 나가는 트래픽의 트래픽과 일치하도록 모바일 테더를 통해 나가는 트래픽의 위장 소스 IP. 이것은 iptables로 수행 할 수 있습니다.
• 모바일 티터를 통해 로컬 트래픽을 라우팅합니다. '경로 추가 192.168.0.0/16 마스크 255.255.0.0 [모바일 테더의 외부 IP]. 이 업데이트를 자주 업데이트하지 않으려면 DDNS를 실행하십시오.

http://lartc.org/howto/lartc.rpdb.multiple-links.html

https://sandilands.info/sgordon/address-spoofing-with-iptables-in-linux

ISP를 크게 활용하려면 BGP를 사용하여 비대칭 라우팅을 살펴보십시오.

두 인터넷 액세스를 모두 사용하여 다운로드 / 업로드의 부하를 공유 할 수 있지만 항상 연결마다 가능합니다. 따라서 하나의 TCP (또는 UDP) 연결은 하나의 링크를 통해서만 갈 수 있습니다. 이것은 다른 답변에서도 언급됩니다. 나가는 TCP 패킷의 경우 승인 패킷을 수신해야하며 동일한 인터페이스를 통해 전달되어야합니다.

예를 들어 큰 YouTube 업로드를 수행하기 전에 라우팅 테이블을 수동으로 변경하여 인터넷을 통해 모든 YouTube 트래픽을 더 빠른 업로드 속도로 전환 한 다음 다시 변경할 수 있습니다. 그러나 유튜브가 많은 다른 IP 주소를 사용하기 때문에 어려울 것입니다 (라우팅은 호스트 이름이 아닌 IP에서 작동합니다). 그러나 일부 회사 FTP 서버의 경우 가능할 수 있습니다.

이것은 ISP로부터 IP 주소를받는 모든 가정 인터넷 액세스에 적용됩니다. 따라서 첫 번째 ISP에는 IP 1.2.3.4가 표시되지만 휴대 전화에는 전화 네트워크 사업자의 IP (예 : 5.6.7.8)가 표시됩니다. 전체 연결 (수신 및 수신 데이터)은 해당 IP 주소 중 하나만 사용해야합니다.

인터넷을 호스팅하는 상업용 및 서버의 경우 ISP와 독립적 인 하나의 IP 주소를 얻을 수 있으므로 더 많은 인터넷 연결을 동시에 사용할 수 있습니다.

업스트림 및 다운 스트림 트래픽에 대해 서로 다른 엔드 포인트를 지원하는 오버레이 (터널) 연결이 있어야합니다. 내가 아는 유일한 프로토콜은 기본적으로 LISP (Locator Identifier Separation Protocol)입니다. 가까운 곳에서 LISP ISP를 찾을 수 있다면 현재 연결 외에 그로부터 서비스를 구입할 수 있습니다. 아마 무료가 아닐 것입니다.

기술적으로 말하자면,이 기능은 기본적으로 IP 위에 구축 된 모든 네트워킹 (공개적으로 라우팅 가능한 IP 주소가 있어야 함)에 내장되어 있으며 클라이언트 측 라우팅 테이블을 변경하여 활성화됩니다. ISP의 자체 로컬 네트워크를위한 트래픽은 대부분 해당 인터페이스를 통해 계속 전송되지만 다른 모든 트래픽은 기본 게이트웨이를 통해 전송됩니다.

승인 및 기타 모든 작업을 수행하기 위해 일치해야하는 "소스"IP 주소는 데이터가 전송되는 소켓을 기반으로 선택되며 인터페이스 제한 소켓의 예외적 인 경우를 제외하고는 전혀 할 일이 없습니다. 데이터를 전달하는 데 사용되는 인터페이스 발신 네트워크 인터페이스는 소스 IP에 의해 선택된다는 의견과 달리 실제로 라우팅 테이블에만 영향을 미칩니다.

그러나 라우팅이 대상 주소에만 의존한다는 사실은 악의적 인 목적으로 사용되어 왔기 때문에 (패킷 스푸핑은 리플렉션 공격의 중요한 구성 요소입니다) 대부분의 캐리어는 역방향 경로 필터링 을 구현 하고 소스 IP가있는 패킷을 버릴 수 있도록 라우터를 구성했습니다. 주소가 스푸핑 된 것으로 간주되므로 경로와 일치하지 않습니다.

퍼블릭 IP 주소가없는 경우 역방향 경로 필터링 외에도 NAT / PAT 계층은이 기능이 작동하지 못하게합니다 (컴퓨터에서 사용하는 소스 IP 주소는 다른 네트워크에서 무의미하며 패킷이 NAT / PAT 라우터를 통해 나가지 않으면 올바르게 다시 작성하십시오).

실제로 대규모 멀티 홈 네트워크의 경우 비대칭 라우팅이 발생합니다. 중요하게도, 역방향 경로 필터링의 대부분의 구현 에서는 패킷이 도착한 인터페이스와 일치 하는 경로 가 존재 해야 합니다 . 선호 경로 (가장 비용이 낮은 경로) 일 필요는 없습니다.

따라서 "할 일"은 인터넷 제공 업체 (제공 업체 업스트림 포함)에게 (a) 역방향 경로 필터링을 비활성화하거나 (b) 선호하지 않는 경로를 설정하도록 설득하는 것입니다. 핵심 라우터는 모든 고유 한 IP 주소마다 하나씩을 얻기 위해 30 억 개의 경로를 처리 할 수 ​​없습니다. 따라서 모든 로컬 서브넷에 대한 경로가있는 ISP 내부를 제외하고는 / 20보다 작은 블록에 대한 경로를 갖는 것은 매우 드 rare니다.

짧은 대답은 다음과 같습니다. 사례의 95 %에서 수행 할 수 없으며 귀하의 95 %에 해당합니다.

첫째, 강렬한 다운로드 작업조차도 일부 패킷이 소스로 다시 흐를 필요가 있기 때문에 ( 즉 , 다운로드에 약간의 업로드 흐름이 필요하기 때문에, 라우팅과 별도로 업로드 및 다운로드에 대해 언급하는 것이 의미가 없다고 가정하겠습니다. TCP,하지만 신경 쓰지 마십시오).

다운로드 부분에 사용 된 것과 다른 NIC를 통해 대부분 다운로드 연결의 업로드를 채널로 전송하는 경우, 다운로드의 소스는 해당 패킷에 대한 응답이 원래 IP 주소와 다른 IP 주소에서 생성 된 것을 볼 수 있습니다 패킷 전송; 지정된 연결과 관련이 있지만 타사 주소에서 시작된 패킷을 무시하는 기본 보안 기능입니다. 따라서 대화의 업로드 부분이 삭제되고 연결이 중단됩니다. 이는 ISP 및 해당 서비스와 거의 관련이 없습니다. 동일한 LAN에있는 두 PC 간에도 동일한 연결에서 두 개의 다른 NIC (두 개의 다른 IP)를 사용하여 IP 주소에 연결하려고하는 경우에도 발생합니다. .

이것이 우리가 업로드 / 다운로드가 아닌 연결에 대해 이야기하는 이유입니다. 그러나 다음과 같이 질문을 재구성 할 수 있습니다 : 두 개의 NIC가 네트워크에 연결된 PC를 가질 수 있습니까? 전자 메일과 같이 느리고 지루한 작업의 느린 연결과 웹 페이지 다운로드와 같은 빠른 프로세스의 빠른 연결을 말합니다.

이 잘 제기 된 질문에 대한 짧은 대답은 Windows, * Nix (MacOS 포함) 및 Android 번호입니다. Linux에서는 가능합니다.

Windows (모든 버전), * Nix 및 Android에서이 작업을 수행 할 수없는 이유는 라우팅 테이블에 하나의 기본 게이트웨이 (* 즉, LAN으로 보내지 않은 모든 패킷을 보내는 주소) 만 가질 수 있기 때문입니다. OS는 하나의 라우팅 테이블, 즉 단일 게이트웨이 만 처리 할 수 ​​있습니다.

대신, 서로 다른 응용 프로그램을 서로 다른 인터페이스에 할당하려면 두 가지 기능이 필요합니다. 하나는 두 개의 라우팅 테이블을 동시에 실행할 수있는 능력이고, 다른 하나는 두 개의 라우팅 테이블에 응용 프로그램을 묶는 능력입니다. 이 글을 쓰는 시점에서 Linux 커널 (경쟁력보다 몇 년 앞선)만이 이러한 기능을 갖추고 있습니다. * Nix 커널은 방화벽 pfsense를 신중하게 사용하여 전체 결과를 얻지 않고 부분적으로 보상합니다.

두 개의 라우팅 테이블을 동시에 실행할 수있는 기능 ( 정책 라우팅 또는 소스 기반 라우팅이라고 함 )은 패킷이 IP 주소에 따라 다르게 라우팅됨을 의미합니다. 이것은 라우터를 구축 할 때 매우 유용한 기능입니다.

그러나 응용 프로그램에 따라 다른 NIC (및 IPS) 를 사용하려면 자체 네트워크 스택으로 별도의 셸을 구축 할 수있는 Linux 커널 기능인 network namespaces 가 필요 합니다 . 이제이 별도의 셸 내에서 실행되는 프로세스는 모두 주 네임 스페이스가 아닌 네트워크 네임 스페이스의 라우팅 테이블에 따라 라우팅됩니다.

물론 이것은 가상 머신은 말할 것도없이 리눅스 컨테이너보다 약한 형태이지만 가상화의 한 형태입니다. 그러나 단일 PC에서는 다른 인터페이스를 통해 다른 프로세스를 라우팅하는 실제 방법입니다.

요약하자면 Linux에서 (Linux에서만) 별도의 네트워크 네임 스페이스를 실행할 수 있습니다. 예를 들어 VPN을 통해 직장에 연결되어 있으므로 작업 리소스에 액세스하고 Firefox를 실행하는 경우, 네트워크 네임 스페이스 외부에서 Chrome을 실행하는 동시에 작업 공간을 기반으로하는 것처럼 보이므로 (Chrome에서는) 집을 기반으로하는 것처럼 보입니다.

서로 다른 공급자간에 관련 연결을 분할하는 것은 두 공급자 모두에서 단일 IP 주소에 도달하거나 라우팅 할 수있는 경우에만 가능합니다. 해당 IP는 일반적으로 BGP를 통해 더 큰 주소 블록의 일부로 제공됩니다. 그리고 만약 당신이 그것을 가지고 있다면, 당신은 BGP에서 path pre-pending과 local preference 규칙이라는 기능을 사용하여 BGP로 이것을 할 수있을 것입니다.

두 네트워크를 통해 IP에 도달 할 수 있도록 ISP와 휴대 전화 제공 업체간에 이러한 계약을 체결 할 수 있더라도 두 연결 모두에 대해 지금 지불하는 것보다 비용이 많이들 것입니다.

반면에 실제로 묻는 것은 ftp / sftp 또는 http로 파일을 업로드 할 때와 같이 주로 업로드 세션에 대해 4G 연결을 선호 할 수 있는지 여부입니다. 그리고 일반적인 웹 브라우징을 통해 해당 트래픽이 ISP를 사용하게하려면 답이 맞는 것 같습니다. 그러나 아마도 작동하려면 세션을 주로 업로드 또는 다운로드로 분류해야 할 수 있습니다. ftp 및 http 및 기타 프로토콜을 업로드 또는 다운로드에 동일하게 사용할 수 있으므로 포트 번호로이를 확인할 수 없습니다. 따라서 유일한 대안은 중간 스트림에서 데이터를 보는 것입니다. 이 단계에서 데이터가 이미 흐르면서 결정이 내려 졌을 것입니다. 따라서 자동화 할 수 없습니다.

따라서 귀하의 경우. 아니. (적어도 신발 끈에있을 때).

두 연결에서 모두 연결할 수있는 호스트가 필요합니다.

해당 호스트에 두 개의 VPN 터널을 설정하십시오. 각 VPN 터널은 다른 인터페이스에서 나옵니다. 일단 두 개의 이더넷 케이블을 갖는 것과 같습니다. 본딩을 사용하여 더 큰 케이블로 함께 사용하고 트래픽을 통과시킬 수 있습니다.

이제 실제로 성능을 크게 향상 시킬지 여부는 알 수 없지만 (모바일 네트워크의 대기 시간이 광대역보다 대기 시간이 훨씬 길어 문제가 발생할 수 있습니다) 시도해보십시오.