A e përdor VM-ja e juaj VPN-në e hostit? Testojeni brenda guest-it

Kontrolloni IP-në publike të hostit, ajo tregon VPN-në dhe konkludoni se VM-ja është e mbuluar. Ky konkluzion nuk mbështetet nga ky test. Guest-i ka tabelën e vet të routing-ut, resolver-in e vet dhe ndërfaqet e veta, dhe adresa e daljes e hostit nuk thotë asgjë për to.

Testi duhet të ekzekutohet brenda guest-it dhe duhet të përmendë çfarë mati.

Filloni brenda guest-it, jo në shfletuesin e hostit

Regjistroni së pari modalitetin e rrjetit të hypervisor-it: NAT, bridged, host-only ose macvtap. Në modalitetin NAT hosti i bën routing trafikut të guest-it, prandaj tuneli i hostit mund të zbatohet ose jo, në varësi të mënyrës se si klienti instalon rrugët. Në modalitetin bridged guest-i është një pjesëmarrës i barabartë në LAN-in fizik dhe tuneli i hostit është i parëndësishëm. Këto dy modalitete japin përgjigje të kundërta nga i njëjti konfigurim i hostit.

Shkruani modalitetin përpara se të ndryshoni çdo gjë, sepse ai përcakton çfarë mund të nënkuptojë rezultati.

Bëni një kërkesë, destinacionin e së cilës e dini

Përdorni një kërkesë të padëmshme drejt një shërbimi që raporton adresën e burimit që pa. Më pas kontrolloni vendimin e routing-ut të vetë guest-it për atë destinacion: ip route get 203.0.113.5 shtyp ndërfaqen dhe gateway-in që do të përdorë guest-i.

Nëse ndërfaqja është NIC-i normal i guest-it, trafiku nuk kalon nëpër një tunel brenda guest-it.

Një adaptor i dytë, një cilësim proxy ose një klient VPN në anën e guest-it mund të ndryshojnë përgjigjen për një aplikacion dhe jo për një tjetër. Testoni aplikacionin që ju intereson vërtet, jo një kërkesë të përgjithshme nga një shell.

Kontrolloni resolver-in veçmas

Një adresë daljeje e ndryshuar nuk ju tregon cili resolver trajtoi atë emër hosti. Pyetni emrin në mënyrë eksplicite me mjetin që i përshtatet platformës dhe shënoni cili server u përgjigj. Split DNS do të thotë që pyetja për resolver-in dhe pyetja për routing-un kanë përgjigje të ndryshme.

Këto të dyja mund të ndryshojnë në çdo drejtim, dhe pikërisht ky ndryshim është shpesh bug-u i vërtetë.

Në një host me systemd, resolvectl query emërton ndërfaqen dhe serverin DNS pas përgjigjes. Konfigurimet më të vjetra e shfaqin serverin në daljen e dig. Në çdo rast, çështja është të shihni cili server u përgjigj, jo vetëm nëse erdhi një përgjigje.

Testoni politikën e dështimit, jo vetëm suksesin

Nëse kërkesa është që asnjë trafik të mos dalë jashtë tunelit, një kërkesë e suksesshme nuk provon asgjë. Përdorni testin e kontrolluar të dështimit që mbështet klienti: ndaloni tunelin në mënyrën e mbështetur dhe shihni nëse një kërkesë e re e guest-it bllokohet. Mos supozoni se kill switch-i i klientit të hostit mbulon çdo skemë të forwarding-ut virtual. Shtrirja e tij e dokumentuar është e vetmja gjë ku mund të mbështeteni.

Një guest që kthehet në NIC-in fizik kur tuneli bie po bën pikërisht atë që lejon modaliteti NAT.

Regjistroni modalitetin dhe shtrirjen

Shkruani modalitetin e hypervisor-it, ndërfaqen dhe rrugën e guest-it, resolver-in dhe aplikacionin që testuat. Shtoni datën, sepse një rikthim snapshot-i ose një përditësim i hypervisor-it mund të ndryshojë të katërta.

Nëse IPv4 ndoqi tunelin, thojeni. Mos e zgjeroni pohimin në IPv6, një namespace tjetër ose një VM tjetër në një rrjet tjetër.