제가 IPsec vpn 을 구축을 하였습니다.
서버 1. <-----> aws site-to-site <--------> aws instnace
ip : 공인 IP1개 ip 대역 : 10.30.0.0/16
ip2: 10.100.0.2
위와 같이 구성을 진행하였고, 서버1에 openswan를 사용해서 구축했습니다.
정상적으로 vpn 이 연결이 됐습니다.
문제는 10.100.0.2 에서 이제 10.100.0.0/24 대역의 IP를 가진 아래 서버들한테 트래픽 전송이 안됩니다.
아래 서버들 끼리 통신은 잘 되지만, 10.30.0.0/16에서 넘어오는 트래픽만 수신이 안됩니다.
ex) 10.100.0.10 -> 10.30.0.10 으로 ping을 요청할 경우,
10.30.0.10 까지 잘 도달하지만 ping reply를 받을 경우, 10.100.0.2 까지만 트래픽이 오고 거기서 10.100.0.10으로 오질 않습니다.
원인을 찾아봐도 모르겠습니다.
도움을 받고 싶습니다.
아래는 10.100.0.2 의 routing 정보입니다.
[root@set-hostname ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 100 0 0 eth0
10.100.0.0 0.0.0.0 255.255.255.0 U 101 0 0 eth1
<공인 IP대역> 0.0.0.0 255.255.255.0 U 100 0 0 eth0
서버는 xen 을 사용하여 vm을 띄워 사용중입니다.
NC은 2개의 서로 다른 물리 NIC이 꽂혀있고 eth0 (공인IP대역) 은 10G, eth1(사설IP대역) 1G nic으로 구성됐습니다.
net.ipv4.ip_forward = 1설정도 하였고, 모든 firewall 다 종료시키고 시도했었습니다..
감사합니다
ipsec 통신이 이뤄져서 그런것 같은데...
서버에서 curl ifconfig.me 입력으로
공인 ip 확인해보시기 바랍니다.
아마...
결과는 aws에서 어떻게 설정되어 있을지는
모르겠으나...
10.100.0.2에 대한 외부 공인 NAT설정이
안되어 있어서 인터넷 통신이
모두 안될 겁니다.
해결책으로는
openswan split-tunneling 설정을 통해서
aws 통신 대역에 대해서만
ipsec 통신이 이뤄지게 설정 변경하셔야
정상 통신이 이뤄지실겁니다.
그래서 10.100.0.10 서버에 route add -net 10.30.0.0/16 gw 10.100.0.2 설정을 주어 10.30.0.0 대역의 트래픽만 vpn을 타게 설정해놨습니다.
선생님 말씀은 VPN서버(10.100.0.2) 에도 NAT 기능을 추가해야한다는 말씀이실 까요??
내용 재확인 해보니...
아래 구조인것 같은데
10.100.0.10인 VM에서 통신 하신 것이 맞는지요?
Xen VM 10.100.0.10 >> vSwitch(bridge) >> Xen svr 10.100.0.2
>> openswan >> IPsec Tunneling >> IPsec VPN(AWS site to site) >> AWS VPC 10.30.0.10
이럴 경우 Xen 10.100.0.2에서 VM 10.100.0.10로 가는
라우팅 추가해 주셔야 될 것 같습니다만..
(다중 게이트웨이 설정 필수)
보통 위와 같은 Site to Site 구성의 경우
지금과 같은 문제로 매번 라우팅을 지속적으로 설정 관리해 주어야 되기 때문에..
Xen과 VM의 Gateway IP를 가진 측에서 Site to Site IPsec VPN 구성이 보편적입니다.
예시 #1
https://duck99.tistory.com/96
예시 #2
https://medium.com/saltware/openswan%EC%9C%BC%EB%A1%9C-aws-site-to-site-vpn-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0-9220a506acb3
예시 #3
https://blog.leedoing.com/32
다중게이트웨이 설정
https://warpnet.tistory.com/entry/Multiple-Gateway-%EB%8B%A4%EC%A4%91-%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4-%EC%84%A4%EC%A0%95
설명이 부족한 것 같아 정리해 드립니다.
10.100.0.10(물리) >> 10.100.0.2(xen, vpn) >> openswan >> ipsec (aws) >> aws vpc 10.30.0.10 이렇게 통신되고 있습니다.
10.100.0.10 과 10.100.0.2 가 현재 서로 통신이 잘 되고 있는 상황인데 어떤 라우팅을 추가해줘야할까요..?
10.30.0.0/16 트래픽은 vpn을 통해 공인 IP nic 으로 들어오고 다시 nic1(사설망)으로 나가야 하니깐
nic 간의 라우팅(브릿지???)을 잡으라는 말씀이신가요??
다중 게이트웨이 설정이라는 것이
[root@set-hostname ~]# route
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 100 0 0 eth0
default gateway 0.0.0.0 UG 101 0 0 eth1
10.100.0.0 0.0.0.0 255.255.255.0 U 101 0 0 eth1
115.68.158.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
이렇게 되면 된 것일까요.. (통신은 그대로 안됩니다.)
조언 부탁드립니다.
라우팅은 단순 IP Header 정보 기반으로 해당 경로로 무조건 보낸다고 보시면 됩니다.
이 상황에서..
현재 10.100.0.10에서 10.30.0.10으로의 통신이 되려면
하나의 통신이 이뤄지는 가장 작은 단위의 패킷 통신이 아래 과정으로 전달이 되어야 됩니다...
1차 : 10.10.0.10에서 10.30.0.10으로의 통신시 10.100.0.2로 보내라는 라우팅
2차 : 10.100.0.2에서는 openswan을 통해 10.30.0.10으로 통신시 ipsec service를 통해 암호화되어 eth0 gateway 공인IP를 통해 AWS Privite Gateway 으로 전달
3차 : AWS Privite Gateway에서는 암호화된 패킷을 복호화하여 VPC 10.30.0.10으로 전달
4차 : VPC 10.30.0.10에서 10.10.0.10으로 응답하여 라우팅 정보를 통해 AWS Privite Gateway로 전달
5차 : AWS Privite Gateway에서 암호화하여 10.100.0.2의 Default gateway eth0 공인 IP으로 전달
6차 : 10.100.0.2의 openswan을 통해 복호화된 src 10.10.30.10을 통한 10.10.0.10으로의 응답 패킷을 eth1을 통해 전달하라는 라우팅
7차 : 10.100.0.10 최종 1개 패킷 수신
여기서 현재 모든 구간의 라우팅 및 통신에 대한 확인은 기존 확인 하셨을것으로 유추되는 tcpdump를 통해 확인하셔야 되는데...
현재 설정상 6차에 대한 부분에서 2차 통신이 이뤄지는 라우팅과 연관되어 이상이 있는 것으로
해당 설정 통신이 이뤄지시려면 다중 게이트웨이 설정 및 개별 인터페이스에 대한 라우팅을 별도로 처리하셔야 되는 상황입니다.
이를 좀 더 편하게 하시려면...
10.100.0.2 및 10.100.0.10 의 사설 Gateway 장비와 공인 IP Gateway를 단일 장비에서 처리하고
해당 장비에서 IPSec VPN 설정을 통해 AWS Privite Gateway와 IPsec Tunneling을 구성하는 겁니다.
만약 10.100.0.2 및 10.100.0.10 의 사설 Gateway 장비와 공인 IP Gateway를 단일 장비에서 처리가 힘들면
다중 게이트웨이 설정을 각 서버에 설정하고 사설 Gateway 장비에서 IPsec Tunneling 설정을 통해
추가적인 IPsec 통신 장비 증가를 대응하는 것이 네트워크 기본 설계의 관건이라고 보여집니다.
우선 다중 게이트웨이 설정은 완료 하신 것으로 보입니다.
https://warpnet.tistory.com/entry/Multiple-Gateway-%EB%8B%A4%EC%A4%91-%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4-%EC%84%A4%EC%A0%95
"방식2"로 설정하셔야 되며....
(사유 : 6차 과정에서 openswan에서 복호화된 패킷이 무조건 eth0으로 전달됨)
해당 설정에서 6차 관련된 설정
"단계" 과정에서 10.100.0.2 설정된 인터페이스 eth1에 대해
라우팅설정 내용에 출발지 관련 도착지 설정을 추가하시면 됩니다만 적용시 많은 테스트가 필요할 겁니다;
경로 지정도 안 되어져있씁니다
실제로 10.30.0.0/16 에게 ping 을 했을 때, 해당 범위에 있는 서버에서 tcpdump해서 해당 트래픽을 받는 것을 확인했습니다.
경로 지정은 어디서 어디를 말씀하시는 것일까요..?
VPN 서버/클라를 돌리면 제대로 된 경우 route에 추가되는게 보통입니다
같은 서브넷이 아닌 이상 gw 지정 안 되서 route가 없으면 아무리 패킷을 반대편 네트워크로 가게 생성해도 길을 못 찾아갑니다
패킷 수신시 암호화하면서
해당 반대편 ipsec vpn 공인 통신되는
서버측 아이피로 패킹하여 라우팅에서는
안보이는 것으로 알고 있습니다^^;
제가 다루는 포티 장비로 예시를 드리면...
openswan은
별도 인터페이스가 생성 안되는
policy base ipsec vpn 으로 터널링됩니다.
https://ibb.co/Nrzp99Q
인터페이스를 생성하는 방식경우 이런식으로 추가되다보니 당연히 될줄 알았습니다
수신은 받은다음 처리해준다쳐도 발신할때는 어떻게 처리되나요?
시스템이 알아먹을려면 포트를 후킹하던지, 유닉스 장치를 생성하던지, 가상 인터페이스를 만들던지 시스템이 알아먹을 수 있는 형식으로 해줘야 호환성 보장될꺼라 생각됩니다
Point to Point 방식 비표준 VPN 프로토콜로 구성시 확인되는 라우팅으로 기억하는데 맞나요?
여튼 현재 "제발되라"님 구성이 조금 이상한게;;;
AWS Privite Gateway는
Site to Site IPsec VPN, Point to site IPsec VPN 구성으로
AWS Privite Gateway측이 Site로 구성됩니다만 현재 생각하신 구성이...
Point to Site IPsec VPN 구성에서...
Point 측 해당 대역 10.100.0.0/24 장비들이 라우팅으로 Point 장비에 통신을 보내면 Point 장비가 Site로 보내야 되는
각 패킷 처리를 상당히 골치아프게 하나의 인터페이스에서 라우팅 처리를 2중으로 해줘야 되는 상황이라서...
차라리 Gateway에서 IPsec VPN이 이뤄지는 Site to Site IPsec VPN 방식이 맞는데...
현재 Gateway인 10.100.0.3이 IPsec VPN 미지원되는 장비이신지
위와 같은 별도 라우팅처리로 10.100.0.2 서버 라우팅 설정으로 죽어나가셔야 되는 상황이네요;
그나마 해당 구성에서 편하게 관리하시려면...
strongswan, libreswan과 같이 Point측 IPsec VPN 데몬를 바꿔서
하기와 같이 인터페이스 생성하게 하시면 훨~~신 편하신겁니다만 기본 구성안 자체를 바꿔는것만 하겠나요^^
https://docs.strongswan.org/strongswan-docs/5.9/features/routeBasedVpn.html
https://libreswan.org/wiki/Route-based_XFRMi
원래 VPN GW가 되는 장비라도 추가로 더 지정할려면 상당히 귀찮은데, 아에 안 되는 장비면 파라메터에서 router or GW로 작동하도록 route 설정도 만지는등 더 귀찮았던걸로 기억합니다
확실히 저런식으로 수동 지정해주면 정적으로 지정한거니 큰 문제 없을꺼같네요 (작동 상태 확인이나 설정 확인도 더 편함)
아마 목적지 정보를 잃었다고 뜨실거에요 .
저랑 같은 케이스로 추정됩니다.
10.100.10.2로 접근할 대상 서버의 라우팅을 추가해주시면 좋을듯합니다.
1. 개요
1) 공인 IP 별도 부여와 함께 사설 IP를 부여하고 싶을 때의 방법을 정의한다.
2) 설계
- 외부망 NIC 추가
- 내부망 DB NIC 추가
2. 처리
1) IP 할당 이후 라우팅을 이용하여 게이트 웨이(GW)을 통해 접근할 수 있도록 한다.(방화벽 제어)
2) 명령어
- 라우팅 고정 파일
ADDRESS0=172.16.33.0
NETMASK0=255.255.255.0
GATEWAY0=172.16.31.1
ADDRESS1=172.16.30.0
NETMASK1=255.255.255.0
GATEWAY1=172.16.31.1
- 명령어
route add -net 172.16.33.0 netmask 255.255.255.0 gw 172.16.30.1 dev ens192
출처: https://devs.tistory.com/44 [내멋대로 내가 가는대로]
혹시.. 어이없게도.. aws의 Security Group 문제는 아니겠죠? ^^;;
알려주신 방법대로 해보았지만 알고보니.. 리눅스 rp_filter 기능을 종료시켜줘야 했습니다..
제가 vpn에 무지하여 터널링만 형성과 net.ipv4.ip_forward = 1 처리만 하면 다 통신이 되는 줄 알았는데 아니었네요..
스위칭 칩셋단에서 패킷 드롭으로 처리되어 OS단으로 안올라오던 패킷도 OS에서 처리될 터인데...
이러면 OS단 뚤려서 좀비 서버로
공격자 IP를 변조하여 타 서버 공격에 악용되어 작동될 여지가 있습니다. (IP Spoofing 공격)
때문에 차라리 별도 가상 인터페이스 생성 및 해당 인터페이스에 rp_fillter 해제 방식으로
IPsec Client를 작동시키는 방법으로 운영하시는 것을 추천드려요^^;
추가적으로
리눅스 네트워크 커널단 보안설정 관련 정보 공유드립니다~
http://zos.kr/bbs/board.php?bo_table=study&wr_id=112
rp_filter 를 종료시키면 일정시간 연결이 되다가 다시 끊기네요.. (10초 내외)
원인을 알 수가 없습니다..
모든 분들이 알려주신 방법을 다 사용해봤는데 잘 안되네요 ㅠㅠ
아래와 같은 구성이면 어떻게 하는 것이 좋을지 조언 해주실 수 있나요??
aws 인스턴스 <---> site to site <------------> idc vpn 서버(xen 가상서버) <----------> idc 물리 서버
10.30.0.0/16 10.100.0.2 10.100.0.0/24
+ 공인IP
해당 구성을 위해선 EC2에서 원본 소스를 확인하는 설정을 꺼 주셔야 합니다
인스턴스 -> 작업 -> 네트워크 -> 소스/대상 확인 에서 소스/대상 확인을 중지 시켜주세요.