PiVPN rokasspiediens darbojas, lapas iestrēgst: pārbaudiet MASQUERADE

Tālrunis rāda tuneli kā pievienotu, klients ziņo par privātu adresi, un pirmā lapa joprojām karājas ielādes vidū. Šī kombinācija vairākumu aizsūta pie šifrēšanas iestatījumiem un procesora temperatūras, kur patiesībā nekas nav sabojāts. Tunelis pacēlās, tātad sarunas bija pabeigtas; tas, kas neizdevās, ir nākamais solis, kad serveris mēģina nodot klienta paketes internetam. Ejiet to pašu ceļu, kuru iet šīs paketes, un neatbilstība parasti ir redzama vienā NAT tabulas rindā.

Sāciet ar to, ko klients sasniedz un ko ne

No pievienotā klienta ielādējiet lapu, kas atrodas publiskajā internetā, un atzīmējiet, vai tā neizdodas uzreiz vai iestrēgst pusceļā. Pēc tam atveriet resursu paša VPN servera privātajā adresē un salīdziniet abus rezultātus.

Tuneļa adrese, kas atbild uz ping, kamēr publiskās vietnes nokļūst līdz taimautam, ir pāradresācijas vai tulkošanas problēmas pazīme, nevis salauzta rokasspiediena. Klienta paša statusa panelis tos nevar atšķirt, jo tas zina tikai to, ka vadības kanāls ir pacelts. Pārbaudiet serverī tuneļa saskarni ar ip -br addr show tun0 un apstipriniet, ka klientam piešķirtā adrese atrodas jūsu konfigurētajā pūlā. Ja pūls un klienta adrese nesakrīt, vispirms izlabojiet to, jo katrs noteikums zemāk tiek saskaņots ar pūlu.

Tālāk pajautājiet serverim, kuru saskarni tas izmantotu, lai sasniegtu publisku adresi. ip route get 203.0.113.9 pirmajā rindā izdrukā izvēlēto ierīci un avotu. Pierakstiet šīs ierīces nosaukumu, jo tieši šai vērtībai jābūt NAT noteikumā.

Izlasiet noteikumu, kas izlemj, vai paketes izies

MASQUERADE pārraksta paketi tikai tad, kad tā iziet caur noteikumā nosauktās saskarnes starpniecību. Noteikums, kas saistīts ar vadu ierīci, neko nedara trafikam, kas iziet caur Wi-Fi, un pakete saglabā savu privāto avota adresi līdz augšējam maršrutētājam. Tam maršrutētājam nav atgriešanās maršruta uz jūsu tuneļa pūlu, tāpēc tas atmet atbildi, un klients redz savienojumu, kas atveras un pēc tam mirst. Simptoms pieaug atkarībā no tā, cik daudz lapas pienāk pirms pirmās atbildes nepieciešamības.

Uzskaitiet dzīvo tabulu un lasiet izejas saskarnes kolonnu, nevis tikai meklējiet vārdu MASQUERADE. Pievienošanas formas izvadi ir vieglāk salīdzināt nekā formatētu sarakstu:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Raspberry Pi, kas kādreiz izmantoja Ethernet un tagad izmanto Wi-Fi, novecojušais nosaukums gandrīz vienmēr ir viss stāsts. Instalētājs pierakstīja, kura ierīce bija iestatīšanas laikā, un saglabātā noteikumu kopa to atkārto katrā palaišanā. Pirms kaut ko citu mainīt, salīdziniet ierīci no maršruta meklēšanas ar ierīci noteikumā. Ja tās sakrīt, saskarne nav jūsu problēma, un jums jāpāriet uz skaitītājiem pēdējā sadaļā. Ja tās atšķiras, labojums ir viena vārda rediģējums noturības failā.

Izlabojiet saglabāto noteikumu kopu, ne tikai darbojošos

Tikai dzīvās tabulas rediģēšana pastāv līdz nākamajai pārstartēšanai, un tas ir tieši tik ilgi, lai jūs pārliecinātu, ka problēma ir atrisināta. Noteikumi, kas atgriežas palaišanas laikā, dzīvo failā, ko ugunsmūra noturības pakotne ielādē no jauna. Debian bāzētos Pi attēlos šis fails parasti ir /etc/iptables/rules.v4.

Pirms tam pieskarties izveidojiet kopiju, pēc tam aizstājiet MASQUERADE rindas izejas saskarni ar pierakstīto ierīci, piemēram, -o wlan0 vietā -o eth0. Atstājiet avota diapazonu tādu, kāds tas ir, ja vien jūsu klientu pūls nav mainījies. Ielādējiet no jauna un apstipriniet, ka noteikums tagad nosauc pareizo ierīci:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Divi blakus esošie iestatījumi viegli aizmirstas. sysctl net.ipv4.ip_forward jāziņo 1, un augšējam maršrutētājam nevajadzētu pašam filtrēt privātās avota adreses.

Pierādiet, ka noteikums iedarbojas, pēc tam izolējiet, kas vēl ir lēns

Skaitītāji ir vienīgais godīgais pierādījums tam, ka noteikums ir saskaņots. Palaidiet detalizēto sarakstu, sāciet lejupielādi klientā un palaidiet to vēlreiz. Paketes un baitu kolonnām blakus jūsu noteikumam vajadzētu pieaugt, un noteikums, kas paliek uz nulles, joprojām nesakrīt. Ja skaitītāji kustas, bet lapas joprojām neizdodas, salīdziniet avota diapazonu ar faktisko pūlu ar grep -n "^server " /etc/openvpn/server.conf. Ja tie kustas un lapas ielādējas, bet caurlaidspēja ir slikta, tulkošana ir pabeigta un atlikušā problēma ir citur.

Salīdziniet divus pārraides no tā paša klienta, vienu uz vietējā tīkla resursdatoru un otru caur tuneli uz to pašu resursdatoru. Lēnums abos gadījumos norāda uz Pi izejas kanālu vai Wi-Fi savienojumu, nevis uz VPN. Lēnums tikai caur tuneli norāda uz MTU un atkārtotām pārraidēm, ko varat pārbaudīt ar ip -s link show tun0 pirms jebkura šifrēšanas iestatījuma maiņas.

Lai atceltu eksperimentu, atjaunojiet kopiju un ielādējiet to no jauna, pēc tam apstipriniet, ka sākotnējais noteikums un tā skaitītāji ir atgriezušies. Ierakstiet izejas ierīci un pārlādes komandu servera piezīmēs, jo nākamā izejas kanāla maiņa atkal atklās to pašu neatbilstību. Noteikums, kas nosauc nepareizo ierīci, paliek neredzams, līdz trafikam tas ir vajadzīgs.