일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Bull
- Sequelize
- nodejs
- MongoDB
- mongoose
- GIT
- TypeScript
- AWS
- MySQL
- Python
- jest
- nestjs
- OCR
- Nest.js
- game
- 공룡게임
- 게임
- 정렬
- class
- 자료구조
- cookie
- dfs
- react
- typeORM
- Dinosaur
- flask
- JavaScript
- Queue
- Express
- Today
- Total
포시코딩
How to connect wifi via wpa_supplicant, netplan in ubuntu 본문
우분투 리눅스에서 wpa_supplicant를 통해 wifi 연결하는 방법
개요
회사에는 달랑 파워선 하나만 연결되있는 조그마한 pc가 있다.
해당 pc 안에는 ubuntu OS 위에서 docker를 통해 여러 db와 server가 돌아가고 있었고
문제 상황 전에는 mongosh 등을 통해 해당 pc의 ip 주소로 접속이 가능했다.
처음엔 파워선만 연결되어 있는데 어떻게 이러지 싶었지만 아마 무선 랜카드가 꼽혀있어서 가능한게 아닐까 생각했다.
(입사 몇 달전부터 돌아가던 pc라 함부로 전원을 끄고 본체를 까보지 못했다.)
회사 건물에는 1층 ~ 4층 와이파이가 돌아가고 있었고
해당 pc에 3층, 4층 와이파이로는 접속되지만 1층, 2층 와이파이론 접속할 수 없었다.
근데 3층, 4층 와이파이 비밀번호를 바꾸는 과정에서 공유기 재부팅이 진행되었고
이후부터 해당 pc에 접근할 수 없게 되었다.
문제 파악
이전 회사에서 iptables.sh 파일을 통해 특정 ip들에 대한 접근을 허용하거나 막았던 경험을 떠올려 확인해봤는데
iptables.sh 파일은 아예 없었고
iptables, firwall, ufw, nft 방화벽들에 대해 탐색해보니
이중 작동중인 방화벽은 있지만 특정 ip 관련해서 따로 세팅되어 있거나 하진 않았다.
공유기 설정을 진행하셨던 분한테 물어보니 비밀번호 설정 및 재부팅 이후 절차에 따라
이전에 사용하던 고정 ip로도 다시 변경하셨다는 얘기를 들었는데
pc쪽에선 건드린게 없기에 공유기 재부팅과 접속에 대해 설정 관련 사항이 없을 것이고
공유기쪽도 매뉴얼에 따라 이전 고정 ip로 다시 설정했으니 문제가 뭔지도 모르는 상황이 발생했다.
..
그렇게 한참을 헤매다가
의심되는건 공유기에서 추가 내부적인 설정이 필요하거나..
공유기 비밀번호를 바꾸면 노트북에서 해당 와이파이가 끊어지듯
해당 pc에서도 무선 랜카드를 통해 연결되어 있던 와이파이가 끊어져 네트워크에서 아예 제외된게 아닐까하고 생각했다.
시행 착오
상황 전에는 3층, 4층 두 종류의 와이파이에 접속했을 때 연결이 됐었고
두 와이파이 모두 비밀번호가 변경 되었으니 두 와이파이에서 튕겨져 나갔을 것이다.
그렇다면 어떻게 동시에 두 와이파이에 연결되어 있었지? 하는 의문점이 생겼다.
일단 ubuntu에서 wifi를 연결하는 방법을 이리저리 찾아보았고 랜카드 설정 관련해서 힌트를 얻었다.
sudo lshw -C network
위 블로그에 나와있는 명령어를 입력해보니
*-network가 두 개가 떴다.
그렇다. 랜카드가 두개 꼽혀있었던 것
그럼 해당 랜카드들이 각각 3층, 4층 wifi를 잡아 연결하면 해결! 될듯 한데
검색을 통해 나오는 wifi 탐색 및 세팅 방법들에 대해 모든 명령어들이 통하질 않았다.
iwlist, iw 또는 기본으로 깔려있다는 nmcli 까지 not found가 뜨며 설치를 해야 사용 가능하다고 떴다.
심지어 /etc 폴더 안에 /sysconfig 가 없어서 다수의 구글링을 통해 나오는걸 적용하지도 못하는 상황
찾아보니 wifi를 탐색하려면 network-manager 또는 wpa_supplicant 둘 중 하나를 써야 한다고 한다.
nmcli, nmtui, iwctl 얘네들도 터미널 기반 도구로서 network-manager 또는 wpa_supplicant 둘 중 하나와 함께 사용한다고 한다.
그럼 둘 중 하나는 무조건 되야 정상이다.
NetworkManager 사용 확인
sudo service NetworkManager status
-> could not be found 뜸
wpa_supplicant 사용 확인
ps -ef | grep wpa_supplicant
실행 결과 wpa_suplicant 쪽에 실행된 아래 두 명령어를 포착할 수 있었다.
/sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
/sbin/wpa_supplicant -c /run/netplan/wpa-wlo1.conf -iwlo1 -Dn180211,wext
두 가지 인걸 보니 각각 두 개의 랜카드에 wifi를 세팅한거라고 생각했고
wpa_supplicant를 통해 진행했다는걸 유추할 수 있었다.
위 명령어 각각의 옵션 플래그는 다음과 같다.
- -u: D-Bus를 통해 wpa_supplicant를 제어하기 위해 사용
- -s: wpa_cli (wpa_supplicant 제어 인터페이스) 소켓을 생성
- -O: 컨트롤 인터페이스 소켓 디렉터리를 지정
- -c: wpa_supplicant 설정 파일의 경로 지정
- -i: 무선 인터페이스의 이름 지정
- -D: 드라이버 선택. 'n180211'과 'wext' 두 가지 드라이버 지정
옵션 플래그 설명에 따르면 -c 다음 오는 경로의 파일을 열어보면 뭐가 나오지 않을까 싶었다.
이 과정에서 권한 문제가 발생했는데
접속한 계정이 root는 아니지만 대부분의 권한이 있는 계정임에도 불구하고 permission denied가 발생해
chmod 755를 적용하여 억지로 열었다.
열어보니 아니나다를까 wifi 관련 내용이 들어있었다.
/run/netplan/wpa-wlo1.conf
network={
ssid=wifi이름
key_mgmt=WPA-PSK
psk=비밀번호
}
해당 파일에서 비밀번호를 수정했고
/run/wpa_supplicant 안에 있는 파일들은 권한 chmod 맨 앞에 s가 붙는 특이한 파일들이었고 딱히 건들지 않았다.
wifi 비밀번호를 수정했으니 이제 적용만 하면 되겠지 싶어서
위 wpa_supplicant 관련 명령어 두개를 실행해봤다.
결과는.. 실패
Successfully initialized wpa_supplicant
ioctl [SIOCSIWENCODEEXT] : Invalid argument
ioctl [SIOCSIWENCODEEXT] : Invalid argument
wlo1: Trying to associate with
wlo1: Associated with
wlo1: WPA: Key negotiation completed with
wlo1: CTRL-EVENT-CONNECTED - Connection to
이런식으로 출력되며 완료되지도 않았다.
다시 좀 찾아보니 해당 명령어에 대한 프로세스들이 올라가 있는 상태라
모두 죽인 후 실행해야 한다고 해서 아래 명령어들을 진행
sudo killall wpa_supplicant
/sbin/wpa_supplicant -c /run/netplan/wpa-wlo1.conf -iwlo1 -Dn180211,wext
/sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
하지만 결과는 마찬가지였다.
나중에 알고보니 해당 명령어들은 적용 시 자동 실행되는 명령어들이었다.
그래서 권한 문제도 있었던 것
해결 방법
해결 과정에서 어떤 시행착오를 겪었는지 알아봤으니
이제부터 깔끔하게 해결 방법에 대해 처음부터 진행해보자
수많은 시행착오를 거쳐 마지막에 성공한 걸 정리한 결과라
특정 과정이 생략되도 괜찮을지 진행하는게 맞았는지에 대한 확인이 필요한 상황이다.
때문에 그런 과정에 대해선 (생략)을 붙이도록 하겠다.
*(23.08.03 추가사항) 실제 테스트 결과 (생략)을 붙인 과정을 진행하지 않아도 wifi 세팅이 제대로 되는 것을 확인했다.
때문에 (생략) 과정은 참고 후 본인 필요에 따라 진행하고 일반적인 상황에선 생략한다.
1. wifi 장치 활성화 확인
ip addr
ip link show
위 두 명령어 중 하나를 입력하면 랜카드의 상태를 확인할 수 있다.
NO-CARRIER와 UP이 같이 있을 경우
- UP: 네트워크 인터페이스가 활성화되어 동작중이지만
- NO-CARRIER: 물리적으로 WIFI 연결이 끊어져있다는 뜻
2. wpa_supplicant 프로세스 종료 (생략)
sudo killall wpa_supplicant
3. 설정 관련 폴더 자동 생성 때문에 발생하는 충돌을 방지하기 위한 폴더 제거 (생략)
mv /run/wpa_supplicant /run/wpa_supplicant_backup
삭제보단 안전을 위해 폴더명 변경으로 진행했다.
4. 비밀번호 변경
sudo vim /etc/netplan/00-installer-config-wifi.yaml
5. 비밀번호 변경 2 (생략)
sudo vim /run/netplan/wpa-wlo1.conf
해당 파일이 4번 과정에서의 파일 수정 적용에 의한 결과물로 자동 생성된 것인지 확실치 않음
6. wifi 장치 비활성화, 활성화 (생략)
# wifi 장치 상태 확인
sudo ip link show
# wifi 장치 비활성화
sudo ip link set wlo1 down
sudo ip link set enp2s0 down
# wifi 장치 활성화
sudo ip link set wlo1 up
sudo ip link set enp2s0 up
# wifi 장치 상태 다시 확인
sudo ip link show
7. 변경된 netplan 적용
sudo netplan apply
8. 결과 확인
ping google.co.kr
9. 접속 확인
ssh 계정@ip주소 -p 22
mongosh 'address:port' --username root
정리하며
정리하고보니 변경된 비밀번호에 대해 wifi를 다시 잡는 방법은
netplan 파일만 수정 후 적용시켜주면 끝나는 매우 간단한 일이었다.
적용하면 wpa_supplicant 관련 설정 파일이 생성되고 이를 통해 연결하게 되는 것으로 보이는데
정작 한국인들이 작성한 글 중 netplan에 대해 조사해보니 대부분 고정 ip 적용할 때 쓰이고
wpa_supplicant에 대해서도 따로 조사해보면 netplan과 같이 쓰는 글들은 찾을 수 없었지만
해외쪽에선 netplan을 network management tool로써 사용해서
wpa_supplicant를 구성하는데 쓰이는 걸 볼 수 있었다.
https://devicetests.com/configuring-wpa-supplicant-ubuntu-server-wireless-networking
아무 정보도 없이 달랑 리눅스 서버 본체 하나만으로 해결하느라 꼬박 하루가 넘게 걸렸는데
그래도 덕분에 하나씩 풀어내면서 방탈출 하는 느낌으로 재밌게 진행했던 것 같다.
앞으로 공유기 설정이 다시 변경될 경우를 대비할수도 있게 되었으니
언젠가 누군가는 해야할 일인데다 공부도 되는 의미있는 시간이었지 싶다.
* 오타, 지적할 부분, 똑같이 했는데 안되는 부분, 보안상 위험해보이는 부분이 있다면
댓글 또는 메일로 연락 부탁드립니다.
'TIL' 카테고리의 다른 글
[study] Node CPU 점유율 최적화 관련 글 (0) | 2023.09.20 |
---|---|
7월20일 - [JS] process.exit, process.exitCode (0) | 2023.07.20 |
7월18일 - JavaScript의 비동기 작업와 블로킹 (0) | 2023.07.19 |
7월17일 - 패키지 매니저 비교 (npm, yarn, yarn-berry, pnpm) (0) | 2023.07.17 |
7월16일 - 자료구조 (Queue, Stack, Hash) with. JavaScript (0) | 2023.07.17 |