Vai jūsu VM izmanto hosta VPN? Pārbaudiet viesa iekšienē

Pārbaudāt hosta publisko IP, tas rāda VPN, un jūs secināt, ka VM ir aizsargāta. Šo secinājumu tests neapstiprina. Viesim ir sava maršrutēšanas tabula, savs risinātājs un savas saskarnes, un hosta izejas adrese par tām neko nepasaka.

Testam jānotiek viesa iekšienē, un tam jānosauc, kas tika mērīts.

Sāciet viesa iekšienē, nevis hosta pārlūkā

Vispirms pierakstiet hipervizora tīkla režīmu: NAT, bridged, host-only vai macvtap. NAT režīmā hosts maršrutē viesa datplūsmu, tāpēc hosta tunelis var būt spēkā vai nebūt atkarībā no tā, kā klients instalē maršrutus. Bridged režīmā viesis ir līdzvērtīgs dalībnieks fiziskajā LAN, un hosta tunelis nav svarīgs. Šie divi režīmi dod pretējas atbildes no vienas un tās pašas hosta konfigurācijas.

Pierakstiet režīmu pirms kaut ko mainīt, jo tieši tas nosaka, ko rezultāts var nozīmēt.

Veiciet vienu pieprasījumu, kura galamērķi jūs zināt

Izmantojiet nekaitīgu pieprasījumu pakalpojumam, kas ziņo, kādu avota adresi tas redzēja. Pēc tam pārbaudiet paša viesa maršrutēšanas lēmumu šim galamērķim: ip route get 203.0.113.5 izdrukā saskarni un vārteju, ko viesis izmantos.

Ja saskarne ir viesa parastā NIC, datplūsma neiet caur tuneli viesa iekšienē.

Otrs adapteris, starpniekservera iestatījums vai viesa pusē esošais VPN klients var mainīt atbildi vienai lietojumprogrammai, bet ne citai. Pārbaudiet lietojumprogrammu, kas jums patiešām ir svarīga, nevis vispārīgu pieprasījumu no čaulas.

Pārbaudiet risinātāju atsevišķi

Mainīta izejas adrese nepasaka, kurš risinātājs apstrādāja šo resursdatora nosaukumu. Vaicājiet nosaukumu tieši ar platformai atbilstošo rīku un pierakstiet, kurš serveris atbildēja. Split DNS nozīmē, ka risinātāja jautājumam un maršrutēšanas jautājumam ir atšķirīgas atbildes.

Šie divi var atšķirties jebkurā virzienā, un tieši šī atšķirība bieži ir īstā kļūda.

systemd hostā resolvectl query nosauc saskarni un DNS serveri aiz atbildes. Vecākas konfigurācijas rāda serveri dig izvadē. Jebkurā gadījumā būtība ir redzēt, kurš serveris atbildēja, nevis tikai to, vai atbilde atnāca.

Pārbaudiet atteices politiku, ne tikai panākumus

Ja prasība ir tāda, ka neviena datplūsma neiziet ārpus tuneļa, veiksmīgs pieprasījums neko nepierāda. Izmantojiet klienta atbalstīto kontrolētās atteices testu: apturiet tuneli atbalstītajā veidā un pārbaudiet, vai jauns viesa pieprasījums tiek bloķēts. Nepieņemiet, ka hosta klienta kill switch aptver katru virtuālās pāradresācijas shēmu. Tā dokumentētais tvērums ir vienīgais, uz ko varat paļauties.

Viesis, kas tuneļa zuduma gadījumā atgriežas pie fiziskās NIC, dara tieši to, ko atļauj NAT režīms.

Pierakstiet režīmu un tvērumu

Pierakstiet hipervizora režīmu, viesa saskarni un maršrutu, risinātāju un pārbaudīto lietojumprogrammu. Pievienojiet datumu, jo momentuzņēmuma atjaunošana vai hipervizora atjauninājums var mainīt visus četrus.

Ja IPv4 sekoja tunelim, tā arī sakiet. Nepaplašiniet apgalvojumu uz IPv6, citu vārdtelpu vai citu VM citā tīklā.