Walang internet ang mga bridged OpenVPN client? Suriin ang NAT rule

Buhay ang bridged server, nandiyan ang masquerade rule, at umiikot pa rin ang browser sa client. Mukhang dapat gumana ang lahat, kaya nauubos ang unang oras sa pagsuri ng tunnel at ng mga kredensyal. Pagkatapos, binabasa mo ang counter sa NAT rule at makikita mo ang zero na hindi gumalaw. Ang rule na hindi kailanman nagbilang ng kahit isang packet ay hindi kailanman tumugma sa isa, at sa bridged server ang dahilan ay estruktural: lumalabas ang trapiko ng client sa virtual na tap device, habang pinapangalanan ng rule ang pisikal na card na kinopya mo mula sa lumang gabay.

Ang counter ang ebidensya, hindi ang entry sa talahanayan

Iba ang rule na umiiral at rule na tumutugma, at ang counter ang naghihiwalay sa kanila. Ilahad ang NAT table na may detalyadong counter at basahin ang mga numero sa tabi ng bawat rule bago magbago ng anuman. Ang counter na nakatigil sa zero habang dumadaloy ang trapiko ay nangangahulugang nilaktawan ang rule, gaano man katinong ang mga address nito. Ang counter na tumataas habang nabigo pa rin ang koneksyon ay nagdadala sa iyo sa ibang lugar: sa forwarding, sa daan pabalik, o sa dulong dulo.

iptables -t nat -L POSTROUTING -v -n

Basahin muna ang counter sa tabi ng tugma ng interface. Kung tama ang source range at mali ang labasan, isang salita lang sa rule ang pagwawasto, hindi isang ganap na bagong rule.

Hanapin ang pangalang aktwal na itinatala ng kernel

Tukuyin ang pangalan ng tunnel device bago isulat ang rule, gamit ang listahan ng interface at hindi ang memorya. Sa isang OpenVPN na bridged setup, ang device ay karaniwang tap interface na ginawa ng server, at ang pangalan nito ay bahagi ng iyong lokal na configuration, hindi isang pandaigdigang constant. Tiyakin na umiiral ito habang buhay ang tunnel, dahil ang device na lumilitaw lamang pagkatapos kumonekta ang client ay gagawing parang problema sa rule ang naunang pagsubok.

ip -brief link

Isulat ang pangalan. Ang bawat susunod na command sa diagnosis na ito ay tumutukoy dito, at ang maling pag-type dito ay gumagawa ng eksaktong parehong zero counter gaya ng orihinal na pagkakamali.

Isulat muli ang rule para sa tunnel device

Itutok ang rule sa tunnel device at panatilihin ang client range bilang kondisyon ng tugma, upang masakop nito ang trapiko ng tunnel at pabayaang hindi maabala ang sariling koneksyon ng host. Palitan ng sarili mong range at pangalan ng device, dahil pareho sa ibaba ay halimbawa at walang isa ang naipapasa sa ibang installation.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

Pagkatapos, suriin ang dalawa pang kondisyon na itinatago ng parehong sintomas. Suriin kung naka-enable ang forwarding, at kung hindi, i-enable ito sa configuration ng distribution mismo at hindi sa echo na nawawala pagkatapos ng reboot. Basahin din ang mga counter ng forward chain at, kung itinatapon nito ang trapiko ng tunnel, payagan nang partikular ang interface na iyon at hayaang hindi magalaw ang patakaran ng chain.

Ang pagbasa ng forward chain na may counter ay kumakatawan sa isang command at tinatanggal ang kalahati ng natitirang posibilidad bago mo pa hawakan ang isa pang rule.

Bakit hindi kailanman tumutugma ang pisikal na card

Ang bridge ay isang software switch na binuo mula sa tap device at isang pisikal na interface. Pumapasok ang frame ng client sa switch na iyon at lumalabas patungo sa pisikal na network bilang miyembro ng bridge, hindi bilang packet sa card. Kaya itinatakda ng kernel ang packet sa bridge at sa port nito, at kaya hindi kailanman lumilitaw sa tugma ang card na iniisip mo. Walang sira sa pisikal na interface; hindi lang ito ang device na itinatakdaan ng kernel ng packet na iyon.

Ang susunod na problemang nararanasan ng mga tao ay galing sa parehong istruktura: ang pag-filter ng frame sa bridge ay hiwalay na pasilidad sa pag-filter ng IP. Kung ang kailangan ay paghihigpit sa antas ng frame, ito ay kabilang sa pag-filter ng bridge, hindi sa isang rule sa IP table.

Patunayan ito mula simula hanggang dulo, pagkatapos ay gawing permanente

Magbuhat ng isang client at mag-ping ng isang bagay sa LAN ng server; sinasanay ng landas na iyon ang forwarding nang walang anumang pagsasalin. Pagkatapos, humiling ng pampublikong bagay upang kailangang gamitin ang masquerade rule, at basahin muli ang counter: dapat itong gumalaw para sa pagsubok na ito at hindi para sa nauna. Ang capture na nakuha sa tunnel device ay nagpapakita ng parehong lugar kung saan lumilitaw ang frame at kung aling address ang dala nito.

Huling hakbang: ilagay ang mga gumaganang rule sa configuration na binabasa ng restart, at itala ang pangalan ng device na aktwal na ginagamit ng bridge ng host na ito. Ang lahat ng nai-type sa kamay ay nawawala pagkatapos ng reboot, at bumabalik ang parehong pagkabigo na walang natitirang makapagpapaliwanag.

Kung hindi pa rin gumagalaw ang counter pagkatapos ng muling pagsulat, ihambing ang source range sa rule sa address na aktwal na natanggap ng client, dahil ang bridged server ay maaaring magbigay ng address mula sa range na hindi mo sinasadya.