Google Cloud VPN ne permet pas le HTTP ou SSH sortant dans Office Network

Nous avons une nouvelle configuration Google Cloud Platform. Nous avons créé une connection VPN avec succès à notre routeur de bureau. Nous pouvons accéder à des adresses privées dans Google Cloud à partir de notre bureau et certains services à l'intérieur de GCP peuvent accéder à notre réseau de bureaux. Nous avons configuré kube-dns pour utiliser notre server DNS interne via VPN pour des ressources privées et pour la plupart, cela fonctionne bien. Et, à partir des deux conteneurs et des machines virtuelles de noeud de cluster de conteneurs, nous pouvons faire une search de ping dans le réseau de bureau.

Mais la première application que nous souhaitons déployer dans Google Container Engine a besoin de l'access HTTPS aux servers API exécutés à l'intérieur du réseau de bureaux derrière le pare-feu. Ces connections HTTPS (testées avec wget et curl) restnt suspendues. Aucune donnée n'est renvoyée. J'ai effectué une capture de trafic sur le routeur de bureau et je vois que les packages entrent et returnnent dans le tunnel comme prévu. J'ai également essayé régulièrement des saisies HTTP et SSH en provenance de Google dans notre bureau. J'ai essayé à l'intérieur d'un conteneur en cours d'exécution et du noeud du cluster Container Engine (image COS) lui-même. Rien que le ping et le DNS fonctionnent à partir de Google dans le réseau de bureau.

Il n'existe pas de règles de pare-feu Egress dans GCP. La politique du routeur de bureau autorise actuellement tout le trafic sur le VPN. J'ai trouvé quelques autres messages semblables à ceux de notre situation, mais ils étaient plus anciens et la plupart d'entre eux faisaient reference aux GCP qui ont été réalisés entre-time, d'autres discutent de solutions iptables complexes.

Nous sums donc complètement bloqués sur notre premier deployment sur le cloud. Comment pouvons-nous dépanner le networking dans GCP? Il semble que les packages de return ne soient simplement pas renvoyés à leur source. Ni DNS ni ping sont TCP et, bien sûr, HTTPS et SSH sont TCP. C'est la principale différence que je peux identifier entre ce qui fonctionne et ce qui ne fonctionne pas. Qu'est-ce que nous essayons ensuite?

Ce qui suit explique le paramètre MTU requirejs pour Google Cloud VPN.

https://cloud.google.com/compute/docs/vpn/advanced#maximum_transfer_unit_mtu_considerations

Sur nos routeurs de série Juniper SSG, j'ai configuré le MTU sur l'interface virtuelle du tunnel VPN avec:

set interface tunnel.3 mtu 1460 

Cependant, la solution nécessitait plus que juste MTU, car sur un VPN, le encryption ajoute des frais généraux après que les packages sont divisés en pièces MTU, ou du less je pense que c'est ainsi. Encore une fois sur nos routeurs, nous avons dû appliquer les commands de configuration suivantes pour configurer les formats de packages appropriés pour le trafic VPN:

 set flow tcp-mss 1350 set flow vpn-tcp-mss 1300 

Je n'ai pas passé du time à chercher les valeurs numériques parfaites dans ces commands, et je n'ai pas non plus testé si l'un d'entre eux était effectivement requirejs, mais avec ces deux valeurs, notre VPN a commencé à fonctionner comme prévu.