소스 포트 규칙이 SSH 경로 하나를 깨뜨리는 이유
«sport 22» 일치는 응답이 어느 SSH 항목에 속하는지 말하지 않습니다. 정책 규칙을 WAN 전용 테이블 하나가 아니라 관리 흐름으로 한정하십시오.
한 호스트에 두 개의 관리 항목, 하나의 서비스 포트, 그리고 둘 다를 돕기 위한 정책 규칙이 있습니다. 규칙은 소스 포트 22와 일치하고, WAN 기본값만 아는 테이블로 조회를 보내며, VPN 항목은 새 로그인에 응답하지 않지만 직접 항목은 계속 작동합니다. 선택자를 제대로 읽으면 이 중 신비로운 것은 없습니다. 소스 포트는 서비스를 식별할 뿐 연결이 도착한 경로를 식별하지는 않습니다.
두 항목, 하나의 서비스 포트
호스트에는 LAN 측 주소와 VPN 주소가 있고 sshd는 둘 다에서 수신합니다. 따라서 직접 세션과 터널 세션은 서비스 포트를 공유하며 어느 로컬 주소가 연결을 받는지만 다릅니다.
그 차이만으로 응답 경로를 고를 수 있으며, 포트 기반 규칙이 버리는 것이 바로 그 차이입니다. 두 세션 모두 소스 포트가 22인 응답을 만들므로 그 포트와 일치하는 규칙은 둘을 분리할 수 없습니다. 규칙은 두 조회를 같은 테이블로 보내고, 그중 하나는 맞지 않는 답을 받습니다. 해결책은 실제로 다른 속성과 일치시키는 것입니다.
각 항목에 자체 포트를 주는 방법도 작동하며, 그것을 요구 사항으로 보는 것은 SSH의 속성이 아니라 설계 선택입니다.
규칙을 읽고, 그다음 테이블을 읽으십시오
정책 규칙은 정렬된 선택자이며, 사용 가능한 답을 반환하는 첫 규칙이 조회를 끝냅니다. 목록을 순서대로 읽고 어느 규칙이 이길 수 있는지 주목하십시오.
그다음 그 규칙이 가리키는 테이블을 읽어야 하는 것은 성공적으로 해석되는 규칙이 유용하게 해석되는 규칙은 아니기 때문입니다. 기본 경로만 있는 테이블은 VPN에서 온 응답을 WAN 인터페이스 밖으로 보냅니다. 이후 테이블의 더 구체적인 경로는 결코 조회되지 않으며, 두 번째 테이블을 추가해도 아무것도 바뀌지 않는 경우가 많은 이유입니다. 살펴봐야 할 것은 선택된 테이블입니다.
ip -4 rule show
ip route show table 100
ip route show table main이 두 출력을 함께 보아야 결과를 설명할 수 있으며, 어느 하나만으로는 잘못된 결론으로 이끕니다.
규칙을 의도한 흐름으로 한정하십시오
두 항목을 가르는 속성은 로컬 소스 주소입니다. 그 주소와 일치하는 규칙은 터널 세션만 개인 테이블로 보내고 직접 세션은 기본 테이블에 남깁니다.
그 규칙은 개인 경로와 해당 서브넷의 반환 경로를 담은 테이블과 짝을 이루어야 합니다. 둘 다 호스트의 모든 서비스가 아니라 관리 트래픽으로 한정하십시오. 그 주소에서 오는 모든 트래픽을 잡는 규칙은 호스트가 거기서 보내는 다른 모든 것도 리디렉션합니다. 여기서는 다음 사람이 그것을 읽어야 하기 때문에 좁은 것이 영리한 것을 이깁니다.
sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1두 항목이 하나의 로컬 주소로 변환되면 그 구별이 사라지고 설계에는 대신 연결을 인식하는 상태가 필요합니다.
리스너, 권한, 응답 선택을 분리하십시오
세션이 작동하려면 주소가 존재하고, 서비스가 그곳에서 수신하며, 응답이 돌아갈 길을 찾는 세 가지 별개의 조건이 참이어야 합니다. 경로 변경은 세 번째만 고칩니다.
리스너 구성은 자체 파일과 자체 다시 로드를 가지며, 여러 수신 주소는 정상입니다. 인증은 다시 세 번째 결정이며, 라우팅 예외는 누구에게도 접근을 허용하지 않습니다. 두 항목 모두에서 호스트 키 검증, 계정 인증, 소스 제한을 유지하고, 하나의 관리 경로가 작동하도록 터널의 다른 제어를 약화하려는 유혹에 저항하십시오.
여기서의 실수는 수정 자체를 막기 때문에 변경하는 경로에 의존하지 않는 복구 채널을 유지하십시오.
오래된 세션이 아니라 새 세션으로 증명하십시오
이미 설정된 터미널은 변경 전에 허용되었기 때문에 아무것도 증명하지 않습니다. 의도한 각 항목을 통해 새 세션을 여십시오.
ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30그다음 VPN 재연결을 반복하고 다시 시도해야 하는 것은 재연결을 견디는 경로가 재연결이 비우는 테이블에 추가된 경로와 같지 않기 때문입니다. 거부된 소스를 허용된 것과 따로 관찰하여 차단된 시도가 작동하는 세션 뒤에 숨지 않게 하십시오. 로컬 주소, 규칙, 테이블을 결과 옆에 저장하십시오. 대신 포트를 나눈다면 SSH의 한계가 아니라 운영 결정으로 기록하십시오.