어제 여기 에 질문을 올렸지 만 내 말로는 충분하지 않다고 생각합니다. BTW,이 질문은 중복되지 않습니다.
아래와 같이 AWS VPC 설정이 있습니다.
목표 / 문제 : 인터넷에서 서버 A로 SSH. 그리고 작동하지 않습니다.
서버 A가 프라이빗 서브넷에 있으므로 인터넷에서 직접 서버 A로 ssh 할 수 있도록 내 NAT 인스턴스에서 iptables NAT를 활성화하려고합니다.
NAT 인스턴스에서 아래 명령을 실행했습니다.
NAT# iptables -t nat -A PREROUTING -p tcp --dport 2222 -j DNAT --to-destination 10.0.1.243:22
NAT 인스턴스에서 IP 전달이 활성화됩니다.
NAT# sysctl -p
net.ipv4.ip_forward = 1
MASQUERADE가 NAT 인스턴스에서 실행 중입니다.
NAT# iptables -t nat -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 6 packets, 312 bytes)
pkts bytes target prot opt in out source destination
199 16466 MASQUERADE all -- * eth0 10.0.0.0/16 0.0.0.0/0
이 테스트 사례에 필요한 다양한 액세스를 허용하도록 AWS 보안 그룹이 올바르게 구성되었습니다.
문제 해결:
포트 22에서 NAT에서 서버 A로 텔넷 할 수 있습니다. 따라서 액세스가 좋습니다.
telnet 54.213.116.251 2222
랩톱에서 실행할 때 NAT의 tcpdump 항목이 아래에 표시됩니다.
NAT# tcpdump -n -i eth0 dst 10.0.1.243 and port 22
09:59:13.738316 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
09:59:16.737009 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
09:59:22.775567 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,nop,sackOK], length 0
따라서 iptables가 패킷을로 라우팅한다는 의미 10.0.1.243
입니다. (BTW, xxx.xxx.xxx.xxx
내 노트북의 공용 IP 주소입니다)
그러나 서버 A에서 tcpdump를 실행할 때 10.0.0.54
NAT의 내부 / 개인 IP 주소가 무엇인지 알 수 없습니다 ( 그리고 이것이 문제라고 생각합니다 ).
Server A# tcpdump -n src 10.0.0.54
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
그러나 NAT 인스턴스에서 서버 A로 텔넷으로 연결하면 서버 A의 tcpdump에 좋은 내용이 표시됩니다 ( 이는 전체 PREROUTING
규칙이 예상대로 작동하지 않음을 의미 함 ).
Server A# tcpdump -n src 10.0.0.54
05:01:47.500080 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [S], seq 2862522431, win 14600, options [mss 1460,sackOK,TS val 3013083 ecr 0,nop,wscale 7], length 0
05:01:47.501601 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [.], ack 760676524, win 115, options [nop,nop,TS val 3013083 ecr 12074896], length 0
05:01:47.535720 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [.], ack 22, win 115, options [nop,nop,TS val 3013092 ecr 12074928], length 0
결론:
NAT의 tcpdump 출력에서 Iptables가 패킷을 올바르게 전달하는 것 같습니다.
서버 A의 TCP 덤프에서 NAT에서 서버 A 로의 연결이 양호합니다.
그러나 엔드 투 엔드에서는 랩톱에서 서버 A에 연결할 수 없습니다.
( BTW, 나는 SSH 터널과 다른 좋은 것들을 알고 있지만 Iptables만이 나를 도울 수 있기를 바랍니다. )
답변
마침내, 나는 그것을 깨뜨렸다 !!!!
NAT 인스턴스에서 아래 명령을 변경해야했습니다.
에서:
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/16 -j MASQUERADE
에:
iptables -t nat -A POSTROUTING -j MASQUERADE
그리고 그것은 작동했습니다 !!!!
따라서 ServerFault에서 위의 두 명령을 사용할 때의 장단점을 묻는 새로운 질문을 곧 만들 것입니다.
답변
- nat 상자의 보안 그룹
2222
에서 tcp 포트 inboud를 허용하는지 확인하십시오.0.0.0.0/0
- VPC “Route Table”이 올바르게 설정되어 있는지 확인하십시오.
- 최소한 두 개의 개별 테이블 (하나는 개인 서브넷과 관련되고 하나는 공개 서브넷과 관련)
- 당신의
10.0.1.0
목적지 : : (개인) 서브넷은 같은 경로 테이블 규칙이 있어야합니다0.0.0.0/0
, 대상 : “냇 상자” - 당신의
10.0.0.0
목적지 : : (공개) 서브넷은 같은 경로 테이블 규칙을 가지고 있어야0.0.0.0/0
, 대상 : “인터넷 게이트웨이” -
NAT 상자에 대해 NIC에서 소스 / 대상 확인 기능을 비활성화 했는지 확인하십시오 . (이미 이미 가지고 있지만 실제로 중요하므로 향후 시청자에게도 포함됨)
-
아웃 바운드 패킷이 어디로 가야하는지 확인하십시오.
iptables --table nat --append POSTROUTING --source 10.0.0.0/16 --destination 0.0.0.0/0 --jump MASQUERADE
-
inboud 패킷이
2222
올바르게 다시 라우팅되는지 확인하십시오 .iptables --table nat --append PREROUTING --protocol tcp --dport 2222 --jump DNAT --to-destination 10.0.1.243:22
답변
이 게시물은 AWS NAT를 이해하는 데 많은 도움이되었습니다. 그래서 나는 iptables -t nat -A POSTROUTING -j MASQUERADE
그것이 효과가 있었던 것을 조사하기 시작 했습니다.
위의 진술에서 찾은 대답은 NAT 상자가 NAT를 ‘LAPTOP’IP를 ’10 .0.0.54 ‘로 소싱하는 동시에 대상 NAT를 10.0.1.243으로 수행하도록 허용한다는 것입니다. 현재 개인 서브넷 상자는 NAT 장치에서만 들어오는 ssh 요청입니다. 이 명령은 실제로 개인 서브넷 서버의 보안을 감소시킵니다. 아래 명령을 사용하여 아래 언급 된 ssh 및 NAT 상자를 통해 개인 서브넷 액세스를 미세 조정하는 것이 좋습니다.
iptables --table nat --append POSTROUTING --source "INTERNET IP of the Laptop" --destination 10.0.1.243 --jump MASQUERADE
답변
조금 더 안전합니다 :
iptables -t nat -I PREROUTING -d 52.213.216.251 -j DNAT --to-destination 10.0.1.243:22
iptables -t nat -I POSTROUTING -s 10.0.1.243 -j SNAT --to-source 52.213.216.251