Ang VPN tunnel ay hindi kailanman kumokonekta: saan talaga humihinto ang mga packet

Patuloy na nagtatangkang muli ang kliyente, humihinto ang log bago matapos ang handshake, at wala talagang naitala ang server. Ang pattern na iyon ay lumalayo sa mga kredensyal at tumuturo sa ruta: may isang bagay sa pagitan ng dalawang dulo na tumatangging dalhin ang protocol na kailangan ng tunnel. Tukuyin kung saan humihinto ang mga packet bago hawakan ang alinman sa dalawang configuration, dahil ang na-filter na protocol at maling password ay gumagawa ng parehong magiliw na error sa karamihan ng kliyente. Ang mga pagsubok ay nakaayos ayon sa gastos, ang pinakamura muna.

Patunayan kung saan humihinto ang trapiko

Kunin sa parehong sandali sa outbound interface ng kliyente at sa server. Ihambing ang lumabas sa dumating, at itala kung saang direksyon lumilitaw ang pagkakaiba.

Walang anuman sa server ay nangangahulugang ang ruta o ang unang NAT ay nagtatapon ng trapiko, habang ang mga pagdating na walang sagot ay tumuturo sa firewall sa server o sa return route na wala. Ang router na madalas na nagtatapos ng mga tunnel ay bihirang magtago ng kapaki-pakinabang na log, kaya ang capture ang nagiging talaan. Isulat ang destination port at protocol number, dahil ang dalawang kabiguan ay magkatulad sa dialog ng kliyente.

Namamatay ang PPTP nang walang protocol 47

Dinadala ng PPTP ang kontrol sa TCP 1723 at ang data nito sa loob ng GRE, na protocol IP 47 at hindi port number. Ang pag-forward lamang ng 1723 ay nagbubunga ng klasikong resulta: nag-a-authenticate ang koneksyon at pagkatapos ay tumatahimik, dahil walang tuntunin para sa protocol na nagdadala ng payload. Hindi ito maihihiwalay ng kliyente sa tinanggihang password, kaya ang capture ay dapat mauna sa mga pagbabago sa configuration.

Ang passthrough ay tumatakbo sa tapat na direksyon ng inbound forward, at ang firmware ay madalas na gumamit ng isang label para sa dalawa, sapat para lituhin ang lahat. Sa kliyenteng Linux, maaaring itapon ng lokal na firewall ang GRE bago pa man makibahagi ang router, kaya kailangan ng protocol 47 ang sarili nitong tuntunin at dapat na ma-load ang conntrack helper. Iniingatan ng ufw ng Ubuntu ang mga tuntuning iyon sa file na before, dahil hindi maipahayag ng ordinaryong allow rules ang protocol number. Pagkatapos, i-reload ang firewall sa halip na i-restart ang makina.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP at IPsec sa likod ng dalawang NAT

L2TP sa loob ng IPsec ay nangangailangan ng UDP 500 para sa palitan ng key, UDP 4500 kapag natukoy ang NAT, at ESP bilang protocol 50. Bawat isa sa kanila ay sinasala nang hiwalay, kaya ang tuntuning nagpapahintulot sa isa ay walang pinapatunayan tungkol sa dalawa pa. Dalawang router na sunod-sunod ay nagsasalin ng bawat packet nang dalawang beses, at hindi na nagkakasundo ang mga dulo sa kung ano ang napagkasunduan.

I-bridge ang panlabas na modem, o patayin ang NAT sa panloob na router, upang maabot ng pampublikong address ang device na nagtatapos ng tunnel. Kung saan hindi posible ang alinman sa dalawa, ang tunnel ay dapat simulan mula sa loob ng hangganan ng dobleng NAT, hindi tapusin doon.

Mga network ng carrier at pagbabahagi ng address

Ang WAN address sa loob ng 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 o 100.64.0.0/10 ay nangangahulugang walang pampublikong address ang router at walang inbound forward mula sa internet ang makakaabot dito. Ang NAT sa antas ng carrier ay nagsasala rin ng mga protocol na hindi nito inaasahan, at ang GRE ay madalas na biktima sa mga mobile link. Ihambing ang WAN address sa router mismo, hindi ang address na iniuulat ng lookup site para sa kliyenteng nasa likod nito.

Ang pagpapatakbo ng parehong router sa kable na linya ay naghihiwalay ng natuklasan tungkol sa carrier mula sa error sa configuration sa isang pagsubok. Kung saan tinatanggihan ng carrier ang protocol, ang natitirang opsyon ay ibang transport sa 443 o tunnel na sinimulan mula sa loob.

Basahin ang listahan ng tagapakinig bago isara ang mga port

Ang nakababahalang port scan ay madalas na ang feature set na dumarating na naka-enable. Inventaryuhin ang mga tagapakinig, itugma ang bawat socket sa isang feature, pagkatapos ay patayin ang feature sa halip na harangan ang port, upang hindi magkahiwalay ang dalawang pananaw.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

Ang mga default ng SoftEther ay magandang halimbawa: TCP 443, 992 at 5555, kung saan ang mga feature na L2TP/IPsec at DNS tunnel ay nagdaragdag ng sarili nilang sockets. Ang pagpatay sa mga feature na iyon ay nag-aalis ng mga tagapakinig sa halip na itago sila, at ang pagsubok mula sa panlabas na host ay nagsasabi kung pinapayagan ng carrier ang port na dumaan. Ang tagapakinig na tumutugon nang lokal ay maaaring sarado pa rin sa itaas, kaya ihambing ang sariling WAN address ng router sa iniuulat ng panlabas na serbisyo.