Điểm:-1

Dòng lệnh KVM nat

lá cờ wf
t09

Cách chính xác để thiết lập mạng NAT giữa KVM vm và máy chủ là gì?

KVM vm:

Không cài đặt tường lửa

$ sudo arp-scan -r 5 -t 1000 --interface=eth0 --localnet

10.0.2.2 52:55:0a:00:02:02 quản lý cục bộ
10.0.2.3 52:55:0a:00:02:03 quản lý cục bộ

$ ip r

mặc định qua 10.0.2.2 dev eth0 proto dhcp số liệu 100
10.0.2.0/24 dev eth0 liên kết phạm vi kernel proto src 10.0.2.15 số liệu 100

ifconfig

eth0: inet 10.0.2.15 netmask 255.255.255.0 phát sóng 10.0.2.255
      ête 52:54:00:12:34:56
lo: inet 127.0.0.1 netmask 255.0.0.0
      inet6 ::1

Chủ nhà:

:~$ ip r

0.0.0.0/1 đến 10.211.1.10 dành cho nhà phát triển0 
mặc định qua 192.168.1.1 dev wlan0 proto dhcp metric 600 
10.21xxxxxxxx dev tun0 liên kết phạm vi kernel proto src 10.21xxxxx 
xxxxxxxxxxxx dev wlan0 
128.0.0.0/1 qua 10.211.1.10 nhà phát triển tun0 
192.168.1.0/24 dev wlan0 liên kết phạm vi kernel proto src 192.168.1.172 số liệu 600 
192.168.4.0/22 ​​dev eth0 liên kết phạm vi kernel proto src 192.168.4.8 số liệu 100 

:~$ifconfig

 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    inet 10.0.2.3 netmask 255.0.0.0 phát sóng 10.255.255.255
    inet6 fe80::76c8:79b4:88d4:7f5c tiền tốlen 64 phạm vi 0x20<link>
    ether ec:8e:b5:71:33:6e txqueuelen 1000 (Ethernet)
    Gói RX 1700 byte 194730 (190,1 KiB)
    Lỗi RX 0 bị rớt 0 tràn 0 khung hình 0
    Gói TX 2862 byte 246108 (240,3 KiB)
    Lỗi TX 0 bị rớt 0 tràn 0 sóng mang 0 va chạm 0
    thiết bị ngắt 16 bộ nhớ 0xe1000000-e1020000  

 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
    inet 127.0.0.1 mặt nạ mạng 255.0.0.0
    inet6 ::1 tiền tốlen 128 phạm vi 0x10<máy chủ>
    vòng lặp txqueuelen 1000 (Local Loopback)
    Gói RX 13251 byte 7933624 (7,5 MiB)
    Lỗi RX 0 bị rớt 0 tràn 0 khung hình 0
    Gói TX 13251 byte 7933624 (7,5 MiB)
    Lỗi TX 0 bị rớt 0 tràn 0 sóng mang 0 va chạm 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
    inet 10.211.1.69 netmask 255.255.255.255 đích 10.211.1.70
    inet6 fe80::a920:941c:ffa8:5579 tiền tốlen 64 phạm vi 0x20<link>
    không xác định 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
    Gói RX 4348 byte 2242726 (2.1 MiB)
    Lỗi RX 0 bị rớt 0 tràn 0 khung hình 0
    Gói TX 3823 byte 404190 (394,7 KiB)
    Lỗi TX 0 bị rớt 0 tràn 0 sóng mang 0 va chạm 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
    inet 192.168.1.172 netmask 255.255.255.0 phát sóng 192.168.1.255
    inet6 fe80::651b:5014:7929:9ba3 tiền tốlen 64 phạm vi 0x20<link>
    ether d8:55:a3:d5:d1:30 txqueuelen 1000 (Ethernet)
    Gói RX 114455 byte 117950099 (112,4 MiB)
    Lỗi RX 0 bị rớt 0 tràn 0 khung hình 0
    gói TX 67169 byte 14855011 (14,1 MiB)
    Lỗi TX 0 bị rớt 0 tràn 0 sóng mang 0 va chạm 0 

~$ Sudo arp-scan -r 5 -t 1000 --localnet

treo thôi......

Máy chủ không thể ping 10.0.2.2

Không bật tường lửa

Cố gắng

$ Sudo ip route thêm mặc định qua 10.0.2.0
$ Sudo ip route thêm mặc định qua 10.0.2.2
$ Sudo ip route thêm mặc định qua 10.0.2.0/24

NAT có thể hoạt động mà không cần virsh không?

Có thể sửa lỗi NAT chỉ từ dòng lệnh không?

Cập nhật:

$ Sudo ip link add natbr0 type bridge
$ liên kết ip sudo thiết lập dev natbr0 lên
$ liên kết ip sudo thiết lập dev eth0 lên
$ sudo ip link set dev eth0 master natbr0

hoạt động để kết nối nô lệ eth0 với kvm - vm có thể ping các máy tính khác trên mạng. nhưng không phải người dẫn chương trình @Tom Yan trả lời kết hợp với archlinux-Network_bridge đã tạo các lệnh ở trên có thể ping ip mạng khác

Vì vậy, tôi đã cố gắng thay đổi kết nối cầu đang hoạt động để cho phép Máy chủ và kvm nói chuyện.

Mục tiêu: host$ ping kvm

$ Sudo ip link add natbr0 type bridge
$ liên kết ip sudo thiết lập dev natbr0 lên
$ sudo ip thêm 10.0.2.1/24 dev natbr0
$ sudo kvm -m 3G -hdb /dev/sde -nic bridge,br=natbr0
kvm$ Sudo ip link add natbr0 type bridge
kvm$ sudo ip thêm 10.0.2.2
kvm$ sudo ip link set dev natbr0 up
kvm có thể tự ping nó 

$ping 10.0.2.2

PING 10.0.2.2 (10.0.2.2) 56(84) byte dữ liệu
64 byte từ 10.0.2.2: icmp_seq=1 ttl=64 time=0,027 ms

nhưng kvm$ping 10.0.2.1

Máy chủ đích không thể truy cập

máy chủ $ ping 10.0.2.2

(chỉ treo)

Thích dòng lệnh hơn để kiểm tra khả năng phục hồi của xương trần của quy trình/hệ thống so với nhiều tập lệnh có thể gây ra nhiều lỗ hổng hơn. - dòng lệnh có hoạt động hay không và các lỗi dễ dàng được theo dõi, cách ly và tái tạo hơn. Tùy thuộc vào hương vị linux, một số tập lệnh/phần nhất định của tập lệnh (như các tập lệnh được tích hợp trong các giải pháp thay thế xml được cung cấp) có thể hoạt động hoặc không hoạt động. Nếu bắc cầu với kvm có thể được sao chép trên bất kỳ hương vị linux nào bằng cách thực hiện theo các lệnh ở trên.... thì có vẻ như kvm NAT cũng có thể đạt được bằng cách sử dụng các lệnh cli - chỉ để làm rõ quan điểm của bài đăng này, các bước cli để NAT kvm sẽ là tiêu chuẩn hóa hơn, vì vậy thích hợp hơn.

nói chung câu trả lời @NikitaKipriyanov là con đường chính xác, đây là câu trả lời nhưng yêu cầu điều chỉnh để ra lệnh

$ sudo kvm -m 3G -hdb /dev/sde -net nic -net user,hostfwd=tcp::1810-:22

sử dụng lệnh tweak vm có thể giao tiếp với internet như mặc định và cũng có thể giao tiếp với máy chủ thông qua ssh. ghi công cho @NikitaKipriyanov và @cnst cho tinh chỉnh https://stackoverflow.com/a/54120040

Người dùng sẽ cần ssh bằng cổng 1810 bằng địa chỉ localhost

$ ssh p@localhost -p 1810

lá cờ in
Thông tin từ `ip r` và `ip a` với thông tin về nic nào là từ KVM của bạn và cũng có thể dòng lệnh máy kvm của bạn sẽ giúp giải quyết vấn đề của bạn. ` -nic user,model=virtio` cung cấp cho bạn chế độ người dùng NAT Nếu những gì bạn muốn thực sự là tự nhiên từ Máy chủ đến mạng của bạn, thì: `iptables -t nat -A POSTROUTING -s $vmnet -j MASQUERADE` sẽ cung cấp cho bạn NAT
Nikita Kipriyanov avatar
lá cờ za
Điều này có trả lời câu hỏi của bạn không? [chuyển tiếp cổng máy chủ với qemu thông qua libvirt trong kết nối mạng ở chế độ người dùng](https://serverfault.com/questions/890520/host-port-forward-with-qemu-through-libvirt-in-user-mode-networking)
t09 avatar
lá cờ wf
t09
@NiKiZe : _iptables -t .... MASQUERADE_ đưa ra đầu ra : Đối số sai `MASQUERADE' . Và _iptables -t nat -A POSTROUTING -o Brii -j MASQUERADE_ được chấp nhận bởi máy chủ nhưng kvm vẫn không thể ping máy chủ hoặc internet
Nikita Kipriyanov avatar
lá cờ za
Lưu ý, bắc cầu không liên quan gì đến NAT và định tuyến. Đừng trộn chúng lên. Nếu bạn muốn bắc cầu, hãy xóa "NAT" và "ip route" và bạn bè ở mọi nơi, bạn sẽ không sử dụng nó. Máy ảo của bạn sẽ xuất hiện cùng với máy chủ của bạn trong một số mạng (đó có thể là mạng riêng của máy chủ và máy ảo, nhưng đó là một câu chuyện khác). Mặt khác, nếu bạn định sử dụng chế độ người dùng NAT, bạn chắc chắn không cần đến cầu nối (vì nó được phát triển để giải tỏa toàn bộ nhu cầu sử dụng cầu nối ngay từ đầu).
Nikita Kipriyanov avatar
lá cờ za
Câu trả lời khác (của @TomYan) là *câu chuyện khác* mà tôi đã đề cập. Anh ấy đề nghị bạn đi theo cách tiếp cận đó, tôi. đ. từ việc sử dụng chế độ người dùng NAT, bạn sử dụng NAT trong Hệ điều hành máy chủ. Đó là cách tiếp cận khả thi, nhưng nó chắc chắn *khó hơn* và *cồng kềnh hơn* so với việc chỉ đánh vần chính xác các tùy chọn dòng lệnh.
t09 avatar
lá cờ wf
t09
@Nikita Kipriyanov - tôi đang chạy thử nghiệm trên kvm để xem liệu nó có thể NAT giống như Virt-Manager mà không có nhu cầu về tài nguyên của trình quản lý tài nguyên nặng và tải nặng hay không. Tôi sẽ nghiên cứu ứng dụng cli của libvirt cho vấn đề này và đăng kết quả nếu thành công.
Điểm:1
lá cờ za

Ý tưởng chung của NAT là bạn không thấy địa chỉ dịch. Bạn không có tuyến đường đến họ. Họ không tồn tại cho bạn. Bạn chỉ thấy các địa chỉ được dịch sang.

Trường hợp QEMU không có gì khác biệt.Trong trường hợp này, Máy chủ của bạn ở "bên ngoài", VM của bạn ở "bên trong", vì vậy VM không bao giờ có thể truy cập được theo địa chỉ mà nó được chỉ định. Bạn có địa chỉ 10.0.2.2/24 của VM, nhưng khi truy cập Internet, các gói của nó được dịch thành 192.168.1.172 theo quy trình QEMU, do đó, máy chủ coi các gói đó là do quy trình QEMU tạo ra và xử lý chúng giống như bất kỳ gói nào khác, chẳng hạn như từ trình duyệt web chạy cục bộ hoặc bất kỳ thứ gì tương tự.

Làm cách nào để truy cập VM từ máy chủ? Khi chúng tôi có NAT, để tiếp cận các máy ẩn đằng sau nó, chúng tôi cài đặt ADNT quy tắc. Và một lần nữa, trường hợp của QEMU cũng không khác, bạn phải thiết lập một số quy tắc cho nó, sau đó bạn có thể giao tiếp với VM từ máy chủ (của các máy chủ khác, nếu bạn muốn) bằng cách gửi các gói đến các cổng đã chọn của máy chủ. chủ nhà Địa chỉ.

Theo tài liệu QEMU, để thiết lập quy tắc DNAT vào chế độ người dùng NAT của nó, bạn sử dụng hostfwd khoản. Hãy giới thiệu những điều sau đây vào dòng lệnh của nó:

    -netdev user,id=usernet0,hostfwd=tcp::11111-:22 \
    -thiết bị virtio-net-pci,netdev=usernet0,mac=08:00:27:92:B0:51

Sau đó, cổng tcp 11111 sẽ bị chiếm bởi qemu-system-x86_64 xử lý trên máy của tôi và nếu bạn kết nối với máy chủ cục bộ cổng 11111, kết nối sẽ được thực hiện với cổng 22 của VM.

Hình thức chung là hostfwd=hostip:hostport-guestip:guestport, nhưng nếu bạn bỏ qua chủ nhà, nó sẽ là máy chủ cục bộ và nếu bạn bỏ qua khách mời, đó sẽ là địa chỉ "không phải cổng" đầu tiên trong mạng khách.

Tôi nhận thấy bạn được đề cập virsh. Bạn đang chạy phải không libvirt? Sau đó, câu hỏi là trùng lặp; Xem ý kiến.

t09 avatar
lá cờ wf
t09
cảm ơn bạn, câu trả lời có ý nghĩa - tôi vẫn đang làm sai điều gì đó. `$ sudo kvm -m 3G -hdb /dev/sde netdev user,id=usernet0,hostfwd=tcp::11111-:22` Đầu ra: `qemu-system-x86_64: netdev: Không thể mở 'netdev': Không như vậy tệp hoặc thư mục` Tôi đã đọc liên kết tài liệu QEMU - bất kỳ hướng dẫn nào giải thích từng bước tôi có thể làm theo?
t09 avatar
lá cờ wf
t09
`$ sudo kvm -m 3G -hdb /dev/sde netdev user,id=usernet0,hostfwd=tcp::11111-:22 device virtio-net-pci,netdev=usernet0,mac=08:00:27:92: B0:51` Đầu ra tương tự: `qemu-system-x86_64: netdev: Không thể mở 'netdev': Không có tệp hoặc thư mục như vậy`
Michael Hampton avatar
lá cờ cz
@t09 Chỉ cần sửa lỗi đánh máy; bạn đã quên `-` trong `-netdev người dùng,...`
Tom Yan avatar
lá cờ in
Trên thực tế, `(S)NAT` (theo nghĩa không dành riêng cho qemu) không ngăn VM có thể tiếp cận máy chủ. Thay vào đó, nó "giả mạo" các lưu lượng truy cập từ VM sao cho chúng có vẻ bắt nguồn từ máy chủ VM đến các máy chủ mạng trong cùng một mạng LAN như vậy (ví dụ: cổng mặc định của nó). Về mặt kỹ thuật, nó thậm chí không ngăn chặn lưu lượng truy cập từ các máy chủ đó đến VM (nhưng chỉ là lưu lượng trả lời từ VM sẽ không có vẻ là trả lời cho chúng).
Tom Yan avatar
lá cờ in
Điều thực sự "cô lập" VM là, AFAIK, thực tế là `-netdev user` là một ngăn xếp mạng không gian người dùng trong chính qemu: https://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29, đó là tại sao bạn không thấy bất kỳ thứ gì mới xuất hiện trong `ip l` trên máy chủ. Chỉ là nhiều người dùng sẽ chỉ sử dụng nó cho thiết lập "phương pháp tiếp cận NAT" (vì nó là mặc định), do đó, nó trở thành một từ đồng nghĩa với NAT trong ngữ cảnh qemu. Sự thật là bạn có thể sử dụng một cầu nối không có nô lệ vật lý và dựa vào chuyển tiếp IP để kết nối Internet trong máy ảo.
Nikita Kipriyanov avatar
lá cờ za
@t09 `-netdev` thực sự phải có dấu gạch ngang. Đó là tùy chọn dòng lệnh QEMU.
t09 avatar
lá cờ wf
t09
nói chung đây là câu trả lời nhưng yêu cầu một tinh chỉnh để ra lệnh $ sudo kvm -m 3G -hdb /dev/sde -net nic -net user,hostfwd=tcp::1810-:22
Điểm:0
lá cờ in

Bạn có thể sử dụng một cầu nối mà không cần làm nô lệ cho bất kỳ giao diện Ethernet vật lý nào của mình trên máy chủ VM.

Giả sử chúng tôi gắn bó với sự lựa chọn của mạng con 10.0.2.0/24 (không cần thiết):

# ip l add natbr0 type bridge
# ip thêm 10.0.2.1/24 dev natbr0

Sau đó tạo tệp sau:

$ echo 'cho phép natbr0' | sudo tee /etc/qemu/bridge.conf 
cho phép natbr0

Sau đó, bắt đầu qemu với ví dụ: cầu -nic,br=natbr0 hoặc cầu -netdev,br=natbr0,id=nb0 -thiết bị virtio-net,netdev=nb0, cái nào sẽ vỗ nhẹ máy ảo của bạn tới cầu một cách năng động (tức là vỗ nhẹ giao diện sẽ bị xóa sau khi tắt máy ảo).

Bạn cũng cần định cấu hình IP tĩnh trên VM:

# ip thêm 10.0.2.2/24 dev ens3
# ip r thêm mặc định qua 10.0.2.1

Trừ khi bạn cũng thiết lập máy chủ DHCP (ví dụ: dnsmasq) trên Máy chủ. Đừng quên định cấu hình máy chủ DNS để sử dụng bên trong VM.

Lưu ý rằng các máy ảo sử dụng cùng một cầu nối có thể giao tiếp với nhau trừ khi bạn chặn giao tiếp đó bằng một số phương tiện (ví dụ: ebtables).

Các mặc định định tuyến (và máy chủ DNS sẽ sử dụng) chỉ cần thiết nếu bạn muốn VM có thể tiếp cận "bên ngoài". Nếu bạn chỉ cần nó để có thể giao tiếp với máy chủ VM, bạn nên bỏ qua lệnh thứ hai và có thể dừng đọc. (Chà, đọc Tái bút)


Có lẽ tốt nhất là định cấu hình, ví dụ:. dnsmasq trên máy chủ để trở thành trình chuyển tiếp DNS nếu bạn không muốn sử dụng máy chủ DNS "công khai" cụ thể trong VM, mặc dù sử dụng DNAT để chuyển tiếp các yêu cầu DNS tới ví dụ: 192.168.1.1 nên làm việc cho những cái cơ bản.

Sau đó, bạn sẽ cần bật chuyển tiếp IP:

# sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

Nếu bạn muốn tránh chuyển tiếp IP từ/đến giao diện mạng nhất định (ví dụ. điều chỉnh0) vì lý do bảo mật, bạn sẽ cần thiết lập tường lửa. Ví dụ:

# iptables -A FORWARD -i tun0 -j DROP
# iptables -A FORWARD -o tun0 -j DROP

Vì bạn có các tuyến đường hầm (VPN) thực tế sẽ ghi đè mặc định tuyến đường, lưu lượng truy cập từ VM đến Internet cũng sẽ đi vào đường hầm (trừ khi bạn đã thêm các quy tắc ví dụ ở trên). Nếu bạn muốn lưu lượng truy cập tăng, ví dụ: thông qua bộ định tuyến của bạn, bạn sẽ cần định tuyến theo chính sách. Ví dụ:

# ip ru add bảng tra cứu iif natbr0 123
# ip r add 192.168.1.1 dev wlan0 bảng 123 # có thể là tùy chọn
# ip r add default qua 192.168.1.1 bảng 123

Bạn cũng có thể ngăn máy ảo của mình truy cập máy chủ LAN của mình:

# iptables -A FORWARD -i natbr0 -d 192.168.1.0/24 -j DROP

Tạo ngoại lệ (lưu ý -TÔI) nếu bạn định chuyển hướng các yêu cầu DNS tới bộ định tuyến của mình:

# iptables -I FORWARD -i natbr0 -d 192.168.1.1 -p tcp --dport 53 -j CHẤP NHẬN
# iptables -I FORWARD -i natbr0 -d 192.168.1.1 -p udp --dport 53 -j CHẤP NHẬN

Cuối cùng, định cấu hình iptables để thực hiện SNAT động (theo giao diện gửi đi) cho mạng con VM của bạn:

# iptables -t nat -A POSTROUTING -s 10.0.2.0/24 -j MASQUERADE

Lưu ý rằng điều này KHÔNG có ý định và sẽ không ngăn chặn chính xác một số lưu lượng truy cập nhất định từ "bên ngoài" (máy chủ LAN vật lý hoặc Internet của bạn; máy chủ VM không được tính) để có thể tiếp cận máy ảo của bạn. Nó chỉ phá vỡ giao tiếp dưới dạng tác dụng phụ khi địa chỉ nguồn của lưu lượng trả lời từ máy ảo bị thay đổi trước khi chúng được chuyển tiếp ra ngoài.Để cách ly thích hợp, bạn sẽ cần (bổ sung) các quy tắc thích hợp trong PHÍA TRƯỚC chuỗi. Cân nhắc thiết lập "trạng thái" ở đó nếu bạn có nhu cầu như vậy.

Ngoài ra, bạn có thể chuyển hướng các yêu cầu DNS đến máy chủ lưu trữ từ máy ảo đến bộ định tuyến của mình:

iptables -t nat -A PREROUTING -d 10.0.2.1 -p udp --dport 53 -j DNAT --to-destination 192.168.1.1
iptables -t nat -A PREROUTING -d 10.0.2.1 -p tcp --dport 53 -j DNAT --to-destination 192.168.1.1

Cái nào ít nhiều sẽ cho phép bạn sử dụng 10.0.2.1 làm máy chủ DNS trong VM.


Tái bút Tất cả các thao tác trên (ngoại trừ việc tạo/ghi vào /etc/qemu/bridge.conf) không ổn định, tức là chúng sẽ biến mất sau khi bạn khởi động lại (trừ khi bản phân phối của bạn làm điều gì đó ngớ ngẩn). Tôi sẽ không đi sâu vào cách bạn có thể làm cho chúng bền bỉ, vì có nhiều cách/cách tiếp cận khác nhau và nó có thể dành riêng cho bản phân phối.

t09 avatar
lá cờ wf
t09
phải tạo /etc/qemu/ dir.... Không chắc là tôi đang quay vm chính xác. Đã thử `Sudo kvm -m 3G -hdb /dev/sde -netdev bridge,br=natbr0,id=nb0 -device virtio-net,netdev=nb0` và `$ Sudo kvm -m 3G -hdb /dev/sde -nic bridge,br=natbr0,id=usernet0` và `$ sudo kvm -m 3G -hdb /dev/sde -nic bridge,br=natbr0,id=usernet0` vm bắt đầu
t09 avatar
lá cờ wf
t09
trên vm: `$ip a ...3: natbr0: ...state UNKOWN nhóm mặc định qlen 1000` _ifconfig_ `natbr0: inet 10.0.2.2 netmask 255.255.255.0 phát sóng 0.0.0.0` _$sudo ip r thêm mặc định qua 10.0.2.1/24_ `Lỗi: mọi địa chỉ hợp lệ đều được mong đợi thay vì "10.0.2.1/24`
Tom Yan avatar
lá cờ in
@t09 Đó là một lỗi đánh máy. `/24` không nên được sử dụng trong lệnh đó.
Tom Yan avatar
lá cờ in
@t09 Có một lỗi đánh máy khác: thay vào đó, lệnh `ip a add 10.0.2.2/24` phải có dạng như `dev ens3`. (Kiểm tra bên trong VM bằng `ip l` để tìm tên giao diện sẽ sử dụng. Đảm bảo rằng bạn biết rằng *toàn bộ khối lệnh* bao gồm lệnh sẽ được chạy *trên VM*.)

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.