MISTERY

Network Diagram Software

With extensive network objects library


Quickly draw network topology diagrams, CISCO diagrams, data center diagrams and many other network diagrams with easy to use drag and drop interface.

  • 100's of templates to get started quickly
  • Export network diagrams as images or pdfs
  • Share and collaborate in real-time with others


이런게 있는지도 모르고 PPT로 수없이 그렸다.

네트워크 만지는 사람들은 한번씩 이용해 보는 것도 좋을듯 하다.










Ref. http://creately.com/Online-Network-Diagram-Software 




신고

Comment +0

저장된 패킷파일을 재 전송하기 위한 방법으로 tcpreplay 를 소개한다. 이미 익히 알고
있는 분들도 많이 계시겠지만, 패킷을 재 전송할때 유용하게 사용될 수 있다. 왜?
패킷을 재전송하냐고 반문할 수도 있겠지만, 나름 사용할 때가 꽤 많다. 도입된 장비에
대해서 다양한 테스트를 수행할 수도 있고, IDS 패턴 시그너처를 작성하고 정상적으로
차단하는지의 유무를 테스트할 때도 쓰일 수 있다.

일단 다운로드를 다음의 주소에서 한다.

기본적인 사용법은 다음과 같다. -i 옵션을 통해 트래픽이 나갈 인터페이스를 지정하고
전송에 사용될 패킷 파일을 지정하면 된다.

# tcpreplay -i eth0 packet.pcap

패킷을 전송할때 속도도 정의할 수 있는 이때 사용되는 옵션은

--pps
--mbps
--topspeed
--multiplier

와 같다. 대충 옵션 이름만 봐도 추정은 될 것이다. PPS 로 지정하여 초당 몇개의
패킷을 전달 할 것인지, mpbs 로 메가 단위로 전송속도를 조절할지, 최대 가능한
속도인 --topspeed 로 할 지를 정할 수 있다.

- 최대 가능한 전송 속도로 전송하기
# tcpreplay --topspeed --intf1=eth0 sample.pcap
# tcpreplay -i eth0 --topspeed test.pcap
sending out eth0
processing file: test.pcap
Actual: 72 packets (21961 bytes) sent in 0.46 seconds
Rated: 4724827.9 bps, 36.05 Mbps/sec, 15490.53 pps

Statistics for network device: eth0
        Attempted packets:         72
        Successful packets:        72
        Failed packets:            0
        Retried packets (ENOBUFS): 0
        Retried packets (EAGAIN):  0

- 10Mbps 비율로 전송하기
# tcpreplay --mbps=10 --intf1=eth0 sample.pcap

- 원래 속도의 반 정도로 조절하여 보내기
# tcpreplay --multiplier=0.5 --intf1=eth0 sample.pcap

참고로, 가끔 속도 지정없이 패킷을 전송하는 경우 패킷파일이 작은데도 불구하고
꽤 오래 걸리는 경우가 있다. 이럴 경우에 --mbps=10000 과 같이 크게 지정하여
전송하면 바로 전송되는 경험도 있었다. 또는 --topspeed 를 이용해 보자.

또 다른 옵션으로 -l(--loop) 옵션이 있다. 캡쳐파일을 주어진 수 만큼 반복하는 것이다
아래 예는 sample.pcap 을 20번 반복해서 eth0 로 전송하게 되는 것이고, 만약
0 를 지정하면 무한루프를 돌게된다. 즉, Ctrl+C 로 중지하기 전 까지는 계속 동작한다.

# tcpreplay --loop=20 -i eth0 sample.pcap

속도가 얼마나 나오는지 테스트를 위하여 xxxx.pcap 을 10번 전송해 보았다.

# tcpreplay -i eth4 --topspeed --loop=10 xxxx.pcap
sending out eth4
processing file: xxxx.pcap
processing file: xxxx.pcap
processing file: xxxx.pcap
processing file: xxxx.pcap
processing file: xxxx.pcap
processing file: xxxx.pcap
processing file: xxxx.pcap
processing file: xxxx.pcap
processing file: xxxx.pcap
processing file: xxxx.pcap
Actual: 1352310 packets (238093580 bytes) sent in 4.90 seconds
Rated: 48583705.8 bps, 370.66 Mbps/sec, 275942.89 pps

Statistics for network device: eth4
        Attempted packets:         1352310
        Successful packets:        1352310
        Failed packets:            0
        Retried packets (ENOBUFS): 0
        Retried packets (EAGAIN):  0

와, 나쁘지 않은 속도를 보여주고 있다. 초당 370Mbps 수준이다.
참고로 tcpreplay 홈페이지에서 리눅스 환경에서 속도를 높이기 위하여 다음과 같은
설정을 제시했다. 물론 사용하는 OS 마다 다 다르겠지만,

echo 524287 >/proc/sys/net/core/wmem_default
echo 524287 >/proc/sys/net/core/wmem_max
echo 524287 >/proc/sys/net/core/rmem_max
echo 524287 >/proc/sys/net/core/rmem_default

거의 10 배가까이 속도가 좋아졌다고 한다. 내 환경을 살펴보니 아래와 같았는데도,
초당 370 메가까지 나왔으니 참고하길 바란다. 사용커널은 2.6.26-2 이다.

# cat /proc/sys/net/core/wmem*
110592
131071
# cat /proc/sys/net/core/rmem*
110592
131071




















출처 : http://www.packetinside.com/2010/04/tcpreplay-%EB%A5%BC-%ED%86%B5%ED%95%B4-%ED%8C%A8%ED%82%B7%EC%9D%84-%EC%9E%AC-%EC%A0%84%EC%86%A1%ED%95%98%EA%B8%B0.html




















신고

Comment +0

tcpdump -i eth1 -w 0906.pcap -C 16 -s 1500 -n -Z root 

 

eth1 인터페이스에서 capture 하며 0906.pcap 파일로 저장하고 16M 로 분할하여 생성

패킷바이트 1500byte size 이하만 캡쳐하고 계정은 root














신고

Comment +0

Collapse image요약

GRE(Generic Route Encapsulation) 프로토콜은 클라이언트 간 또는 클라이언트와 서버 간에 VPN(가상 개인 네트워크)을 만들기 위해 PPTP(지점 간 터널링 프로토콜)과 함께 사용됩니다.

Collapse image추가 정보

일반적인 한 가지 구현은 아래와 같이 LAN 사이의 라우팅을 위해 구성된 두 개의 라우팅 및 RRAS(원격 액세스 서비스) 서버 간에 Microsoft의 VPN 기술을 사용하는 것입니다.
Lclient           L-RRAS ===== VPN ===== R-RRAS           Rclient
    |      IP      |  |      인터넷       |  |      IP      |
     --------------    -----------------    --------------
				
VPN을 만들고 사용할 때 GRE가 어떻게 사용되는지 잘 이해하고 있으면 패킷 구조를 이해하는 데 도움이 됩니다. PPTP 제어 세션을 설정한 후에 GRE를 사용하여 안전한 방법으로 데이터나 페이로드를 캡슐화합니다. PPTP에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
241252 VPN 터널 - PPTP 프로토콜 패킷 설명 및 사용
Microsoft에서 데이터를 캡슐화하는 데 사용하는 GRE 패킷의 일반적인 형식은 다음과 같습니다.
데이터 링크(D/L) 헤더
IP 헤더
GRE 헤더
PPP 헤더
암호화된 PPP 페이로드
데이터 링크 트레일러
터널을 통과할 데이터나 페이로드는 PPP(지점 간 프로토콜) 헤더가 지정되어 GRE 패킷 내에 저장됩니다. GRE 패킷은 두 터널의 종점 간에 데이터를 전송합니다. GRE 패킷은 최종 목적지(터널의 종점)에 도달한 후에 폐기되고 캡슐화된 패킷이 최종 목적지로 전송됩니다.

이 절의 처음에 있는 다이어그램을 사용하여 Lclient의 IP(인터넷 프로토콜) 패킷이 먼저 L-RRAS 서버로 전송됩니다. IP 패킷은 암호화되고 추가 PPP 헤더가 지정된 다음 GRE 패킷 내에 저장됩니다. 아래의 다이어그램에서는 PPP 헤더도 데이터와 함께 암호화되기 때문에 "PPP 헤더"가 아니라 "PPP 스텁"이라고 합니다. 보이지는 않지만 GRE 프로토콜은 PPP 헤더가 있다는 것을 인식하도록 구성됩니다. 캡슐화되고 암호화된 데이터가 있는 GRE 패킷은 인터넷을 통해 "R-RRAS 서버"의 최종 목적지로 전송됩니다. R-RRAS 서버는 GRE 헤더와 PPP 헤더를 제거한 다음 해독된 데이터(IP 패킷)를 Rclient로 전송합니다.
Lclient           L-RRAS ===== VPN ===== R-RRAS           Rclient
    |      IP      |  |      인터넷       |  |      IP      |
     --------------    -----------------    --------------
    D/L 헤더                  D/L 헤더              D/L 헤더
    IP 헤더                    IP 헤더               IP 헤더
    페이로드                   GRE 헤더              페이로드
                               PPP 스텁
                               페이로드(암호화됨)
				

프로토콜 헤더

GRE 프로토콜이 어떻게 암호화 프로토콜로 작동하는지 이해하려면 프로토콜의 헤더 형식을 검토해야 합니다. Microsoft는 GRE 패킷 헤더를 다음과 같은 형식으로 구현했습니다.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|R|K|S|s|Recur|A| Flags | Ver |        프로토콜 종류              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    키(HW) 페이로드 길이          |       키(LW) 호출 ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     시퀀스 번호(선택 사항)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    응답 번호(선택 사항)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
				
다음 표에서는 사용할 수 있는 함수와 매개 변수에 대한 세부적인 설명이 있는 각 필드를 보여 줍니다.
C(비트 0) 체크섬의 유무 표시. 영(0)으로 설정합니다.
R(비트 1) 라우팅의 유무 표시. 영(0)으로 설정합니다.
K(비트 2) 키의 유무 표시. 일(1)로 설정합니다.
S(비트 3) 시퀀스 번호의 유무 표시.
페이로드(데이터) 패킷이 있을 경우 일(1)로 설정합니다.
페이로드가 없을 경우 영(0)으로 설정합니다(GRE 패킷은 응답 전용).
s(비트 4) 엄격한 원본 경로의 유무 표시. 영(0)으로 설정합니다.
Recur(비트 5-7) 순환 제어입니다. 영(0)으로 설정합니다.
A(비트 8) 응답 시퀀스 번호의 유무 표시.
패킷에 이전에 전송된 데이터를 확인하는 데 사용하는
응답 번호가 포함된 경우 일(1)로 설정합니다.
Flags(비트 9-12) 영(0)으로 설정해야 합니다.
Ver(비트 13-15) 1(향상된 GRE)이 들어 있어야 합니다.
프로토콜 종류16진수 880B(PPP의 경우)로 설정합니다.
키(HW) 페이로드 길이(키의 상위 2옥텟) GRE 헤더를 제외한
페이로드의 크기입니다.
키(LW) 호출 ID(키의 하위 2옥텟) 이 패킷이 속하는
세션에 대한 피어의 호출 ID가 들어
있습니다.
시퀀스 번호페이로드의 시퀀스 번호가 들어 있습니다.
S 비트(비트 3)가 일(1)인 경우에 있습니다.
응답 번호이 사용자 세션에 대해 보내는 피어가
받은 가장 높은 번호의 GRE 패킷의 시퀀스 번호가
들어 있습니다. A 비트(비트 8)가 일(1)인
경우에 있습니다.

향상

GRE 프로토콜에는 RFC(Request for Comments) 2637에서 비롯된 눈에 띄는 몇 가지 향상된 점이 있습니다.
  • 응답 번호 필드 - 특정 GRE 패킷이나 패킷 집합이 터널의 원격 종점에 도달했는지 여부를 확인하는 데 사용됩니다. 이 응답 기능은 사용자 데이터 패킷의 재전송에는 함께 사용되지 않습니다. 그 대신 지정된 사용자 세션에서 사용자 데이터 패킷이 터널을 통해 전송되는 속도를 확인하는 데 사용됩니다.
  • 터널링 이식성 - 페이로드 섹션에는 미디어 관련 프레이밍 요소가 없는 PPP 데이터 패킷이 들어 있습니다.
  • 시퀀스 번호 추적 - 포함된 시퀀스 번호는 패킷 단위의 시퀀스 번호입니다. 각 사용자 세션의 시퀀스 번호는 세션이 시작할 때 0으로 설정됩니다. 페이로드를 포함한(S 비트 또는 비트 3이 1로 설정된) 지정된 사용자 세션에 보낸 각 패킷에는 해당 세션의 다음 연속 시퀀스 번호가 할당됩니다.
  • 추가 긍정 응답의 사용 - 이 프로토콜을 사용하면 데이터와 함께 응답이 전송되고 전체적인 프로토콜을 보다 효율적으로 사용할 수 있어 패킷 버퍼링 요구가 줄어듭니다.

네트워크 모니터 추적

네트워크 모니터 추적을 볼 때 여러 가지를 확인해야 합니다. 플래그 요약은 처음 16비트의 16진수 값으로 구성되어 있습니다. 아래의 예제 패킷에서 플래그 요약은 12,417 또는 0x3081h입니다. Microsoft 네트워크 모니터 파서에서는 플래그 요약 비트 필드의 버전 번호를 표시하지 않지만 해당 번호는 있습니다. 예를 들어, 다음과 같은 예제 패킷이 있다고 가정합니다.
GRE: 플래그 요약 = 12417 (0x3081)
         GRE: 0............... = 체크섬 없음
          GRE: .0.............. = 라우팅 없음
          GRE: ..1............. = 키 있음
          GRE: ...1............ = 시퀀스 번호 있음
          GRE: ....0........... = 엄격한 원본 경로 없음
          GRE: ........1....... = 응답 시퀀스 번호 있음
       GRE: 순환 제어 = 0 (0x0)
      GRE: Ver = 1 (0x1)
      GRE: 프로토콜 종류 = 0x880B
      GRE: 키 길이 = 90 (0x5A)
      GRE: 키 호출 ID = 32768 (0x8000)
      GRE: 시퀀스 번호 = 16 (0x10)
      GRE: 응답 번호 = 15 (0xF)
				

처음 8비트는 00110000이며 30의 16진수 값을 나타냅니다. 다음 8비트는 10000001이며 81의 16진수 값을 나타냅니다. 따라서 플래그 요약은 0x3081h(또는 10진수 12,417)입니다. 












출처 : http://support.microsoft.com/kb/241251/ko











신고

Comment +0

작업환경

  • CentOS

System 설정

아래의 명령을 실행하여 sysctl.conf 파일을 편집합니다.

1
vi /etc/sysctl.conf

아래와 같이 net.ipv4.ip_forward 값을 1 로 변경합니다. 재부팅시에 적용이 됩니다.

1
net.ipv4.ip_forward = 1

아래의 명령을 이용하여 직접 Kernel 변수를 수정할 수 있습니다.

1
echo 1 > /proc/sys/net/ipv4/ip_forward

iptables 설정

MASQUERADE 설정

1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Network Interface (eth0) 을 통한 Port Forwarding

1
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport ${port} -j DNAT --to ${IP:Port}

특정 IP 를 통한 Port Forwarding

1
iptables -t nat -A PREROUTING -p tcp -d ${IP} --dport ${Port} -j DNAT --to-destination ${IP:Port}

Local Port Forwarding

1
iptables -t nat -A PREROUTING -p tcp -d ${IP} --dport ${Port} -j REDIRECT --to-port ${Port}












출처 : http://blog.beany.co.kr/archives/2157


사실.. 위 설정에 대해서는 다 알고있다.

NAT 서버를 설정하면서 수없이 해보았던 건데.. 참 정리가 잘된거 같아서 옮겨왔다.


위에 내용중에 추가할 부분은 반드시 service iptables stop (iptables를 멈춘 후) 한 후 추가하고,

다 추가한 후 service iptables save 그리고 마지막으로 service iptables start 를 하는 것이다.


그리고 가끔. selinux 로 인해서 적용이 안될경우가 있으니 disable 하는 것도 알아두자. 













신고

Comment +0

티스토리 툴바