원격 접속과 사이트 간 VPN, 어느 쪽이 맞을까
원격 접속 터널은 장치를 네트워크에 연결하고, 사이트 간 터널은 게이트웨이를 연결합니다. 토폴로지로 설계를 고르고 장애를 좁히십시오.
출장 중인 직원과 지사에는 서로 다른 터널이 필요하며, 잘못 고르면 실험실에서는 동작하지만 첫 월요일에 실패하는 설계가 나옵니다. 원격 접속은 장치를 게이트웨이에 연결합니다. 사이트 간은 네트워크를 대표하는 두 게이트웨이를 연결합니다. 아래 체크리스트가 요구 사항이 실제로 어느 쪽을 말하는지 판정합니다.
누가 접속하고, 접속하는 쪽 뒤에 무엇이 있는가
원격 접속에서는 노트북이나 휴대폰의 소프트웨어가 터널을 세우고, 게이트웨이는 주소와 경로를 할당하기 전에 사용자, 장치 또는 둘 다를 인증합니다. 사이트 간에서는 라우터, 방화벽 또는 클라우드 게이트웨이가 연결을 세우고, 그 뒤의 장치는 클라이언트를 실행하는 대신 일반 라우팅을 사용합니다. 이 차이가 터널의 가동 책임(앞의 경우 직원의 장치, 뒤의 경우 관리되는 장치)을 누가 지는지 결정합니다. 인증이 사람을 설명하는지 네트워크를 설명하는지도 이 차이가 결정합니다.
한 사무실의 모든 기기가 장치별 설정 없이 다른 사무실에 도달해야 한다는 요구라면 여기서 멈추십시오. 그것은 사이트 간이며, 원격 접속 로그인을 잔뜩 쌓는 것은 형편없는 대체물입니다.
주소 지정과 돌아오는 경로
로컬과 원격 대역을 따로 계획하십시오. 두 사이트가 같은 사설 서브넷을 쓸 수 있으며, 그러면 라우팅이 모호하지 않게 되기 전에 설계에 변환 또는 재번호 부여가 필요합니다. 본사와 같은 대역을 쓰는 가정용 라우터는 원격 근무자 한 명에게 같은 문제를 만듭니다. 중복은 충분히 흔하므로 그 확인은 첫 대화에 들어가야 합니다.
돌아오는 경로는 나가는 경로만큼 중요합니다. 서버는 요청을 받고도 클라이언트 네트워크로 돌아갈 경로가 없을 수 있습니다.
어떤 라우터가 원격 접두사를 아는지, 특히 클라우드 네트워크와 여러 게이트웨이에서 문서화하십시오. 초록 터널 아이콘은 목적지에 동작하는 돌아오는 경로가 있는지 답할 수 없고, 한 방향 핑도 마찬가지입니다. 원격 접속에서는 보통 게이트웨이가 풀 경로를 가지며, 사이트 간에서는 접두사를 나르는 모든 중간 라우터가 동의해야 합니다. 변환은 주소를 내장한 응용 프로그램이 깨질 때까지 빠진 경로를 숨길 수 있습니다.
인터넷 출구는 별개의 결정입니다
사설 도달성은 터널이 일반 브라우징을 실어 나를 것을 요구하지 않습니다. 일반 웹 트래픽이 게이트웨이를 통해 나가는지는 두 번째 결정이며, 설계마다 정하고 클라이언트 프로필이나 사이트 구성에 기록합니다.
전체 터널과 분할 터널은 그 질문에 대한 답이며, 원격 접속 대 사이트 간 질문에 대한 답이 아닙니다. 내부 이름은 두 설계 모두에서 적절한 DNS가 필요한데, 공용 리졸버는 사설 사무실 호스트 이름에 대한 답을 갖지 않기 때문입니다. 리졸버를 밀어 넣는 것과 기본 경로를 밀어 넣는 것은 관련된 설정이며, 하나를 다른 것 없이 바꾸면 DNS 문제처럼 보이는 장애가 생깁니다.
토폴로지로 장애를 좁히십시오
이동하는 노트북 하나는 클라이언트, 자기 계정 또는 로컬 네트워크에서 접속을 잃습니다. 지사 전체는 공유 경로와 게이트웨이에서 접속을 잃습니다.
먼저 터널 수립, 다음으로 경로, 다음으로 허용된 트래픽, 다음으로 이름 확인, 다음으로 응용 프로그램 로그인을 확인하고, 실패하는 첫 단계에서 멈추십시오.ip route get 10.60.8.15 응용 프로그램 로그를 한 줄도 읽기 전에 라우팅 질문에 답합니다. 암호화 설정은 파일 공유 권한 오류를 고치지 못하며, 동작하는 핑은 응용 프로그램이 승인되었음을 증명하지 않습니다. 순서를 고정하면 장애 하나를 셋으로 만드는 무작위 구성 변경을 막을 수 있습니다.
마지막으로, 공급업체 자료를 읽을 때 정의를 똑바로 유지하되, 상용 인터넷 출구 서버는 기업의 사설 게이트웨이와 다른 서비스이며 그 기업의 네트워크에 어떤 접속도 제공하지 않는다는 점을 기억하십시오.