블로그 이미지
안녕하세요~ iolate(a.k.a. isho) 의 블로그 입니다~! iolate

카테고리

분류 전체보기 (181)N
끄적끄적 (6)
Server, Cloud (10)N
Linux, Ubuntu (29)
개발개발 (45)
Mac, iOS (41)
Embedded (20)
NAS (1)
Web (5)
Network (3)
Review (12)
기타 (9)
비공개글 (0)
Total681,543
Today111
Yesterday241

이건 정리용.


1. Root CA 생성

# CA private key 생성
openssl genrsa -out ca.key 2048

# CA request 생성
openssl req -new -key ca.key -out ca.csr -subj "/C=KR/O=TIM Lab/CN=My VPN CA"

# CA 인증서 생성
echo "basicConstraints = critical, CA:TRUE
subjectKeyIdentifier = hash
keyUsage = digitalSignature, keyCertSign, cRLSign" > ca.ext

openssl x509 -req -days 3650 -extfile ca.ext -set_serial 1 -signkey ca.key -in ca.csr -out ca.crt

# 필요없는 설정파일과 csr 제거
rm ca.ext ca.csr


2. ta.key, dh2048.pem 생성 

openssl dhparam -out dh2048.pem 2048
openvpn --genkey --secret ta.key


3. 서버용 인증서 생성

# private key 생성
openssl genrsa -out cert.key 2048

# csr 생성
openssl req -new -key cert.key -out cert.csr -subj "/C=KR/O=My Organization/CN=VPN Server"

# CA 인증서/키로 인증서 생성
echo "basicConstraints = critical, CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth" > cert.ext

openssl x509 -req -days 3650 -extfile cert.ext -CA ca.crt -CAcreateserial -CAkey  ca.key -in cert.csr -out cert.crt

# 필요없는 설정파일과 csr 제거
rm cert.ext cert.csr

# 서버 인증서, 키 등 이동 / 복사
cp ca.crt /etc/openvpn/ca.crt
cp cert.key /etc/openvpn/server.key
cp ta.key /etc/openvpn/ta.key
mv cert.crt /etc/openvpn/server.crt



4. 클라이언트용 인증서 생성

사실 서버 인증서 생성과 큰 차이 없다. X.509 의 설정파일 내용 정도?
# private key 생성
openssl genrsa -out cert.key 2048

CERT_NAME="Gildong Hong"

# csr 생성
openssl req -new -key cert.key -out cert.csr -subj "/C=KR/O=My Organization/CN=$CERT_NAME"

# CA 인증서/키로 인증서 생성
echo "basicConstraints = critical, CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = digitalSignature" > cert.ext

openssl x509 -req -days 3650 -extfile cert.ext -CA ca.crt -CAcreateserial -CAkey  ca.key -in cert.csr -out "clients/$CERT_NAME.crt"

# 필요없는 설정파일과 csr 제거
rm cert.ext cert.csr



5. ovpn 설정파일 만들기

exec 3> VPN.ovpn

echo "client
remote SERVER_HOST PORT

dev tun
proto udp
resolv-retry infinite
nobind
cipher AES-256-CBC
auth SHA256
key-direction 1
persist-key
persist-tun
remote-cert-tls server
verb 3

;redirect-gateway def1 bypass-dhcp
;auth-user-pass
" >&3

printf "\n\n<ca>\n" >&3
cat ca.crt >&3
printf "</ca>\n\n<tls-auth>\n" >&3
cat ta.key >&3
printf "</tls-auth>\n\n<cert>\n" >&3
cat "clients/$CERT_NAME.crt" >&3
printf "</cert>\n\n<key>\n" >&3
cat cert.key >&3
printf "</key>" >&3

exec 3>&-


Posted by iolate

OpenVPN 은 기본적으로 사용자별로 인증서를 생성해서 연결하도록 하고 있다.


그러다보니 설정파일에 ca, tls-auth, cert, key 4개의 파일이 추가로 따라다니게 되는데 관리하기 조금 번거로운 면이 있다.

물론 각각 ovpn 파일안에 임베딩해버릴 수 있지만...


아이디, 비밀번호로 로그인하는 방법이 있길래 진행해보았다.


먼저 OpenVPN 서버 설정에서 아래 두 문구를 추가한다.

client-cert-not-required
auth-user-pass-verify "/etc/openvpn/userauth/verify.sh" via-file

첫번째 줄은 클라이언트 인증서가 필요없게 하는거고, 두번째줄은 비밀번호를 체크할 스크립트를 지정한다.

저 파일은 내가 만들어줘야하며, 경로는 어디두던 크게 상관없음.


다만 user nobody / group nogroup 설정을 했을 경우 OpenVPN 데몬이 nobody / nogroup 권한으로 작동하기 때문에, 권한에 유의해주면 된다. 읽기 권한이나 실행 권한 등이 없으면 비밀번호 체크를 할 수 없다.

비밀번호 체크 과정에 root 권한이 필요하다면 권한을 낮추는 해당 설정을 제거해주자.


스크립트 경로 뒤의 via-file 은 OpenVPN 에서 사용자가 입력한 아이디와 비밀번호를 넘겨줄 방식을 정한다.

via-file 로 할 경우 임시 파일을 생성하면서

username
password

이렇게 두 줄로 된 파일을 생성한다.


(via-env 로 할 경우 환경변수에 넣어준다는데, 사용자명은 들어오는데 비밀번호는 어디있는지 모르겠더라...)



해당 스크립트에서 아이디와 비밀번호를 읽어서, 성공했다면 exit 0 을, 실패했다면 에러코드와 함께 프로그램이 종료되면 된다.



이제 비밀번호 체크를 위한 스크립트를 만들자.

방식은 다양하니 직접 만들면 되겠지만 내 스크립트를 참고 삼아 올려둠.


아래 URL 에 들어가보면 다른 스크립트들도 있다.


나는 user.pass 파일에

사용자명=SHA1비밀번호
사용자명=SHA1비밀번호

꼴로 저장을 해두고, 이를 검사하는 방식으로 작성하였다.


verify.sh 코드는 이렇게.

#!/bin/bash
passfile="/etc/openvpn/userauth/user.pass"
logfile="/var/log/openvpn/userauth.log"

username=`head -n 1 $1`
password=`head -n 2 $1 | tail -1`

hashed=`echo -n $password | sha1sum | awk '{print $1}'`
userpass=`cat $passfile | grep $username= | awk -F= '{print $2}'`

if [ "$userpass" = "$hashed" ]; then
        echo "`date +'%Y-%m-%d %H:%M:%S'` - auth success: $username" >> $logfile
#       echo "ok"
        exit 0
fi

echo "`date +'%Y-%m-%d %H:%M:%S'` - auth fail: $username" >> $logfile
#echo "not ok"
exit 1



그리고 client 설정 파일에는 cert 와 key 를 없애고, auth-user-pass 옵션을 추가해주면 된다.



----------

이 다음으로, Local 사용자 계정으로 로그인하는걸 시도해보았다.


보통 shadow 파일을 읽어서 비교를 많이 하던데, 나는 PAM Authentication 을 이용해보았다.

PAM 인증을 할때 root 이어야만 제대로 작동하는 것 같으니, 서버 설정에서 user nobody 옵션은 주석처리 해주자. (혹은 스티키 비트를 넣어주거나..)



PAM 인증을 하는 c 프로그램을 제작하였고, 로그를 남기기 위해 간단한 쉘 스크립트를 같이 이용하였음.

verify.sh

#!/bin/bash
pam_auth="/etc/openvpn/userauth/pam_auth"
logfile="/var/log/openvpn/userauth.log"

pam_result=`$pam_auth $1`
ret=$?

echo "`date +'%Y-%m-%d %H:%M:%S'` $pam_result" >> $logfile
exit $ret



pam_auth.c ( https://gist.github.com/iolate/a58b73a023b35d5f181814de2f4ffccd )

// gcc -o pam_auth pam_auth.c -lpam

#include <security/pam_appl.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int custom_converation(int num_msg, const struct pam_message** msg, struct pam_response** resp, void* appdata_ptr) {
	// Provide password for the PAM conversation response that was passed into appdata_ptr
	struct pam_response* reply = (struct pam_response* )malloc(sizeof(struct pam_response));
	reply[0].resp = (char*)appdata_ptr;
	reply[0].resp_retcode = 0;

	*resp = reply;
	return PAM_SUCCESS;
}

int main(int argc, char *argv[]) {
	if (argc != 2) {
		fprintf(stderr, "Usage: %s [filepath]\n", argv[0]);
		exit(1);
	}
	
	FILE* fp;
	char* username = NULL;
	char* password = NULL;
	size_t len = 0;
	ssize_t read;
	
	fp = fopen(argv[1], "r");
	if (fp == NULL) {
		fprintf(stderr, "%s: Cannot open '%s'\n", argv[0], argv[1]);
		return 1;
	}
	
	read = getline(&username, &len, fp);
	if (read == -1) {
		fclose(fp);
		return 1;
	}
	username[strlen(username)-1] = '\0'; // remove LF
	
	read = getline(&password, &len, fp);
	if (read == -1) {
		fclose(fp);
		return 1;
	}
	password[strlen(password)-1] = '\0'; // remove LF
	
	fclose(fp);
	
	// PAM Authentication
	struct pam_conv conv = {custom_converation, password};
	pam_handle_t* pamh = NULL;

	int retval = pam_start("whoami", username, &conv, &pamh);

	if (retval == PAM_SUCCESS)
		retval = pam_authenticate(pamh, 0); // is user really user?

	//if (retval == PAM_SUCCESS)
	//	retval = pam_acct_mgmt(pamh, 0); // permitted access?

	if (retval == PAM_SUCCESS) {
		fprintf(stdout, "Authenticated - %s\n", username);
	} else {
		fprintf(stdout, "Not Authenticated - %s\n", username);
	}

	pam_end(pamh, 0);
	return retval;
}


pam_auth 를 컴파일하기 위해선 pam development 패키지가 필요하니 설치하고 컴파일 해주자.

Ubuntu 기준 아래의 방법으로 진행하면 됨.

sudo apt install libpam0g-dev
gcc -o pam_auth pam_auth.c -lpam



verify.sh 를 간단히 수정하면, 두가지 방식을 동시에 사용하는 것도 가능하다.


참고

https://forums.openvpn.net/viewtopic.php?t=24907

https://medium.com/@nqbao/openvpn-auth-user-pass-verify-example-8d99023f08f7


https://unix.stackexchange.com/a/153323

http://www.linux-pam.org/Linux-PAM-html/adg-example.html

Posted by iolate

Ubuntu 18.04 에 NIS 를 구성하여 사용하고 있었음.


설치 및 설정은 아래 링크를 참고.


Ubuntu 18.04 : NIS Server

(01) Configure NIS Server

(02) Configure NIS Client

(03) Configure NIS Slave


나는 Slave 서버는 없고, MERGE_PASSWD 와 MERGE_GROUP 옵션은 뭔지 잘 모르겠어서 하라는대로 하지 않았음.


위 방법으로 1대의 Master 와 여러대의 Client 를 구성하였는데, Client에서 NIS 계정으로 로그인할 경우 SSH 연결을 위해서 20초 가량이 걸리면서 연결이 제대로 안되는 문제가 발생.


ssh -vvv 옵션을 주고 연결을 하면


(생략)

debug1: Entering interactive session.

debug1: pledge: network

(여기서 약 20초 딜레이)

debug3: receive packet: type 80

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0

(생략)


이렇게 진행이 된다.


/var/log/auth.log 를 보면

sshd[15635]: pam_systemd(sshd:session): Failed to create session: Connection timed out


이런 식의 오류메시지가 남겨져 있음.


찾아보니 systemd-logind 에 IP Sandbox 기능이 있는데 이와 관련한 문제이며 이 기능을 꺼줘야 한다고 한다.

보안상의 문제로 이걸 끄면 대체로 IP 필터를 걸어줘라~ 라는 식으로 적혀 있던데 이 기능 자체가 새로 생긴 것 같아 보이고 필요성을 모르겠어서 그냥 비활성화만 하고 치움.



sudo vi /lib/systemd/system/systemd-logind.service
SystemCallArchitectures=native
LockPersonality=yes
#IPAddressDeny=any
FileDescriptorStoreMax=512


sudo systemctl daemon-reload
sudo systemctl restart systemd-logind


참고

https://github.com/systemd/systemd/issues/9431

https://askubuntu.com/questions/1031022/using-nis-client-in-ubuntu-18-04-crashes-both-gnome-and-unity/1064617#1064617

Posted by iolate

개인적으로 nginx 자체는 매력적이라고 생각했지만, php-fpm 이라던가 uwsgi 같이 웹서버에서 직접 붙지 않고 socket 으로 연결되는 방식이 마음에 들지 않아 잘 사용하지 않았다. 

설정 및 관리가 좀 더 번거롭기도 했고..


이제는 마음에 안들었던 몇가지를 감수하고 장점을 취해보기 위해서 사용해보려고 하는데,  여전히 개떡같은 uWSGI 설정법을 정리해봄.


환경은 Ubuntu 18.04 + Nginx + uWSGI + Python3 + Flask.

이 방법의 최대 장점 중 하나가 프로젝트별로 python 버전에 구애받지 않고 venv 를 전혀 무리 없이 돌릴 수 있다.. 인 것 같은데 난 평소에 그렇게 안쓰고 있으니 일단 생략.


1. 패키지 설치

Ubuntu 18 에는 쓸만한 uwsgi 버전으로 기본 패키지 매니저에 있다. 플러그인까지 한번에 설치해주자.

apt install uwsgi uwsgi-plugin-python

* pip 을 이용해서 설치해도 된다. 어차피 systemd 데몬으로 만들거라... 이 편이 더 나은 것 같기도 하다.


2. 프로젝트 wsgi 설정

프로젝트 폴더에 이런식으로 파일을 만든다.

wsgi.py

from flask_app import app

if __name__ == '__main__':
    app.run()

uwsgi.ini

[uwsgi]
plugin = python3
module = wsgi:app

master = true
processes = 3

socket = /tmp/PROJECT.sock
chmod-socket = 664
vacuum = true

die-on-term = true

plugin = python 은, uwsgi 를 apt로 설치해서 필요한 것 같다.

pip 으로 설치하면 필요없을 듯?


3. systemd unit 생성

/etc/systemd/system/ 경로에 PROJECT.service 로 파일을 만든다.

[Unit]
Description=uWSGI instance to serve PROJECT
After=network.target

[Service]
User=ubuntu
Group=www-data
WorkingDirectory=/PATH/TO/PROJECT
#Environment="PATH=/PATH/TO/BIN"
ExecStart=/usr/bin/uwsgi --ini uwsgi.ini

[Install]
WantedBy=multi-user.target

뭐 User, Group 이라던가 적당히 해주고, 그 밑에 WorkingDirectory, 환경변수, 실행커맨드 등도 적당히 수정해준다.


이 후

sudo systemctl enable PROJECT

sudo systemctl start PROJECT

이렇게 자동 실행 설정 및 서비스 시작 해주면 된다.


4. Nginx 설정

sites-available 등의 설명은 생략.


아래와 같이 구성하자. 수정이 필요하다면 적당히 수정...


server {
        listen 80;
        server_name 사이트주소;

        location / {
                include uwsgi_params;
                uwsgi_pass unix:///tmp/PROJECT.sock;
        }
        location /static {
                alias /PATH/TO/PROJECT/flask_app/static;
        }
}

업스트림 설정으로 분산화를 하거나, uri 에 따라 다른 프로젝트로 연결하는 것도 가능하다. 이건 내가 쓸일 있을때 수정해둘거임.


5. 로그 보기

프로젝트 폴더에 만들었던 uwsgi.ini  에서 log 파일 경로를 지정할 수도 있지만,

sudo journalctl -u PROJECT 로 볼 수도 있다.

uwsgi 관련 로그는 여기에서,

접속 기록이나 파이썬 에러 로그 등은

/var/log/nginx/access.log, /var/log/nginx/error.log 에서 확인할 수 있다. 물론 설정에서 각각 바꿔줬으면 다르겠지?



참고

How To Serve Flask Applications with uWSGI and Nginx on Ubuntu 18.04 (DigitalOcean)

uWSGI documentation

Posted by iolate

tar 압축/해제

Linux, Ubuntu / 2018.09.10 03:40

맨날 검색하다가 작성.


압축

$ tar -zcf [.tar.gz] [...]


압축 해제

$ tar -zxf [.tar.gz]


옵션

-f: use archive file or device ARCHIVE

-c: create a new archive

-x: extract files from an archive

-z: filter the archive through gzip


-p: extract information about file permissions (default for superuser)

-t: list the contents of an archive

-v: verbosely list files processed

Posted by iolate
TAG tar, tar.gz

서버에서 

push "redirect-gateway def1 bypass-dhcp"

push "dhcp-option DNS 10.0.2.220"

이런류의 설정을 넣어두면, OpenVPN 으로 연결시 모든 트래픽이 VPN 을 통하게 된다.


이를 client 설정 파일에서 override 할 수 있는데, 여러 방법이 있지만 설정파일을 이용하는 방법을 기술.

다른 방법은 아래 참고 URL 로 들어가보자.


위 서버 설정에서의 첫번째 줄, push ~~ def1 ~~ 어쩌구 설정을 썼다면 client 설정 파일에 아래 라인들을 포함하면 된다.

route 0.0.0.0 192.0.0.0 net_gateway
route 64.0.0.0 192.0.0.0 net_gateway
route 128.0.0.0 192.0.0.0 net_gateway
route 192.0.0.0 192.0.0.0 net_gateway


만약 서버에서 def1 옵션을 사용하지 않았을 경우 아래 와 같은 방법으로.(뭐가 다른진 잘 모르겠다)

route 0.0.0.0 128.0.0.0 net_gateway
route 128.0.0.0 128.0.0.0 net_gateway



+

위 방법까지만 하면 VPN 대역만 라우팅될텐데, 나같이 내부망에 VPN 서버 파두고 쓰는 경우엔 추가로 라우팅 테이블을 수정해야 한다.

내가 사용하려는 내부망은 10.0.0.0/8 대역을 사용하고, DNS 설정도 필요하니 아래와 같이 설정을 추가

route 10.0.0.0 255.0.0.0
dhcp-option DNS 10.0.2.220


DNS 설정의 경우 VPN 클라이언트 옵션에서 "수동으로 설정한 네트워크 설정 변경"을 허용해주어야 한다.

이건 클라이언트마다 다르니 알아서 찾아서 켜주도록 하자.



참고

https://community.openvpn.net/openvpn/wiki/IgnoreRedirectGateway

https://serverfault.com/a/631048

Posted by iolate

ubuntu 17 부터인지

ifupdown 대신 netplan 이 네트워크 설정을 담당하고,

기본 nameserver 로는 127.0.0.53, systemd-resolved 가 작동하면서 알아서 질의한다.


같은 시기에 설치한 ubuntu 18 서버 두대 중 한대가 dns 질의가 안되었는데,


$ nslookup google.com

Server: 127.0.0.53

Address: 127.0.0.53#53


** server can't find google.com: SERVFAIL


$ sudo journalctl -u systemd-resolved -f

Jun 26 18:53:46 hostname systemd-resolved[688]: Got packet on unexpected IP range, refusing.



대충 이런 상황...?


원인을 찾아보니 황당하게도 iptables 설정 문제.

포트 포워딩을 하면서 SNAT 을 위해 아래와 같이 설정해두었는데 이게 문제였다.

# iptables -t nat -A POSTROUTING -j MASQUERADE



로컬 인터페이스에 대해서도 SNAT 이 걸려서 뭔가 문제라고 판단을 하였고, 

# iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE

이렇게 네트워크 인터페이스를 지정해주고 문제 해결.


참고로 네트워크 인터페이스 지정을 안해주니 sudo 도 hostname 을 제대로 못찾아서 에러를 낸다.

127.0.1.1 주소를 /etc/hosts 파일에 hostname 과 연결해주면 해결되지만, (또 그렇게 연결해두라고 하지만)

SNAT 설정을 안해두면 애초에 이 문제가 발생하지 않음.


여튼 해결.

Posted by iolate

Ubuntu 12.04 에서 openswan 을 사용하여 l2tp 서버를 설치한 글은 - 우분투 L2TP VPN 설치/설정법



요즘에 IKEv2 라는거 사용을 권장하는 것 같긴 하지만, 일단 귀찮으니 그냥 L2TP 를 사용해보도록 하자.


1. IPSEC

Ubuntu 16.04 부터는 openswan 이 기본 repository 에 제공되지 않는다. 대체품으로 strongswan 을 설치하자.

strongswan 을 사용하면서 설정이 조금 다른데, 이걸 제외하면 이전 글과 동일하다.


# apt-get install strongswan

# vi /etc/ipsec.conf

더보기


# vi /etc/ipsec.secrets

더보기


# service ipsec restart


2. xl2tpd

이전 글과 똑같다. 귀찮으니 딱 필요한 부분만 적겠음.


# apt-get install xl2tpd ppp

# vi /etc/xl2tpd/xl2tpd.conf

더보기


# vi /etc/ppp/options.xl2tpd

더보기


# vi /etc/ppp/chap-secrets

더보기


# service xl2tpd restart


3. iptables

# iptables -A FORWARD -s 10.7.0.0/24 -j ACCEPT

# iptables -t nat -A POSTROUTING -s 10.7.0.0/24 -o eth0 -j MASQUERADE


$ echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf




* 안되면 재부팅을 해보자. 아마 IPSEC 설치 후 재부팅을 해야하는 것으로 안다.(아닐수도)

Posted by iolate


쓸일이 있어서... 응시를 했다. (무쓸모가 될 가능성이 높지만)


LPIC-1 은 101-400, 102-400 두개의 시험을 쳐서 통과하면 자격을 준다.

왜 아직 Certifications 에 아무것도 없는진 모르겠지만 시간이 지나면 넣어주겠지...

글 수정하는 동안에 Certificate 메일이 왔다.


시험당 60문제, 800점 만점에 500점 이상시 통과. 60문제인데 문제마다 배점이 다르다.

시험당 $170 였는데, 난 결제하니 한화로 20만 9천원 정도 나오더라.. 두개보면 42만원..ㅠㅠ


원래 리눅스를 쓰던 사람이라면 대부분의 문제의 답을 이미 알거나, 한번 보면 바로 알 정도의 난이도?

물론 주로 사용하는 배포판에 따라 좀 갈리긴 할 듯.


근데 그런거 상관없이 덤프에서 보기 순서 안바꾸고 나오니 암기만 잘하면 딸 수 있다... 그래서 더 돈이 아깝다..



시험 응시

1. lpi.org 에서 회원가입 및 LPI ID 를 발급받는다.

2. Pearson VUE 에서 시험 신청을 한다

1) 회원가입 및 로그인

2) For test taker

3) LPI 검색

4) LPI ID 입력

5) 원하는 시험장소 및 시험시간 선택 (시험 장소에 따라 가능일자 / 시간이 다르다)

6) 결제

3. 시험장소(보통 학원)에 응시하러 간다

1) 시험치러 왔다고 말한다

2) 신분증, 같은 이름의 카드(영문 이름 때문인 듯)가 필요

3) 서명하고 사진촬영

4) 컴터 앞에 앉아서 시험치고 끝


시험 시간은 응시 장소에 따라 꼭 정해진 시간을 지킬 필요는 없는 것 같다. 30분 일찍 갔는데 그냥 쳤음.



덤프

내가 구한 덤프는

- 2015년 4/8월자 덤프(101-400, 102-400). 85~120문제 정도로 구성

- 2012년 12월 28일자 덤프(117-101, 117-102). 50여문제를 한 Exam 으로 해서, 여러개 시험으로 구성. 70~110페이지


* 원래 117-101, 117-102 란 이름이였는데 각 101-400, 102-400 으로 바뀌었다.


인데, 첫번째꺼만 봐도 될 듯. 두번째껀 그냥 앞쪽 시험 2개 정도만 훑어보고 들어갔다.



101-400

커널과 관련된 부분은 그냥 외웠고, 그걸 제하면 한번씩 해봐서 알거나, 새로운 명령어 하나 배운다는 기분으로 공부했다.

물론 덤프에 나오는 문제 위주로.


117-101 덤프에서도 몇문제 나왔는데, 뭐 몰라도 통과할 수 있거나 안봤어도 맞출 수 있었을 듯

8분만에 풀고 나왔다. 너무 일찍 나왔다고 다음 시험은 그러지 말라더라.


+ 1월 9일 오늘 아는 사람이 응시하고 왔는데, 101-400 덤프에서 1문제 정도 나오고 다 달라서 당황하셨다고 한다. 다행히 500/500 으로 통과하셨다지만... 102-400 은 그대로 나왔다고 하네... 왜지?;;


102-400

xwindows, 프린터(cups) 같은 것들이 나오는데 난 거의 안써본 것들이라 외웠다.

쉘스크립트나 네트워크 쪽 문제들은 그냥저냥...

뜬금없이 SQL 쿼리가 나오는데(리눅스 시험에서 대체 왜?) 뭐... 어렵진 않다.


전체적으로 101-400 에 비하면 덤프를 처음 봤을때 답을 모르겠는 문제들이 많았음.

근데 어차피 덤프보고 공부/외우면 된다. 102-400 덤프에서 다 나온 것 같다.


102-400 덤프에 문제 오류가 3~4개 정도 있었던 것 같은데.. 그냥 스스로 고칠 수 있거나 틀려도 탈락 안한다.

117-102 덤프는 설명이 다 달려있어서 좋더라.


마찬가지로 8분만에 다 풀었는데, 앞시험에서 나오고 나니 30분 정도는 앉아있어 달라고 하셔서 나머지 20분을 멍하게 시간때우다가 나왔다.



총평

시험치기 전날 2~3시간 정도 보면 매우 쉽고 무난하게 통과한다.

리눅스 시스템을 처음 접한 사람이라면 잘 모르겠다.


뭐 틀렸는지 안 알려준다. 궁금하다.


Posted by iolate

교내망에 있는 서버 하나가 접근이 꼬여서 원인을 찾다가 기록함.


우선 서버들의 네트워크 구성


메인서버 - Windows Server 2012 R2    - 교내망(10.x.x.5), 가상 스위치(192.168.137.1, host)

서버 A - Ubuntu 14.04                  - 교내망(10.x.x.6), 가상 스위치(192.168.137.6), 도커

서버 B - Ubuntu 14.04                  - 교내망(10.x.x.7), 가상 스위치(192.168.137.7)

서버 C - CentOS                            - 가상 스위치(192.168.137.2)


교내 다른 장비에서 메인서버, 서버 B 로는 교내망 주소로 바로 접근이 되는데,

서버 A 는 교내망 주소를 사용해도 서버 B 를 거쳐야만 접속이 되었다.

똑같은 교내망 IP 인데 말이지..


원인을 찾아보다가 서버 A의 outbound ip 가 메인서버의 ip 로 찍히는 것을 발견,

기본 라우터 설정을 바꿔주면 왠지 해결될 것 같은 느낌이 왔다.


서버 A:~$ ip route list

default via 192.168.137.1 dev eth1 

10.x.x.0/23 dev eth0  proto kernel  scope link  src 10.x.x.6 

172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 

192.168.137.0/24 dev eth1  proto kernel  scope link  src 192.168.137.6

서버 B:~$ ip route list

default via 10.x.x.1 dev eth0 

10.x.x.0/23 dev eth0  proto kernel  scope link  src 10.x.x.7 

192.168.137.0/24 dev eth1  proto kernel  scope link  src 192.168.137.7 


이유는 모르겠지만 서버 A의 기본 라우터가 eth1 로 되어있다. 바꿔주자.


서버 A:~$ sudo ip route change to default dev eth0 via 10.x.x.1

서버 A:~$ ip route list

default via 10.x.x.1 dev eth0 

10.x.x.0/23 dev eth0  proto kernel  scope link  src 10.x.x.6 

172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 

192.168.137.0/24 dev eth1  proto kernel  scope link  src 192.168.137.6



via 뒤의 아이피는 eth0 의 gateway 주소를 적어주면 된다.


이후 ssh 접속이 잘됨을 확인.

재부팅해도 유지된다.


왜 바뀌었는지 모르니 다음에 또 바뀔 가능성이 있을 수 있지만.... 일단 해결!

Posted by iolate

최근에 달린 댓글

최근에 받은 트랙백

글 보관함