반응형

 

작성일: 2024년 2월 21일

 

PPTP, L2TP 같은 터널링을 사용할 수 없는 상황에서

방화벽 건너편의 네트워크에 접속할 일이 발생하면, SSH Port Forwarding을 임시방편으로 사용하는 것도 좋다.

물론 전제 조건이 있다.

  - SSH 접속할 수 있도록 방화벽 허용 규칙
     또는
  - DNAT Rule
     또는
  - 공유기의 Port Forward Rule이 미리 설정되어 있어야 한다.

 

즉, 원격 Network에 SSH 접속 만큼은 가능한 환경이라는 가정하에 아래 설명을 봐야 한다.

간단하게 한번 훑어보고 실습 환경으로 가보자.

 

SSH Tunneling에는 3가지가 있다.

  - Local Port Forwarding (Local Tunneling)

  - Remote Port Forwarding

  - Dynamic Port Forwarding

 

각 Tunneling 방식에 대해서는 아래 구체적으로 설명하기로 한다.

 

우선 접속할 대상 Network의 SSH 서버의 설정을 수정해야 한다.

SSH Server Config 설정

$ sudo -s

$ vim /etc/ssh/sshd_config

... 중간 생략 ...
AllowTcpForwarding yes     # <-- yes로 변경
GatewayPorts yes           # <-- yes로 변경
... 중간 생략 ...

$ systemctl restart sshd

 

 

준비 작업 끝 !

예시를 들어서, Local Tunneling에 관해서 설명해보면 이렇다.

 

SSH Local Port Forwarding (Local Tunneling)

아래 그림과 같이 집에 있는 내 맥북 PC에서 회사에 있는 VNC 서버에 접근해보겠다.

 

SSH 터널링 (Local Port Forwarding 방식)

 

위 네트워크 구성도를 참고하여 내 PC(맥북)에서 아래의 명령을 수행한다.

(위 구성도와 아래 명령에 있는 IP Address 값을 매핑해서 보면, 아래 명령의 의미를 이해할 수 있다)

$  ssh  -L 5900:10.1.1.3:5900  root@10.1.1.2

 

그리고 내 PC(맥북)에서 RealVNC Viewer 또는 TigerVNC Viewer에 새 연결 정보를 설정해야 하는데,

주소를 localhost (또는 127.0.0.1)으로 입력해야 한다. (아래 화면을 참고)

 

 

위와 같이 VNC Server의 주소를 설정하고, 접속 버튼을 누르면 

VNC 접속 요청 트래픽은 아래 순서로 흘러간다.

 

  1)  내 맥북 PC VNC Client

  2)  localhost의 ssh client (192.168.1.5:5900)

  3)  사무실의 ssh server (10.1.1.2)

  4)  VNC Server (10.1.1.3:5900)

 

원하는 VNC 접속 성공 !!

 

 


 

 

SSH Remote Port Forwarding

이번에는 완전 반대의 경우를 생각해보자.

사무실 쪽에서 SSH 서버 접속을 허용하지 않아서 Local Tunneling이 안 되는 경우라면, 

사무실에 있는 누군가(나의 친한 동료)가 내 집에 있는 내 맥북에 SSH Tunneling을 요청해주어야 한다.

물론 내 맥북이 Public network에 노출되어야 한다.

이런 방식을 Remote Tunneling이라고 한다. 

 

SSH 터널링 (Remote Port Forwarding 방식)

 

사무실에서 나의 동료가 회사 Linux 서버에서 아래와 명령을 실행해준다.

$  ssh  -R  34343:10.1.1.2:5900  sejong@192.168.1.5 -p 20022

 

그러면 위 명령 때문에 내 맥북 PC에는 TCP Listening port 34343가 생성된다.

## 집에 있는 내 맥북 PC에서 명령을 실행한 결과

$  netstat -anp | grep LISTEN
... 중간 생략 ...
tcp    0    0 0.0.0.0:34343       0.0.0.0:*         LISTEN      -
... 중간 생략 ...

 

이제 내 맥북에서 VNC Viewer를 이용해서 아래 화면과 같이 설정하고 회사 Network로 접속해보자.

VNC Server 주소는 localhost 또는 127.0.0.1 으로 설정하면 된다.

 

위와 같이 VNC Server의 주소를 설정하고, 접속 버튼을 누르면

VNC 접속 요청 트래픽은 아래 순서로 흘러간다.

 

  1)  내 맥북 PC VNC Client

  2)  localhost의 ssh client (192.168.1.5:5900)

  3)  사무실의 ssh server (10.1.1.2)

  4)  VNC Server (10.1.1.3:5900)

 

원하는 VNC 접속 성공 !!

 

 


 

반응형

 

HP DL-380, DL-580 또는 Dell PowerEdge 장비처럼 network port가 4~10개가 넘는 경우

Network 물리 포트와 OS에 할당된 Network port 이름간 관계를 찾기가 어렵다.

 

이럴 때, ethtool 명령으로 특정 포트 이름의 물리 포트가 어떤 것인지 찾을 수 있다.

예를 들어, 아래처럼 명령을 수행하면 eth0 포트에 해당하는 물리 포트의 램프가 아주 빠르게 깜빡깜빡거린다.

 

 

##
## eth0 포트의 램프를 깜빡거리게 한다.
##

$  ethtool -p eth0
^C


##
## eno2 포트의 램프를 깜빡거리게 한다.
##

$  ethtool -p eno2
^C

 

반응형

Kubernetes Cluster에서 MetalLB를 사용하다 보면, IP 트래픽을 처리하는 방식이 궁금할 때가 많다.

특히 Baremetal 환경에서 서비스를 운영한 개발자, 운영자라면 특히나 MetalLB의 동작 방식이나 원리가 이해가 안 되고, 감(느낌)도 안 잡힌다.

어디에 MetalLB 설계서 같은 문서가 있으면 좋겠지만, 그런게 없으니까 일단 궁금한 점이 떠오를 때마다 테스트하고 기록하는 수 밖에 ~~~

 

 

Q)  Kubernetes Service 리소스의 External IP 항목에 보여지는 IP Address는 실제로 어디에 있는가?

실제로 LoadBalancer Type으로 서비스 리소스를 설정하고, External IP Address를 할당받아서 테스트를 해보니까, 

External IP Address는 Master Node 또는 Worker Node에 있는 특정한 Network Port(예:  eth2)의 Mac Address를 공유해서 쓰고 있었다.

물론 Network Port(예: eth2)는 External IP Address와 같은 Network 대역이라서 라우팅이 가능한 Port가 된다.

(아마 MetalLB Operator가 동일한 Network 대역을 찾아서 할당해주는 것 같다)

참고: Layer 2 Mode로 MetalLB를 구성하고 테스트한 결과임
그렇다면, Master Node와 Worker Node가 10개가 있을 때, 어떤 Master Node와 Worker Node에 External IP Address가 있게 되는걸까?

 

이 External IP Address와 관련있는 Pod의 위치(Pod가 구동된 Master Node 또는 Worker Node)와는 전혀 관련이 없다.

MetalLB는 External IP Address를 Worker Node의 특정 Ethernet Port에 할당할 때, 최대한 분산되도록 스케쥴링한다.

만약 MetalLB가 External IP를 worker-a에 이미 할당할 것이 있다면, 그 다음 External IP를 worker-a가 아닌 다른 Node에 위치하도록 구성한다. 즉, 이 External IP가 한쪽 Kubernetes Node에 몰려서 외부 트래픽이 한개의 Node에 집중되는 것을 막으려는 노력을 하는 것이다.

 

반응형

 

Netcat(nc) TCP, UDP를 통해 Peer(Client/Server) 연결하고, 데이터를 읽고 쓰는 유틸리티 프로그램이다.

 

대부분 개발자, 운영자가 아래와 같은 목적으로 NC 명령을 사용할 것이다.

 

1)  두 장비(Network Node) 간에 IP Network이 정상인지 확인하거나

2)  중간에 방화벽이 있다면, 방화벽 정책이 적용되었는지 직접 TCP, UDP 트래픽을 테스트하기 위해서 NC를 사용한다.

3)  서버 또는 클라이언트 한쪽만 개발(구현)한 뒤에 Peer를 시뮬레이션하기 위해서...  (즉, 시뮬레이터 만들기 귀찮아서 ㅋㅋ) 

 

 

 

설치

 

##
## Mac OS 에 설치하는 경우
##

$  brew install netcat


##
## Ubuntu 에 설치하는 경우
##

$  apt install -y netcat


##
## CentOS, Redhat 에 설치하는 경우
##

$  yum install -y nc

 

 

 

사용 방법 / 예제

 

장황하게 설명하는 것보다는 아래 화면 캡처 하나가 훨씬 이해하기 좋을 듯~~~

그냥 아래 화면처럼 따라하면 테스트가 잘 된다.

 

##
## Netcat Server
##

$  nc  -l  -p 9090


##
## Netcat Client
##

$  nc  10.10.5.3  9090

이것은 테스트 메시지이다. (enter key)
...
...
... 이런 식으로 메시지를 타이핑하면서 테스트한다 ...
...
...

^C

$

 

 

게시물 작성자: sejong.jeonjo@gmail.com

 

반응형

 

Istio를 사용해서 Pod간 Traffic을 제어하다보면, 특정 Pod의 특정 TCP Port는 Proxy 처리에서 제외(Exclude)시키고 싶을 때가 있다.

(즉, Istio Enovy Proxy Container를 경유하지 않고, 바로 다른 연동할 Pod로 TCP Traffic을 보낸다는 뜻)

 

아마, 대부분 HTTP가 아닌 회사 내부에서 자체적으로 Protocol을 정해놓고 연동하는 Traffic 들이 대부분일 듯.

또는 NATS, Kafka 같은 Message Broker와 연동하는 경우에도 굳이 Service Mesh를 사용할 일이 없다.

왜냐하면 NATS, Kafka는 원래 메시지 분산 처리를 할 수 있도록 설계되어 있으니까 굳이 Istio의 제어를 받지 않아도 된다.

 

만약, TCP Port 50001를 사용하는 TCP Traffic을 Istio Envoy Proxy를 경유하지 않고, Main App Container (A)에서 바로 다른  Main App Container(B)에게 보내려면 아래와 같이 Pod에 Exclude Annotation을 설정한다.

 

apiVersion: apps/v1
kind: StatefulSet   ## or Deployment
metadata:
  name: myapp

... 중간 생략 ...

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
        traffic.sidecar.istio.io/excludeInboundPorts: "34432,50001,50002,50003,50100,50102,50103,50200,50201,50203,50300,50301,50302"
        traffic.sidecar.istio.io/excludeOutboundPorts: "34432,50001,50002,50003,50100,50102,50103,50200,50201,50203,50300,50301,50302"
반응형

Kubernetes service의 manifest를 작성하다보면, port와 targetport가 헷갈린다.

각 term이 의미하는 것을 지금 이해해도, 몇 개월 뒤에 다시 service resource에 대한 manifest를 작성하려고 보면 또 헷갈려서 다시 문서를 뒤적거리게 된다.

 

  • Port
    • Service Object 자체의 Port.  즉, 여러 Pod를 묶어서 이 Port 값으로 노출시킨다.
    • 한 kubernetes cluster 내에서 다른 pod가 내 pod에게 Layer 4 메시지를 전송할 때 바라보는 port number.
    • 만약 MetalLB, NGINX 같은 Ingress Gateway를 사용하는 경우라면, 이 'port' 값이 Cluster 외부에서 LB(즉, Ingress Gateway)를 통해 들어오는 Port number가 된다.
      예를 들어,   http://{EXTERNAL-IP}:{SERVICE-PORT}
      이런 형태가 된다.
  • TargetPort
    • 내 pod 안에 있는 container가 listening하고 있는 port number.
    • container(즉, app)이 어떤 port를 listening하고 있는지 정확한 값을 알고 설정해야 한다. (HTTPD 설정시 기본 값을 이용했다면, 대부분 80이지 않을까?)
  • NodePort
    • kubernetes 밖으로 노출시킬 port number.
    • Ingress Gateway 또는 Istio를 사용하는 경우에는 딱히 설정할 필요없는 설정 항목.

 

 

Example

만약 2개의 TCP Port를 Service로 오픈하고 싶다면, 아래와 같이 Service Resource와 Pod Resource를 설정한다.

 

##
## Service Manifest Example
##
kind: Service
metadata:
... 중간 생략 ...
spec:
  ports:
  - name: metrics
    port: 24231
    protocol: TCP
    targetPort: metrics
  - name: logfile-metrics
    port: 2112
    protocol: TCP
    targetPort: logfile-metrics
... 중간 생략 ...   
    


##
## Pod Manifest Example
##
kind: Pod
metadata:
... 중간 생략 ...
spec:
  containers:
    name: my-container  
    ports:
    - containerPort: 24231
      name: metrics
      protocol: TCP
    - containerPort: 2112
      name: logfile-metrics
      protocol: TCP
... 중간 생략 ...

'kubernetes' 카테고리의 다른 글

MetalLB BGP 모드를 이용한 Loadbalaning  (0) 2021.08.30
Istio Circuit Break  (0) 2021.08.07
Dockerfile Example  (0) 2021.07.19
Istio Web Docs - 읽기 좋은 순서대리 정리  (0) 2021.07.19
nsenter  (0) 2021.07.13
반응형

 


 

만약, Kubernetes cluster network 외부에서 kubernetes service에 access한다고 가정하면

아래와 같이 kubectl port-forward 명령으로 외부 IP traffic을 허용할 수 있다.

 

 

Example: Jenkins Web Dashboard 접속한다고 가정하고 테스트해보기

  • 구성 예시:
    • kubernetes service의 port는 8080
    • Web browser로 접속할 port는 8180

 

 

 

 

즉, 외부에서 8180으로 접속시도하면, 8080으로 port forward하도록 하려면, 아래와 같이 명령을 수행하면 된다.

 

##
## --addresss=0.0.0.0은 모든 IP Address를 수용하겠다는 뜻이다.
##
## 8180:8080은 Kubernetes Cluster 외부의 Client가 8180 포트로 접속 요청하면
## Kubernetes Cluster 내부의 8080 서비스 포트로 Forward해주겠다는 뜻이다.
##

$ kubectl  port-forward  --address=0.0.0.0 \
     $(kubectl get pod -l app.kubernetes.io/name=jenkins -o jsonpath='{.items[0].metadata.name}') \
     8180:8080

 

위와 같이 설정하고 Web browser에서 bastion node로 접속 시도한다.  (아래 예제 명령처럼 접속한다.)

 

$  curl  http://bastion.my-kube.node:8180/

 

 

위 예시는 Pod Name을 이용한 것이고, Service 이름을 이용해서도 port-forward 설정할 수 있다. (아래 명령을 참고)

##
## Cluster 밖의 Client가 9999 port 번호로 요청하면,
## 80 port 번호로 바꾸어서 almighty 네임스페이스의 almighty 서비스로 forwarding한다.
##

$ kubectl port-forward --address=0.0.0.0 -n almighty service/almighty 9999:80
Forwarding from 0.0.0.0:9999 -> 8080
Handling connection for 9999
...

 

 

 


참고:
kubectl port-forward 명령을 수행한 node가 bastion이라면, web browser가 접속할 Server(Target) 주소도 bastion의 IP address이어야 한다.

 

 

게시물 작성자: sejong.jeonjo@gmail.com

 

 

+ Recent posts